Or use an existing, language provided parser - haskell-src-exts, for instance.
"it would need to be a extra step in your compilation pipeline"
I don't see what that has to do with syntax. Any compiler could have a hook where it hands off a parsed AST - many do.
I have jet to see compiler hooks that are as simple as to write as they are in lisp. Also, most of them are far less powerful then they are in clojure.
I see tons and tons of example were people use clojure macros in intressting ways but not that many people who write scala compiler hooks.
So in theroy you are right, in practice I have not jet seen tons of examples.
Clojure has a lot of great things going for it. I don't have any objection to Lisp syntax - I like it although I don't know that I prefer it - but I don't think we should be crediting it with things more properly deserved by other pieces. Proper support for macros is a biggie.
It has to do with the syntax. Working Lisp "plugins" is very simple because all the code is represented as plain datastructures. Rewriting program is like writing simple data structures manipulation code.
Strictly speaking, AST data structures are often full of junk, but that's not mostly a matter of the complexity of the syntax itself but of the variety of things being done with that AST - you can't report error locations if all you have is the nested lists representing your Lisp program.
The focus on making macros work well is absolutely a strength of Lisps. The syntax is a much smaller part of that than the lore would suggest.
More syntax makes things harder, compiler that have not been designed wit this goal make things harder. You can look at the papers trying to get this stuff in to other langauges and there are some problems, dylan [1] was doing it befor most others, now rust is coping that stuff.
Actually some of the coolest stuff was done by David Moon (Common Lisp, Dylan) he greated a langauge spec that he calls PLOT [2] and it has a very inovate macro system. For anybody that is intrested in that sort of stuff I highly recommand it.
[1] http://people.csail.mit.edu/jrb/Projects/dexprs.pdf [2] http://users.rcn.com/david-moon/PLOT/ and http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf
Scheme's SRFI 49 (2003-2005, Final): "Indentation sensitive syntax": http://srfi.schemers.org/srfi-49/srfi-49.html
Lispin (2008): So utterly dead, we have to resort to the Internet Archive: http://wayback.archive.org/web/20080517144846id_/http://www....
cl-2dsyntax: http://www.cliki.net/cl-2dsyntax (Annoying exclamation marks in this one, oops).
CGOL (1973!): http://en.wikipedia.org/wiki/CGOL
The last one shows you just how long people have been unsuccessfully trying to promote Algol-like syntaxes for Lisp.
That would be F#.
Both languages are very similar in way that they support lists, arrays and maps as first class citizens as fundamental types and provide expressive algorithms to operate over them 'out of the box' with more or less uniform syntax.
To me, as a novice, the main apparent practical difference between the two languages are the domains for which there is strong support and which have discoverable solutions. I.e. the platform and the community.
If anybody on Arch Linux wants to give a Hy a try, I put together a PKGBUILD: python-hy.
I'm experimenting on this with Hype. It's barebones and does some whacky-don't-look-at-it macro "magic", but it works! Also trying to mimic core.typed's way of annotation.
Note: Just using python functions annotations with a typeannotation library to provide some runtime type checking. It's rather rad if i can say so my self.
https://github.com/Foxboron/Hype https://github.com/ceronman/typeannotations
Parenthesis are always offputting to me, even though I like a fair amount of clojure concepts. I often feel like functional programming has made a cottage industry around putting obfuscated names around relatively simple ideas (see transducers for example)
I'm not directly in the dev space, but it appears as though the choice of languages that people use has far more to do with what Builder Tools will support than what people actually want to use. Teams only use Scala or Clojure if they are willing to build it using their convoluted Ant wrapper that doesn't make any sense.
Combine that with Scala's bewildering type system and I can see why companies move to Java or Clojure.
I was really into Scala and studying it and everything. I still remember all the scala bloggers I follow, Daniel, Tim MOrris, Paul Snively, etc...
Eventually I landed into a scala job role. Oh boy was it different. The other programmers were like type casting to Any or whatever that generalize highest type was (unified type theory).
The complexity is pretty high, it's great if you know it all but in all seriousness it was impeding...
Personally, I like the object + static typing + first class functions as it eliminates 90% of errors at compile time. If any error occurs at run time, am pretty sure it's logical. This is a huge plus. The only drawback - the ridiculous amount of type specific code you have to write for mundane changes/updates.
As a Scala dev, that is absolutely terrifying. I can't even begin to think of a good reason for that.
(Ok, but in all seriousness... don't.)
The Java community has its flaws (oh boy, does it) but it has adapted to the hordes of mediocrities. Give Scala to mediocre engineers (who typecast to Any, use null instead of Option[T]) and you have the Java hell with worse IDE support and 5x compile times.
I would be very surprised if that was the case, based on what I've seen.
I wouldn't be surprised if Clojure has more "industry" adoption than Scala at this point.
Give me Clojure semantics (anti-OO, maps, vectors, and seqs) with some optional typing and a Python syntax then I'm there *
* that's just my preference, no need to convince me of anything other.