That's a good question without an easy answer, but there are two leading theories. One is that languages are infrastructure and it's really hard to replace infrastructure once it gets established (look at how much time it's taking for electric cars to replace gas-powered ones). The other is that Lisp's productivity boost allows individuals to get things done by themselves and so it tends to attract people who aren't good at collaborating (the famous "Lisp curse"). So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully.

> So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully.

This is why I choose Go many times over other languages. Its a bit easy to keep on the rails since it is so restrictive (at the cost of repetitive, explicit verbosity).

Historically I think there's a very strong case that Symbolics did outperform others with their software productivity, especially in graphics. They had an ability to wade into certain domains and produce legitimately shockingly competitive products, which really should not have been possible.

But I also think Lisp leads to spectacular burnout as I think it imposes a greater cognitive requirement on the part of the developer.

A Symbolics graphics reel from 1989 https://www.youtube.com/watch?v=V4HXPJtym2Q

This stuff was still in use on Final Fantasy 7 https://lunduke.substack.com/p/the-computers-used-to-do-3d-a...

> it imposes a greater cognitive requirement on the part of the developer

... because of the "monotonous" syntax? That was a reason mentioned by L Peter Deutsch in Coders at Work ...

I do think it's the relatively superficial uniformity of it, regardless of the level of abstraction at which you're operating, which eventually makes things crack.

My hunch is top performing lisp devs are capable of holding more of this in their head at once than mere mortals. A key benefit of more conventional languages is you can limit the scope of your concerns and reasoning (within limits), however, that does prevent you from being able to make whole system optimisations, which is notably what Symbolics (at least in graphics) were outperforming everyone else at. What the Symbolics devs achieved seems to me only viable by having an unusually capable team focused on a specific domain for a long time, without too much diversion/distraction. The bus factor must have been horrific.

This thread made me go off and look more into this, and I couldn't help thinking the software industry has really lost something with the commercial failure of these very deeply specialised and incredibly high end tools. (ICAD was the other). It's odd how people could justify spending huge amounts on the hardware just to run the software, but didn't want to pay for the software when it became possible to run it on just about anything, and so the software stops being developed.

> It's odd how people could justify spending huge amounts on the hardware just to run the software, but didn't want to pay for the software

I wonder if the difference between capital expenditure vs operation expense was an influence . . .

In some small way I am revisiting the idea with https://github.com/kaveh808/kons-9

We'll see what comes of it.

I developed my first 3D graphics system on a Symbolics back in the mid-80's, before Symbolics released their S-Geometry package.

Though the software was powerful and made use of the extensibility provided by Lisp, it failed to gain much traction in the industry because the hardware was not suited to 3D graphics. Silicon Graphics (SGI) workstations took that market by the early 90's.

"But I also think Lisp leads to spectacular burnout as I think it imposes a greater cognitive requirement on the part of the developer."

I have never heard about this as a speciality of Lisp.

> there's a very strong case that Symbolics did outperform others with their software productivity

Symbolics used object-oriented programming in the form of Flavors. It had an integrated, GUI-based development environment. Development was mostly incremental: one can write some piece and run it immediately inside the application under development. Everything runs in a debug mode, without an explicit debug mode. The whole system, the whole documentation, the whole source code was always available. The applications were large, but for today's standards nothing shockingly large.

But there were also downsides. Mostly: hardware developed outside much faster and software had to move there.

First the Symbolics graphics suite was ported over to SGIs running Allegro CL, then also Windows NT systems. A refresh of the graphics suite was developed under the name Mirai.

https://www.youtube.com/watch?v=UNXEemZ_Ysk