Although treasonous to say, I don't think a sexp-based language is appropriate for a wide community of programmers. (I'm currently enjoying coming back to PLT Racket from Clojure, so please don't write me off as someone who can't get over the initial shock.)
Macros make it too easy to define new syntax, to the point where things that should be core language features are neglected, only to be continually re-half-implemented, etc. Take a look at what passes for 'good enough' for destructuring in Clojure, both the older let-based and the newer core.match (which still lacks the extensibility of Racket's match). The deficiencies can always be fixed 'later', right?
No syntactic difference between function application and special forms means that one requires an editor that can somehow differentiate (slime/drracket approaches) to even have a shot at quickly scanning unfamiliar code (say, quickly looking at what an implementation actually does). It's pointed out that Guile will handle other languages (imho this is tacitly admitting uncertainty about Scheme). But multiple languages only stand to make the code-reading problem even worse! Never mind that Scheme will be the only first-class language (other languages can't consume macros) so alternatives are at best advertisements to get people hooked and having to learn the 'real language'.
The little bit of Ruby I've written opened my eyes to how much you can do with just first-class code blocks, and made me understand why something like SLIB would opt for explicit lambdas everywhere instead of macros. Macros are so enticing to cut down on boilerplate, but they're visually indistinguishable, and without plenty of forethought they're not composable.
Clearly many skin syntaxes for Lisps have been attempted and never caught on. I don't currently have much to add on that front besides a suggestion of not being afraid of well thought out concrete syntax (how many base special forms are there, really?). But really, I think my whole post shows the main problem with Lisp, at least for me. It's so easy to do things and it's such a blank slate that no matter what I sit down to do, I always end up trying to create a new language.
Although treasonous to say, I don't think a sexp-based language will
ever be adopted by a wide community of programmers.
The problem with this argument is that a sexp-based configuration
language is already adopted by a community of programmers: Emacs Lisp.
Emacs itself ships with over a million lines of Lisp code, and there
are thousands of extensions available from around the Internet.
The problems you worry about with respect to macros have simply not
happened; most people name macros the same way (starting with def or
define-), and most macros are written "cleanly" in such a way as to
not surprise the programmer. (I'll be honest: I can't think of one
time I've ever hit a but in a Lisp program caused by a strange macro.)
Emacs Lisp shows that if you give someone a turing-complete
programming language on top of a powerful piece of software with a
clean and well-documented API, programmers will ignore the warts and
enhance the software in ways you never thought possible.
Guile is not a perfect programming langauge, and I would never use it
by choice. But if I started using some piece of software that used it
for configuration, I know I would love it because it would stay out of
the way and let me make things. Once you are making cool things,
you don't care about the syntax or programming language features at
your disposal: you just make it work.
Some other examples of this include JavaScript for Firefox extensions
and Vimscript for Vpim extensions. JavaScript is very ... minimal
compared to other languages like Perl, Python, Ruby, Haskell, and so
on, but people write great browser extensions anyway. Vimscript is
the weirdest thing I've ever seen but Vim is able to do a lot of cool
stuff despite this.
The only thing a successful extension language needs is something
worth extending. If you use Guile as your extension language, you
can concentrate doing that instead of writing your own programming
langauge toolchain.
I can't think of one time I've ever hit a bu[g] in a Lisp program caused by a strange macro.
What about macros that have the same name? In Emacs, the convention is to name your functions foo-this and foo-that if your program is foo.el. But this does not seem to be true for macros. Is that because macros don't leap outside the compilation context of foo.el? (Edit: nope, I checked it and they do.) Or is it that people are sloppier about naming their macros?
Edit: or is it rather that, if your foo.el defines a macro 'blah, and I write bar.el that says (require 'foo) and then defines its own macro 'blah, it's my macro that gets used to compile my code, so the one in foo.el can't do any harm to it?
The naming convention for macros is a little weird. My rule is: if the macro is user-visible (and not something to make your module easier to implement), it should start with define- or with-, and should include a uniquifier somewhere in the name. If you were writing an extension called foo, you might provide a macro called with-current-foo or define-foo-bar.
If someone already has a macro with this name, then don't call it that.
The reason for ignoring the normal package-function naming convention is that it's simply ugly to write code like:
I get (and practice) the part about user-visible macros. But what about macros that are just to make my module easier to implement? I often write those to concisify (well, you did say "uniquifier") my code. There's a tension here: encoding the package name in the macro name can easily make the name so long that the whole thing is why-bother, but using a short name runs the risk of a collision. For example, paredit.el defines XCOND. Although I don't have an XCOND, that's just the sort of macro name I might have chosen.
Well you're completely right, that first sentence was DOA (I edited it to hopefully take away less from the rest of my comment). And it's certainly true that any extension language will be used if it enables one to get things done. And I would rather have something extensible, rather than something utterly braindead where I end up using another language to generate extension scripts.
But I still think Lisps impose an overhead on reading code, and that overhead is highly unfriendly to a moderate GNU user who just wants to start poking around to see what happens under the hood and customize a few things. If a goal of the GNU project is to empower users to extend their own software, that burden should be avoided.
The problems I said with macros not being visually distinct reflect what I've personally found when trying to grok others' code. Many special forms are easily picked out, but one must be sure that all have been picked out in order to separate the control flow from the expression trees.
But I still think Lisps impose an overhead on reading code, and that overhead is highly unfriendly to a moderate GNU user
Interesting thought, but where is your evidence? From personal experience, I've spent the most time reading and writing Perl and Emacs Lisp. As a result, I find both of them easier to read than Python, which is a language designed to be readable. The reality is that all computer programs are hard to read if you don't practice reading them. (As an aside, I would estimate that about 20% of programmers "in industry" are able to fluently read code. The rest just write the same thing over and over again and are confused when they are asked to fix bugs in code they didn't write.)
I don't think XML is appropriate for any programmer.
XML kinda showcases another point.. Give someone the tools to whip up a 'language' without really thinking about their underlying problem and incidental complexity abounds.
Macros make it too easy to define new syntax, to the point where things that should be core language features are neglected, only to be continually re-half-implemented, etc. Take a look at what passes for 'good enough' for destructuring in Clojure, both the older let-based and the newer core.match (which still lacks the extensibility of Racket's match). The deficiencies can always be fixed 'later', right?
No syntactic difference between function application and special forms means that one requires an editor that can somehow differentiate (slime/drracket approaches) to even have a shot at quickly scanning unfamiliar code (say, quickly looking at what an implementation actually does). It's pointed out that Guile will handle other languages (imho this is tacitly admitting uncertainty about Scheme). But multiple languages only stand to make the code-reading problem even worse! Never mind that Scheme will be the only first-class language (other languages can't consume macros) so alternatives are at best advertisements to get people hooked and having to learn the 'real language'.
The little bit of Ruby I've written opened my eyes to how much you can do with just first-class code blocks, and made me understand why something like SLIB would opt for explicit lambdas everywhere instead of macros. Macros are so enticing to cut down on boilerplate, but they're visually indistinguishable, and without plenty of forethought they're not composable.
Clearly many skin syntaxes for Lisps have been attempted and never caught on. I don't currently have much to add on that front besides a suggestion of not being afraid of well thought out concrete syntax (how many base special forms are there, really?). But really, I think my whole post shows the main problem with Lisp, at least for me. It's so easy to do things and it's such a blank slate that no matter what I sit down to do, I always end up trying to create a new language.