In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types.

So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose.

I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-...

I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.

There is Boost.Hana and the older Boost MPL and brigand.

C++20 will have more constexpr improvements.

Although I do conceed they require a C++ Wizard hat, and aren't not even close of Lisp's macros friendliness.

In Lisp, they say "here is a tool that can do anything. Have fun". In Python they say: "here are many tools that are specific and limited to that purpose. Also you gona take bad decisions, so we limited it some more".

The first approach is appealing to very good programmers. The second one, to anybody who had to work with the vast majority of normal programmers.

I prefer the second one. People abuse macros, make way to long lambdas, don't document their magic and indent poorly if they are not forced to.

Since tooling is something people always learn too late, I'm going with the language with sane defaults.

And there is a limited pool of that.

We, humans, also have work to do.

Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp.

Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming.

I don't think that one needs to be a 10x programmer to use Lisp - many of those 10x programmers are not programming in Lisp, since the 10x programmer gets hired because he/she might be able to cope with enterprise Java architectures.

Since Lisp is a programmer amplifier, you might think that these Lisp users are 10x programmers, when in fact they are not.

But there are domains where people are using Lisp, who are not focused on programming. For example there are various Lisp-based music apps + literature which are used by composers. Example: https://opusmodus.com

Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)

I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before.

* Where did you learn about it?

* Are there other similar prog-lang music production tools with similar level of polish?

* Any cross-platform / Windows supported tools? -- unfortunately opus modus only runs on macs :-(

1: https://github.com/ctford/leipzig

2: https://github.com/overtone/overtone

3: https://extemporelang.github.io/

Opusmodus was supposed to have a Windows version in 'the future', but I don't know what plans are currently.

The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.

Which would easily make decades old and still maintained Lisp implementations unmaintainable, since they contain zillions of macros themselves.