4 ms·

> 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

> 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.
- Capricorn2481 3y ago
  Your comments are describing two different things. - Technical leaders choosing a language that's easy for developers to Grok to make them more fungible, and make onboarding easier. - Corporate managers purposefully choosing a language as a "Response" to Common Lisp, as you said, to tank the performance of a company for more funding. One is actually happening, the other requires me to believe corporations even know what Common Lisp is, which would be amazing. You're lucky if management even knows what Python is. The conspiracy theory I'm referencing is the fact that people think Corporations just hate developer proficiency and will actively fight against tools that make people more proficient. That is different from someone coming to a manager with, from the managers perspective, an idea that could increase efficiency but make them look bad. The first is not something a manager actively does, but the second is an insecure reaction to someone "Rocking the boat." Common Lisp did not take the world over for lots of reasons beyond hand wringing PMs.
  - bitwize 3y ago
    You're missing the point. It's not really a response to Lisp as such, it's a response to anything which makes developers more productive. Developments from the Lisp world have had trickle-down effects that make other languages and IDEs more powerful: garbage collection, hot-reloading, etc. The productivity gains realized by these developments, however, have been more than neutralized by a concomitant increase in corporate BS. So it's not really a conspiracy of orgs out to get Lisp but it does make Lisp a bad fit for organizations which rely on inertia, ego, and fungible worker-units, which is most of them.
kiviuq 3y ago
Lisp's primordial sin is the fact that it is FP. US cooperations never supported FP (see Microsoft and F#). FP is largely a European phenomenon.
- kagevf 3y ago
  Lisp is non-opinionated and supports FP, OOP, AOP, in whatever mix you want.
jjav 3y ago
> This is a ridiculous LISP conspiracy theory that really needs to die. Not really. Lisp can be a power amplifier if you can keep it under control. But, as I've argued above, that limits you to a small stable team. If I could start a new company with a few solid Lisp buddies and I knew that's going to be the core team for the next decade, I think I'd use Lisp and it would be a significant productivity gain. But but but.. those are some unrealistic constraints. If I'm starting a company presumably I want the company to keep growing as much as possible, not stay with a few core people for years. So no, I wouldn't use Lisp. > to have too many employees All of them, the goal of both startups and public companies is to continuously grow. As soon as growth stops that is seen as a problem and the decline begins. The only exception is privately held companies who don't run on VC money and don't have any intention to become public. Those might be the best candidates for Lisp. > to work slowly No company specifically wants that, but they vastly prioritize being able to hire 10,000 scrum interchangeable cogs to do development and that's not the environment where Lisp works well.
- lispm 3y ago
  It's possible to build teams in the low hundreds. Example: https://www.youtube.com/watch?v=hMVZLo1Ub7M https://www.youtube.com/watch?v=hMVZLo1Ub7M Siscog, company is 37 years old, 130 employees, 1.7 Million lines of Lisp code. In the planning/scheduling domain for railway companies. Other example ITA Software, bought by Google for $700 Million dollar. 100+ Lisp developers.
  - jjav 3y ago
    > Siscog This is really cool! Had not heard about them. Thanks! Nice, so looks like low hundreds of developers may be possible given the right environment. That said, I don't feel it disproves my impression. If the company is 37 years old, still privately held and still has less than a hundred developers then it is clearly not a company looking to grow fast above all else. So feels like a nurturing environment for Lisp.
    - lispm 3y ago
      > looking to grow fast above all else They may also not need to. They may have enough people working in a productive environment. If you add a Lisp feature to a large code base, it may not take a lot of time to do so, given the possibility of an incremental development style with Lisp (-> changing running applications incrementally).
ragall 3y ago
> What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Many companies are risk-averse and prefer predictability to performance. They therefore often choose slow and outdated software products instead of newer, more efficient ones and they prefer using tools that require large amounts of developers, but in a predictable fashion. Using a tool that allows a very small team to perform the job of 10x as many is risky because the bus factor becomes that much higher, as well as the difficulty in finding and training replacements.

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.

Capricorn2481 3y ago
Your comments are describing two different things. - Technical leaders choosing a language that's easy for developers to Grok to make them more fungible, and make onboarding easier. - Corporate managers purposefully choosing a language as a "Response" to Common Lisp, as you said, to tank the performance of a company for more funding. One is actually happening, the other requires me to believe corporations even know what Common Lisp is, which would be amazing. You're lucky if management even knows what Python is. The conspiracy theory I'm referencing is the fact that people think Corporations just hate developer proficiency and will actively fight against tools that make people more proficient. That is different from someone coming to a manager with, from the managers perspective, an idea that could increase efficiency but make them look bad. The first is not something a manager actively does, but the second is an insecure reaction to someone "Rocking the boat." Common Lisp did not take the world over for lots of reasons beyond hand wringing PMs.
- bitwize 3y ago
  You're missing the point. It's not really a response to Lisp as such, it's a response to anything which makes developers more productive. Developments from the Lisp world have had trickle-down effects that make other languages and IDEs more powerful: garbage collection, hot-reloading, etc. The productivity gains realized by these developments, however, have been more than neutralized by a concomitant increase in corporate BS. So it's not really a conspiracy of orgs out to get Lisp but it does make Lisp a bad fit for organizations which rely on inertia, ego, and fungible worker-units, which is most of them.

kiviuq 3y ago

Lisp's primordial sin is the fact that it is FP. US cooperations never supported FP (see Microsoft and F#). FP is largely a European phenomenon.

kagevf 3y ago
Lisp is non-opinionated and supports FP, OOP, AOP, in whatever mix you want.

jjav 3y ago

> This is a ridiculous LISP conspiracy theory that really needs to die. Not really. Lisp can be a power amplifier if you can keep it under control. But, as I've argued above, that limits you to a small stable team. If I could start a new company with a few solid Lisp buddies and I knew that's going to be the core team for the next decade, I think I'd use Lisp and it would be a significant productivity gain. But but but.. those are some unrealistic constraints. If I'm starting a company presumably I want the company to keep growing as much as possible, not stay with a few core people for years. So no, I wouldn't use Lisp. > to have too many employees All of them, the goal of both startups and public companies is to continuously grow. As soon as growth stops that is seen as a problem and the decline begins. The only exception is privately held companies who don't run on VC money and don't have any intention to become public. Those might be the best candidates for Lisp. > to work slowly No company specifically wants that, but they vastly prioritize being able to hire 10,000 scrum interchangeable cogs to do development and that's not the environment where Lisp works well.

lispm 3y ago
It's possible to build teams in the low hundreds. Example: https://www.youtube.com/watch?v=hMVZLo1Ub7M https://www.youtube.com/watch?v=hMVZLo1Ub7M Siscog, company is 37 years old, 130 employees, 1.7 Million lines of Lisp code. In the planning/scheduling domain for railway companies. Other example ITA Software, bought by Google for $700 Million dollar. 100+ Lisp developers.
- jjav 3y ago
  > Siscog This is really cool! Had not heard about them. Thanks! Nice, so looks like low hundreds of developers may be possible given the right environment. That said, I don't feel it disproves my impression. If the company is 37 years old, still privately held and still has less than a hundred developers then it is clearly not a company looking to grow fast above all else. So feels like a nurturing environment for Lisp.
  - lispm 3y ago
    > looking to grow fast above all else They may also not need to. They may have enough people working in a productive environment. If you add a Lisp feature to a large code base, it may not take a lot of time to do so, given the possibility of an incremental development style with Lisp (-> changing running applications incrementally).

ragall 3y ago

> What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Many companies are risk-averse and prefer predictability to performance. They therefore often choose slow and outdated software products instead of newer, more efficient ones and they prefer using tools that require large amounts of developers, but in a predictable fashion. Using a tool that allows a very small team to perform the job of 10x as many is risky because the bus factor becomes that much higher, as well as the difficulty in finding and training replacements.