That is fine. Most people simply cannot drive a Formula-1 car, but it would be stupid to conclude that a F-1 is a cursed car and nobody should want to drive one. Similarly, a few languages can only be used by highly trained people who understand well how it works. Lisp, Forth, and J are in that category of tools that require highly trained people. In their hand, one of these languages can do fantastic things, in the hands of an average programmer you have nothing.

Lisp without macros can be and is used by 'normal programmers'. And even with macros it's not like it's witchcraft that only a select few can handle. It's a powerful language, but nonetheless a language that everyone can learn.

That is actually a nice analogy! No one, not even the pro formula-1 drivers will want to drive a f1 car in regular traffic. Much the same with these languages (apls, lisps, forth, etc); they have their place and role, but is better not used in regular open source or commercial codes.

That is absolutely false. I have seen absolutely horrible "clever" code hacks in Java production code - absolutely opaque and extremely complicated.

Lisp is definitely a good choice for 'regular open source or commercial code'.

Actually, it's somewhat the opposite. The lisp curse refers to the ways in which lisp can easily be extended with nonstandard or bespoke features. Apl relies much more heavily on primitives; they are so expressive and general that you often don't even need to add functions. This gives the code more universality (assuming you know the language, which I expect should be a given).

It's about redundancy. Code in other languages has much more of it, and that is good for understandability, recognizability.

With less redundancy it is easier to make errors both in writing AND reading of code.

APL is like compressed code. The redundancy has been compressed out. Therefore reading a page of APL is like reading a book in other languages. Even though the text is shorter you still have to understand as much of program behavior.

Reading APL means reading something FAST and we know that it is easy to have errors whenever you try to do something fast, say like typing very fast.

> With less redundancy it is easier to make errors both in writing AND reading of code.

I don't really see that. Boilerplate code is not helpful for clarity or correctness. It's just more code that you have to write that can introduce errors.

The errors you introduce into boilerplate code are trivial syntax errors easy to spot by the parser. The difficult errors are the semantic ones because the parser can not catch them.

Think about human languages. They have large amounts of redundancy and for a good evolutionary reason I believe. It is easier to distinguish meaning when words around a given word anchor it into a specific context.

Redundant languages have a built-in error-correcting code built into them. They take more bits to transmit but those extra bits correct, and help detect errors.

Very interesting link.