4 ms·

> Also: a maintenance nightmare as soon as you have more than ~1 person working on the codebase! Lisp isn't any harder to maintain than any other language. The

> Also: a maintenance nightmare as soon as you have more than ~1 person working on the codebase! Lisp isn't any harder to maintain than any other language. The Lisp codebases I've worked on, even professionally, were originally written by talented, experienced engineers and were in fact wonderful to maintain. > Now imagine something like Lisp where every developer & team morphs it in a different way and you have a product with hundreds of developers on it. Dr. Ian Malcom's could/should distinction applies here. Most Lisp teams do not "morph the language" willy-nilly. They set standards of what to do and what not to do, establish a house style, build up a library of in-house functions and macros, and the more junior programmers imitate the more senior ones, just like any other dev team in any other language. And the vast majority of Lisp teams are small, even if they are working on large applications. "We wanted to make it possible for very large projects to be done by small teams of people and for smaller ones to be done by one person." --Tom Diaz, Director of Software Products, Symbolics, 1986: https://www.youtube.com/watch?v=-K01FQ73xgY&t=144s https://www.youtube.com/watch?v=-K01FQ73xgY&t=144s > The anti-Lisp is something like Go. Simple, not very flexible, everyone does it the same way mostly, you can plug & play developers like scrum demands we do. I think you might be on to something. Symbolics was very much in danger of making large software projects possible by one person or a small team of people. It seems as if the corporate world has responded to the proliferation of more powerful software development tools -- not only in Lisp, but certainly Lisp and Smalltalk had an outsized influence -- by lowering the skill ceiling to make devs more fungible, and creating more and more process to hobble their productivity so as to justify larger teams of devs and dev-adjacent personnel: PMs, POs, scrum masters, etc.

Jensson 3y ago
> The Lisp codebases I've worked on, even professionally, were originally written by talented, experienced engineers But companies have untalented junior engineers, you need a language they can write while still remaining structured. Talented professional engineers can write assembly language in a very easy to read and structured manner. But there is a reason basically everyone writes in structured languages today instead of unstructured, that enforced structure helps make code more readable and uniform.
- bitwize 3y ago
  With good leadership, untalented junior engineers can become very productive junior engineers. I've seen it happen. Within weeks some kids fresh out of college, who had been taught everything mainly in Java (this was still the JavaSchool era, more or less) were proficiently and happily contributing to our C++ code base. They were pretty good, but they weren't Carmack or anything. Now if your leaders are untalented, you have an organizational issue: you're promoting schlubs. Why are you doing that? Stop doing that.
Capricorn2481 3y ago
> I think you might be on to something. Symbolics was very much in danger of making large software projects possible by one person or a small team of people. It seems as if the corporate world has responded to the proliferation of more powerful software development tools -- not only in Lisp, but certainly Lisp and Smalltalk had an outsized influence -- by lowering the skill ceiling to make devs more fungible, and creating more and more process to hobble their productivity so as to justify larger teams of devs and dev-adjacent personnel: PMs, POs, scrum masters, etc. This is a ridiculous LISP conspiracy theory that really needs to die. What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit? If lisp were genuinely powerful, corporations would be able to make bigger projects faster.
- Avicebron 3y ago
  I think the key point was that maintaining control over the employees by making them replaceable has more benefit that better products. That's what market capture is for
- bitwize 3y ago
  > What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit? 1) In the corporate world, a larger headcount under you means you get more funding for your initiatives. If you get things done with a team of five, that signals to upper management that that's all you need and your budget will be adjusted down accordingly. 2) When it comes to software, companies favor the ability to monitor and control the development process from above over speed. Agile only gets uptake among large orgs inasmuch as Agile consultants promise them this. 3) There is, decades after The Mythical Man-Month, a sense that you can get a good programmer's worth of output -- without a good programmer's worth of risk -- out of several, much more fungible, mid programmers. 4) Egos on the line. Tom Smykowski from Office Space is real. Need proof? Propose something sensible like having engineers talk to, or shadow, customers so they can see what the pain points are in their work and which pieces of the software need attention... and see who bristles. No conspiracy is needed. Companies can remain stubbornly dysfunctional, and will bizarrely spend more to protect that dysfunction, for decades, than to try something better. My father proposed more resilient ways of running an assembly line in the 1960s, upper management laughed. In the 1980s what he proposed was one of the tenets of the "Toyota Way", but it took until the 90s/2000s for American managers to start listening. This goes double when you realize that software is off most companies' critical path, and addressing performance issues among software teams is way less important than addressing performance issues among, say, sales and marketing teams.
_19qg 3y ago
> Symbolics was very much in danger of making large software projects possible by one person or a small team of people. Just that there were very few of these people. A typical saying: "there were more Lisp Machines (~ 10000 were made in one decade, over all Lispm companies) than programmers for them."

Jensson 3y ago

> The Lisp codebases I've worked on, even professionally, were originally written by talented, experienced engineers But companies have untalented junior engineers, you need a language they can write while still remaining structured. Talented professional engineers can write assembly language in a very easy to read and structured manner. But there is a reason basically everyone writes in structured languages today instead of unstructured, that enforced structure helps make code more readable and uniform.

bitwize 3y ago
With good leadership, untalented junior engineers can become very productive junior engineers. I've seen it happen. Within weeks some kids fresh out of college, who had been taught everything mainly in Java (this was still the JavaSchool era, more or less) were proficiently and happily contributing to our C++ code base. They were pretty good, but they weren't Carmack or anything. Now if your leaders are untalented, you have an organizational issue: you're promoting schlubs. Why are you doing that? Stop doing that.

Capricorn2481 3y ago

> I think you might be on to something. Symbolics was very much in danger of making large software projects possible by one person or a small team of people. It seems as if the corporate world has responded to the proliferation of more powerful software development tools -- not only in Lisp, but certainly Lisp and Smalltalk had an outsized influence -- by lowering the skill ceiling to make devs more fungible, and creating more and more process to hobble their productivity so as to justify larger teams of devs and dev-adjacent personnel: PMs, POs, scrum masters, etc. This is a ridiculous LISP conspiracy theory that really needs to die. What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit? If lisp were genuinely powerful, corporations would be able to make bigger projects faster.

Avicebron 3y ago
I think the key point was that maintaining control over the employees by making them replaceable has more benefit that better products. That's what market capture is for
bitwize 3y ago
> What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit? 1) In the corporate world, a larger headcount under you means you get more funding for your initiatives. If you get things done with a team of five, that signals to upper management that that's all you need and your budget will be adjusted down accordingly. 2) When it comes to software, companies favor the ability to monitor and control the development process from above over speed. Agile only gets uptake among large orgs inasmuch as Agile consultants promise them this. 3) There is, decades after The Mythical Man-Month, a sense that you can get a good programmer's worth of output -- without a good programmer's worth of risk -- out of several, much more fungible, mid programmers. 4) Egos on the line. Tom Smykowski from Office Space is real. Need proof? Propose something sensible like having engineers talk to, or shadow, customers so they can see what the pain points are in their work and which pieces of the software need attention... and see who bristles. No conspiracy is needed. Companies can remain stubbornly dysfunctional, and will bizarrely spend more to protect that dysfunction, for decades, than to try something better. My father proposed more resilient ways of running an assembly line in the 1960s, upper management laughed. In the 1980s what he proposed was one of the tenets of the "Toyota Way", but it took until the 90s/2000s for American managers to start listening. This goes double when you realize that software is off most companies' critical path, and addressing performance issues among software teams is way less important than addressing performance issues among, say, sales and marketing teams.

_19qg 3y ago

> Symbolics was very much in danger of making large software projects possible by one person or a small team of people. Just that there were very few of these people. A typical saying: "there were more Lisp Machines (~ 10000 were made in one decade, over all Lispm companies) than programmers for them."