Hacker News new | ask | show | jobs
by codesections 2128 days ago
This serves as an interesting counterpoint to Paul Graham's Beating the Averages[0] essay (which argues for using a powerful programming language as a secret weapon to allow a startup to outperform its competitors).

Reading this list, I'm struck by just how mainstream the languages are. I don't have anything against Python or Ruby, but it'd be hard to describe either as a secret weapon — indeed, about the only "secret weapon" languages on that list are Lisp and Elixir, each of which shows up only once.

[0]: http://www.paulgraham.com/avg.html

5 comments

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.

> Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten

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.

That's one way of looking at it. I tend to prefer the mountaineer's ethos when thinking about goals for grinding out a new application: Getting to the top doesn't count if you can't get safely back down again.
It's a bit different with pre-sale/aquisition than mountaineering, with enough money and therefore ability to hire talent it's not impossible to refactor/split the project or even rewrite as needed once the business value is established. Reddit did it, going from lisp to Python, as did Twitter with microservices, Facebook rewriting a PHP VM, etc.

Startups in your analogy are more akin to: "get to the mountain top and succeed and have the cash to hire a helicopter out of there, or you die (the company)".

“Viaweb sold for a lot of money. It was bad code.”

I think the ultimate test of code is whether it generates money. That is the sole reason the world cares so much about code.

It’s an unpopular definition, and I don’t like it, but it seems correct.

Code should be obvious the the point that anyone taking a glance can say: "I can take it from here". It happened to me once. I was let go from a gig because the code was so darn easy to maintain (Django plugins), that I coded myself out the job.
There's a tendency to optimize for development speed in startups these days, which usually means gluing together lots of dependencies rather than writing things yourself. That pushes developers towards languages with well-established ecosystems.
When he wrote that, he considered Python and especially Ruby as outside of the mainstream and a bit more powerful, too. The mainstream he was comparing against was Java.

I'd say the ecosystem has move considerably in the direction he advocated. Even Java has moved considerably from 2001 Java.

the language isn't the secret weapon - it's the person wielding it. It's just that if the wielder is using a less common language, it makes the news.
Also there's a large selection bias: people using less common or more esoteric/demanding languages tend to be better engineers who have invested the time in learning something off the beaten path. That absolutely does not mean it's the right decision since most employees will statistically be average and you want to have a stack that appeals to a large enough talent pool.
Top-50 billion dollar unicorns are hardly _mainstream_. We might be witnessing the fact that these non-mainstream languages help beating the odds.