|
He wrote that essay nearly 2 decades ago. It was a different world. At the time, the only language with a truly comprehensive open source ecosystem was perl, so, if you were going to work on anything else, there was a decent chance you'd end up writing almost everything yourself. That puts you in a spot where your secret weapon is the language itself. Nowadays, I'd argue that the secret weapon is never the language itself. Ruby's popularity was never about Ruby itself, it was about Rails. Python is, IMO, an ugly hack of a language, but it's still the one I'm always pushing for at work, because its unbelievably lush open source ecosystem means that choosing Python means you'll end up having to do a lot fewer things yourself. Java's was originally about cross-platform deployment, but, now that it's been a decade or so since anyone was actually that worried about interpreted languages, I'd guess it's now more the fact that Java developers are cheap and easy to hire. I'm also honestly not super impressed by Graham's comments on programming languages. Sure, Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten. Graham has done a good job of pitching the idea that this is because people can't understand the obvious genius of Lisp, and I'll admit, as a Lisper, that that story once beguiled me. But, now that I've been around the block a few times, I realize that code that can only be maintained by its own author is never good code, and that sale price is rarely a good proxy for quality (especially when the purchaser is Yahoo!), and that sheer dumb luck plays a much larger part in entrepeneurs' success than any business essayist cares to admit, least of all the ones writing autobiographical essays. |
I think that's because the code after the sale had to meet different requirements than the code before the sale.
Before the sale, the chief requirement, at least from what I gather from pg's essays, was fast implementation of new features. That was the secret weapon, and Lisp was a key enabler for it. The number of people touching the code was very small, so having the code be understandable by others was not a high priority.
After the sale, the chief requirement, I suspect, was maintainability while running at scale. The before-the-sale period had already sufficiently explored the feature space that fast implementation of new features was no longer a requirement, so the advantages of Lisp were no longer crucial. But having code that lots of people could understand and modify reliably was crucial.
So the code had to be rewritten after the sale. That doesn't mean the code before the sale was bad, just that it was tailored to different requirements.