3 ms·

That's also the problem with Lisp (and other powerful languages). They are far too malleable. They can be changed into unrecognizable blobs by people with lots

That's also the problem with Lisp (and other powerful languages). They are far too malleable. They can be changed into unrecognizable blobs by people with lots of intelligence but low wisdom (I include myself in that group). They don't _have_ to. They can lead (and often do) to clean implementations. But we tend to like 'cleverness'. The larger the team, the more detrimental the effect. That's why we ended up with Java. And more recently, golang. As much as I like Go on its niche, it's a straightjacket. I'd often think to myself "this whole file I've been working for a week on would be 5 lines of scheme or lisp". But then if I get run over by a bus the company could theoretically replace me the next day (they couldn't because there's far more knowledge required than coding, but they think they could).

agentultra 5y ago
Ah yes, the "we should be able to hire anyone off the street and replace you instantly," fallacy. I've never in all my career ever been asked to walk out into the street and grab a random stranger and pull them into our office to fix this code now because Jerry just got hit by a bus and won't be making it into the office ever again. We can barely hire other programmers.
- watmough 5y ago
  Great point! Maybe not so much of a fallacy when you look at how developer management currently works in most mainstream companies. It really does seem more geared to going slowly, and making each tiny step be recorded in some system.
jimbokun 5y ago
Mediocre programmers will write unrecognizable blobs in any language, and good Lisp programmers can use macros and other advanced tools to make their code even more clear and understandable.
wtetzner 5y ago
> That's why we ended up with Java. To be fair, I've seen much bigger unrecognizable blobs in Java than I have in any Lisp. A language that's too rigid just makes people reach for other workarounds, e.g. craziness in the build system, using lots of reflection, configuring things with XML, etc. It doesn't make it any easier for someone to come into a project and understand what's going on. At least with Common Lisp you can just expand the macros to see what's going on.

agentultra 5y ago

Ah yes, the "we should be able to hire anyone off the street and replace you instantly," fallacy. I've never in all my career ever been asked to walk out into the street and grab a random stranger and pull them into our office to fix this code now because Jerry just got hit by a bus and won't be making it into the office ever again. We can barely hire other programmers.

watmough 5y ago
Great point! Maybe not so much of a fallacy when you look at how developer management currently works in most mainstream companies. It really does seem more geared to going slowly, and making each tiny step be recorded in some system.

jimbokun 5y ago

Mediocre programmers will write unrecognizable blobs in any language, and good Lisp programmers can use macros and other advanced tools to make their code even more clear and understandable.

wtetzner 5y ago

> That's why we ended up with Java. To be fair, I've seen much bigger unrecognizable blobs in Java than I have in any Lisp. A language that's too rigid just makes people reach for other workarounds, e.g. craziness in the build system, using lots of reflection, configuring things with XML, etc. It doesn't make it any easier for someone to come into a project and understand what's going on. At least with Common Lisp you can just expand the macros to see what's going on.