I'm still breathing a sigh of relief that it's no longer the Haskell Evangelism Strikeforce. People can preach Rust all they like, but Haskell scared me.
They aren't that dissimilar. Both promote ambitious languages in which lofty ideals somewhat get in the way of convenience, practicality and available brain capacity. Both consist, for the most part, of disturbingly enthusiastic but generally friendly disciples. They want you to believe, to suffer meaningfully, to achieve one-ness with the borrow checker, to be (or Maybe) The Monad.
They're not, say, supercilious lispers who have guarded the bucket of unvarnished truth since 1958 or rubyists promising a path to happiness in this life (and also something about monkeys).
"supercilious lispers" - I wish I could disagree because I love the language(s). Why is that?! What mechanism forces lispers in recluse from the world?
Oof, it was intended entirely as a joke but if you want an overly simplistic theory: an ancient language which provided profound insights into the nature of computation and programming but without a modern, maintained, free, useful and cross-platform implementation. Adherents are justifiably proud of the former and hair-trigger defensive about the latter. This doesn't exactly attract new adherents.
It's the easy accessibility of macros, without any cultural aversion to their overuse.
Any truly-large Lisp codebase ends up as an entire Lisp-derivative language. (If not in truth, then in practice: once you've created and employed enough macros in a given project, you've forced anyone who wants to contribute to said project to "learn" the project as if it were its own language anyway.) This effectively isolates the project by the same degree as having been written in an entirely-novel language.
This effectively isolates the project by the same degree as having been written in an entirely-novel language.
Not any more than the special vocabulary of a project consisting of functions. Or of classes in an object framework.
If I see (foo x y z), and do not know what foo is, I have no idea what happens, regardless of whether foo is a macro or a function. If I know it's a function, then I know that x, y and z are expressions reduced to values; they are not analyzed as syntax. However, that is far from a complete understanding; I still don't know what foo does.
If foo must be a function (I may not use macros), then I have to figure out a way to package everything into the values that x, y and z denote so that foo can do whatever it does. That will likely be harder to understand than a macro.
Anyway, Lisp macros can be expanded. If you think some macro is hard to understand, then invoke macroexpand on the quoted form; see if you like that better. That's what you would have to write if you didn't have the macro.
Just because macros are not allowed doesn't mean that everything is magically understandable and that you don't have to spend weeks, months or even years learning the structure of the code and its vocabulary.
Code without macros still extends the language.
When we define a function, we are extending a language; just like we extend a natural language when we invent a new noun or verb.
It's the sort of language that'd be great as a partial-coverage DSL in a "patchwork" sort of language, though—like how C has asm{} blocks, or how Rust has unsafe{} blocks.
I'd like to, for example, write code in an actor language, where the state and message-passing was handled in an Erlang-y way (tagged tuples, message sending as a primitive, every process has an untyped inbox), but then the "body" of each process, between the IO parts, was Haskell or another parametrically-typed ML. You wouldn't even need any concept of an IO monad: all the side-effects would occur "outside" the haskell{} block.
