He’s saying that one does not need to do a perfect job to win. A common failure mode is to spend ages worrying about the details while someone else’s good-enough quick hack takes over the world. It’s quite a resonant quote for programmers.
C and Unix obliterated their technically superior rivals. There’s a whole tradition of worrying about why this happened in the still extant LISP community which was one of the principal losers. Look up ‘Worse is Better’ if you’re interested in the details.
I’m aware of all that. But the idea that perfection is not needed, and that successful things are almost always flawed in some way, seemed too obvious to merit a quote.
But that is just typical mind fallacy on my part: if others feel this is an insight people should be reminded of, I shouldn’t argue.
My understanding—and I wasn’t there for that particular holy war, so I might have some of the details wrong—is that while LISP is in many ways the better language, it didn’t at the time have the practical implementation support that C did. Efficient LISP code at the time required specialized hardware; C was and is basically a set of macros to constructs common in assembly languages for most commodity architectures. It worked, in other words, without having to build an entire infrastructure and set of development practices around it.
Later implementations of LISP pretty much solved that problem, but by that time C and its derivatives had already taken over the world.
C was a major improvement on the languages of the day: COBOL, Fortran, and plain assembly. Unlike any of those, it was at the same time fully portable, supported structured programming, and allowed freeform text.
But I don’t think programmers would have embraced LISP even if its performance was as good as the other languages. For the same reasons programmers don’t embrace LISP-derived languages today. It is an empirical fact that the great majority of programmers, particularly the less-than-brilliant ones, dislike pure functional programming.
Note, though, that (a) “Lisp doesn’t look like C” isn’t as much of a problem in a world where C and C-like languages are not dominant, and (b) something like Common Lisp doesn’t have to be particularly functional—that’s a favored paradigm of the community, but it’s a pretty acceptable imperative/OO language too.
“Doesn’t run well on my computer” was probably a bigger problem. (Modern computers are much faster; modern Lisp implementations are much better.)
Edit: still, C is clearly superior to any other language. ;-)
I suspect the main reason lisp failed is the syntax, because the first thing early computer users would try to do is get the computer to do arithmetic. In C/Fortran/etc. you can write arithmetic expressions that look more-or-less like arithmetic expressions, e.g. (a + b/2) ** 2 / c. In Lisp you can’t.
He’s saying that one does not need to do a perfect job to win. A common failure mode is to spend ages worrying about the details while someone else’s good-enough quick hack takes over the world. It’s quite a resonant quote for programmers.
C and Unix obliterated their technically superior rivals. There’s a whole tradition of worrying about why this happened in the still extant LISP community which was one of the principal losers. Look up ‘Worse is Better’ if you’re interested in the details.
I’m aware of all that. But the idea that perfection is not needed, and that successful things are almost always flawed in some way, seemed too obvious to merit a quote.
But that is just typical mind fallacy on my part: if others feel this is an insight people should be reminded of, I shouldn’t argue.
My understanding—and I wasn’t there for that particular holy war, so I might have some of the details wrong—is that while LISP is in many ways the better language, it didn’t at the time have the practical implementation support that C did. Efficient LISP code at the time required specialized hardware; C was and is basically a set of macros to constructs common in assembly languages for most commodity architectures. It worked, in other words, without having to build an entire infrastructure and set of development practices around it.
Later implementations of LISP pretty much solved that problem, but by that time C and its derivatives had already taken over the world.
C was a major improvement on the languages of the day: COBOL, Fortran, and plain assembly. Unlike any of those, it was at the same time fully portable, supported structured programming, and allowed freeform text.
But I don’t think programmers would have embraced LISP even if its performance was as good as the other languages. For the same reasons programmers don’t embrace LISP-derived languages today. It is an empirical fact that the great majority of programmers, particularly the less-than-brilliant ones, dislike pure functional programming.
Note, though, that (a) “Lisp doesn’t look like C” isn’t as much of a problem in a world where C and C-like languages are not dominant, and (b) something like Common Lisp doesn’t have to be particularly functional—that’s a favored paradigm of the community, but it’s a pretty acceptable imperative/OO language too.
“Doesn’t run well on my computer” was probably a bigger problem. (Modern computers are much faster; modern Lisp implementations are much better.)
Edit: still, C is clearly superior to any other language. ;-)
I suspect the main reason lisp failed is the syntax, because the first thing early computer users would try to do is get the computer to do arithmetic. In C/Fortran/etc. you can write arithmetic expressions that look more-or-less like arithmetic expressions, e.g. (a + b/2) ** 2 / c. In Lisp you can’t.
I dislike pure functional programming. I can’t think of a pure functional LISP that isn’t a toy. I’m sure there is one. I wouldn’t use it.
And before we hijack this thread and turn it into a holy war, C is my other favourite language.