> the haters that parrot this old, barnacle-ridden trope: it's too powerful! Macros! Nobody can understand it but gods and strange people on the Internet! You will have to listen to these people constantly invade every forum, discussion group, and chat room on the Internet to tell you how you shouldn't be learning CL.

These people are actually the reason I went and learned CL. I couldn't understand why some programmers would hate a programming language so much. Now it's one of my favourite languages.

Yes, it's great to experience the 10x or 100x developer syndrome sometimes.

Using Clojure changed my life somewhat, as at some point I rewrote 2000 lines of C++ (to handle splitting and coalescing NAESB cycle pipeline nominations) in about 27 lines of pattern-matching Clojure, and just no one, no one would take it seriously. A usable UI in Swing to manage it wasn't much more, and was cross-platform. Not a fun experience overall, I ended up quitting that company, doing iPhone dev for a bit, then moved back into G&G.

Other than that rewrite experience, I just used Clojure like I used to use Perl. Easy to bang something out in, and performant native Java libraries for things you might not expect, like low-level SQL Server (2005 at the time!) and Oracle (8 at the time) drivers.

I'm back mainly as a C++ developer now in visualization and HPC.

That's also the problem with Lisp (and other powerful languages). They are far too malleable. They can be changed into unrecognizable blobs by people with lots of intelligence but low wisdom (I include myself in that group).

They don't _have_ to. They can lead (and often do) to clean implementations. But we tend to like 'cleverness'. The larger the team, the more detrimental the effect.

That's why we ended up with Java. And more recently, golang. As much as I like Go on its niche, it's a straightjacket. I'd often think to myself "this whole file I've been working for a week on would be 5 lines of scheme or lisp". But then if I get run over by a bus the company could theoretically replace me the next day (they couldn't because there's far more knowledge required than coding, but they think they could).

Ah yes, the "we should be able to hire anyone off the street and replace you instantly," fallacy. I've never in all my career ever been asked to walk out into the street and grab a random stranger and pull them into our office to fix this code now because Jerry just got hit by a bus and won't be making it into the office ever again. We can barely hire other programmers.

Great point!

Maybe not so much of a fallacy when you look at how developer management currently works in most mainstream companies.

It really does seem more geared to going slowly, and making each tiny step be recorded in some system.

Mediocre programmers will write unrecognizable blobs in any language, and good Lisp programmers can use macros and other advanced tools to make their code even more clear and understandable.

> That's why we ended up with Java.

To be fair, I've seen much bigger unrecognizable blobs in Java than I have in any Lisp. A language that's too rigid just makes people reach for other workarounds, e.g. craziness in the build system, using lots of reflection, configuring things with XML, etc. It doesn't make it any easier for someone to come into a project and understand what's going on. At least with Common Lisp you can just expand the macros to see what's going on.

If you want to learn a truly powerful language then learn Assembler programming ;)

Once you want some macros for "obvious abstractions," use a macro assembler;

then once you want a more consistent macro language reinvent Forth on your macro assembler;

then once you want a complete stdlib reinvent Lisp on Forth

Yep which is why we have less powerful but more productive programming languages today. And we created it all from Assembler.

Amen.