> whether we like it or not, each project effectively creates its own dialect of the language

(http://ithare.com/cpp-guidelines-made-to-measure-s-one-size-...)

Each project has its own coding guide and idiosyncrasies. That is not restricted to Lisp. Macros allow you to express some rules in a domain-specific language, not in a separate document or tacit knowledge. This is more manageable than ad-hoc approaches. Abusing macros is definitely bad and can lead to ghetto-languages.

Lisp is interactive, call "describe" on whatever you don't understand. Under Emacs, if you encounter a form you don't understand, point to it, "C-c C-d d" and you get the documentation; "M-." and you go to the definition; "C-c M-m" and you call macroexpand.

This is pretty much exactly the argument made by The Lisp Curse:

http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

That basically every program written in a Lisp becomes its own programming language. It has mechanisms which are vaguely-familiar-but-different from all the other programs. The mechanisms are 80% of a complete solution, but a different 80% each time, depending on the needs of the program.

Anyone can write js.

Some humans can write Lisp. But Lisp production code can only be maintained and updated by AIs who are more intelligent than we are.

Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming.

For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish.

I don't think the problem was metaprogramming.

When I see people talking about Closure, I don't see them talking about the power they get from metaprogramming. It's almost the opposite, people talk about the safety of FP, and power from Category Theory.

For C++ templates, you get that impression and multiply by a few googols.

Now, Ruby and Python communities do claim to gain power from metaprogramming. I can say that Python metaprogramming is something completely different from Lisp's one, but Ruby's is more similar. Yet, both communities put a hard limit on the amount of "magic" you should use on your programs (where Ruby's limit is way higher than Python's), so it can not become the panacea that it is in Lisp.

Metaprogramming is one of the main selling points of Lisp, the only other being how easy it is to implement. Other languages have other features to show.

What people talk about category theory w/r/t Clojure? Since it has almost no type system to speak of, I'd be very curious to know what in the world they're on about.

Macros and the repl were, to me, the best part of clojure.

I see people talking about monads and applicatives all the time. I don't know Clojure, but I got the impression it has a powerful implicit type system.

Not the same level of metaprogramming. Ruby Python try but it's less idiomatic or batshit crazy. C macros are glorified sed scripts, you're at the byte buffer level; it's cute but not good either. To me lisps sit at a nice middle ground where metalevels are as close as possible while still being usable. That's my take based on what people said in the 60s, after all sexps weren't supposed to be used.

Metaprogramming scales very well. Every high-level program + compiler is metaprogram for assembler code.

That has a much higher barrier of entry, though. If I work on a project written in Blub, I won't be able to do any metaprogramming unless I can get everyone else to adopt my Blub++ compiler. If the software is written in Lisp, all I have to do is get it through a code review.

In effect, it's not really scaling; it's being limited to the small portion of developers who work on compilers.

Possible that most people really like to have distinct level encoded as syntax.