> But the main disadvantage of LISP is maintainability.
LISP allows programmers to use abstraction so powerful that sky is the limit. Problem is, humans have their limits, too. And different humans have different limits. Abstractions are powerful, but then you have to think abstractly in order to use them properly.
When you are good at abstract thinking, LISP will liberate you. When your colleague is better than you, or just as good as you but has more LISP experience, reading their code will make your head hurt. To make you two cooperate, your colleague would have to give up some of their powers... but the ability to use those powers to their maximum was the thing that made them love LISP. So now one of you is going to suffer.
Other languages often put artificial limits to your abstract thinking. For example, you have a few parts of code you realize are somehow just different instances of the same pattern; the pattern could be extracted and reused... but doing it in this language would either be impossible, or the outcome would be really ugly, or it would require writing so much boilerplate code that the more abstract version would end up being longer, less legible, and not really nice at all. So you sigh and don't do it. And the same thing happens to your colleagues in similar situations, so now you are all writing approximately on the same level of abstraction.
In other words, with lesser languages, the frustrating thing is the language. With LISP, the frustrating thing is other humans (and that may include yourself on a different day). But the frustration is always there. Unless you are really good and working alone, I guess. But that puts the company that employs you in a dangerous situation, so it is unlikely to happen.
When your friend is a faster runner, and is wearing running shoes, he will leave you in the dust. Solution: everyone wears combat boots, and carries a 30 pound load on their back. Now the field is level; and you even have to cooperate to go forward.
That's the sad fact about human nature: when you have a project that requires everyone to move at the same speed, chaining people together and putting unnecessary weight on their back works better (more reliably) that asking the fastest ones to please slow down a little.
(Then of course there are also other problems, such as companies wanting to keep all their employees completely replaceable, which is incompatible with people using their unique skills.)
For me, one of the key determinants in how I write most code is how approachable it will be to the next person. Because anything significant is going to involve more people, and I don't want to have to be chained to my past successes.
I think there's an analogy with writing. If I'm writing something for myself, or for a narrow, specialist audience, I can indulge my desire for all sorts of things: abstruse ideas, obscure words, Dickensian sentences, punny wordplay, tangents galore. But when I'm writing here I try very hard to rein those desires in. Because here the writing isn't about me.
So I think LISP's ability to turn my ideolect into a tower and creeup up into it is exactly what I don't want in a tool.
How
"1. ((...)) LISP used to be superior to everything else but modern languages have caught up in most areas. LISP still has a few special tricks ((...)) but these are rarely needed in everyday programming."
and
"3. ((...)) You will get awesome results very fast and can do things that would be really hard in other languages."
can both be true?
5 comments
[ 3.1 ms ] story [ 21.9 ms ] threadLISP allows programmers to use abstraction so powerful that sky is the limit. Problem is, humans have their limits, too. And different humans have different limits. Abstractions are powerful, but then you have to think abstractly in order to use them properly.
When you are good at abstract thinking, LISP will liberate you. When your colleague is better than you, or just as good as you but has more LISP experience, reading their code will make your head hurt. To make you two cooperate, your colleague would have to give up some of their powers... but the ability to use those powers to their maximum was the thing that made them love LISP. So now one of you is going to suffer.
Other languages often put artificial limits to your abstract thinking. For example, you have a few parts of code you realize are somehow just different instances of the same pattern; the pattern could be extracted and reused... but doing it in this language would either be impossible, or the outcome would be really ugly, or it would require writing so much boilerplate code that the more abstract version would end up being longer, less legible, and not really nice at all. So you sigh and don't do it. And the same thing happens to your colleagues in similar situations, so now you are all writing approximately on the same level of abstraction.
In other words, with lesser languages, the frustrating thing is the language. With LISP, the frustrating thing is other humans (and that may include yourself on a different day). But the frustration is always there. Unless you are really good and working alone, I guess. But that puts the company that employs you in a dangerous situation, so it is unlikely to happen.
(Then of course there are also other problems, such as companies wanting to keep all their employees completely replaceable, which is incompatible with people using their unique skills.)
For me, one of the key determinants in how I write most code is how approachable it will be to the next person. Because anything significant is going to involve more people, and I don't want to have to be chained to my past successes.
I think there's an analogy with writing. If I'm writing something for myself, or for a narrow, specialist audience, I can indulge my desire for all sorts of things: abstruse ideas, obscure words, Dickensian sentences, punny wordplay, tangents galore. But when I'm writing here I try very hard to rein those desires in. Because here the writing isn't about me.
So I think LISP's ability to turn my ideolect into a tower and creeup up into it is exactly what I don't want in a tool.