You could probably replace it with 10k lines or Python or Ruby too, but it would run like shit compared to the C/C++ version, but because this is HN and they are using lisp, this is news.
Not everyone trades efficiency for reliability and comfort. Some people really get to have their cake and eat it too.
I would characterize the differences vs. C++:
1.) substantially slower in all but one case
2.) almost always uses more memory, sometimes drastically more
3.) marginally more compact
The benchmark tests are toy programs that solve a small set of problems under constraints that create a known bias in favor of languages like C++. They are an objective measure of something, but that something is not language performance and compactness is real-world, non-toy programs that solve problems unlike the ones in the game.
Impressions are admittedly not the best way to gauge such things, but they're better than relying on a test that does not make any attempt to address the question at hand.
My personal heuristic is to assume Alioth is roughly right with a largish margin of error, and then look for anecdotal evidence of specific areas that the game does a particularly poor job of reflecting. For Lisps, code size appears to be a large blind spot based on everything I have seen. Lisp's ability to create mini-languages and very high-level abstractions — a large source of its brevity — is pretty much useless on the scale of the Benchmarks Game.
Do you have any other claims that can be checked?
"They" say your thinking is broken:
- if you think it's okay to generalize from particular measurements without understanding what limits performance in other situations;
- if you think it's okay to generalize from particular measurements without showing the measured programs are somehow representative of other situations.
Not attacking you, I'm genuinely curious.
No...? Is there another acceptable answer for this? In which cases is such an "upgrade" slowdown acceptable to the customer?
[EDIT: Changed most to many. But I think arguments about whether or not speed matters are silly in the general case. Arguments about tradeoffs are always going to be so specific to your app that a general argument is fairly meaningless.]
In exactly those cases where the customer cares more about the added benefits (e.g. security, maybe more features) than speed.
For example, I use firefox even though I've noticed that Chrome is snappier because Firefox comes with addons that provide features that I cannot do without. In this case, I have made a tradeoff between speed and features.
CPU is vastly cheaper than programmer time. There is a point where the tradeoff becomes unprofitable, but to prioritize code speed over all else is a recipe for terrible software.
If you're doing number crunching or heavy 3d, then it requires further thought, but if the code in question isn't one of your CPU usage hot points the conciser code is totally worth it.
It depends on how the slowdowns translate to absolute slowdowns in human perceptible time. Which depends very much on the kind of problem, and whether a piece of code is on the "critical path" for anything.