Hacker News Reader

Comment by fleitz | Hacker News Reader

Seriously how many people here write programs to solve k-means or n-body problems? Who fucking cares how many lines of code it takes to write k-means, and who fucking cares how long it takes to execute or how much memory it consumes.

Most of us write software that moves bits from an API or DB to a screen. If we're lucky we translate a couple of those values to a color or something.

Why are benchmarks so focused on code no one writes? How many successful YC companies aren't CRUD apps?

Type the problem you have into google, write your stuff in the language that has the most concise stackoverflow answers on how to solve that problem.

View on HN

> Why are benchmarks so focused on code no one writes?

Mostly because, when you're doing something that cares about environmental overhead and compiler efficiency, it tends to involve the kinds of algorithms that benchmarks test with. In other words, benchmarks are designed to provide exactly the information that is useful to the people that need benchmarks. You're absolutely right that isn't the case for web, phone, and applications programmers, and it's true that those people shouldn't pay attention to benchmarks, but there are people out there that care quite a bit.

For example, I write code for humanoid robots. If my code takes more than about half a millisecond to respond to sensor input, my robot will fall over and possibly hurt itself (thousands of dollars of damage) or me (...no thanks). That means that the language and environment I use actually matters - I don't get to have a garbage collector or a high-level runtime VM, to start with. And what algorithms am I running? K-means, n-body, matrix multiplication and inversion, and constraint satisfaction AKA sudoku. As I said, the benchmarks are designed to suit the people that need them.

If you are in the games industry, you solve n-body problems all the time. If it's a multiplayer game, you work with distributed n-body problems. Even if all you did was a CRUD app, if you truly became successful, memory footprint and CPU usage will matter. The 300x slowdown from Ruby will sting. But for everybody else, you're right. None of this is relevant, in the same way that a 5000 hp car engine isn't useful to anybody but Batman.

Personally, I am very fortunate to not think about nothing but CRUD apps all the time. Working with games, all the fun things like sort speed, path finding, etc are real world problems :)

And how many games programmers are thinking.. hmm... should I write my physics engine in ruby?

Zero, but other languages like Haxe, Actionscript, Javascript, and the like are becoming more relevant as higher quality browser games become more prominent.

So, most of us do something so anything else should be ignored?

Not that long ago my main programming tasks were: * plotting some kind of Julia sets and analyzing its properties * high precision computations (>150 significant digits) of invariant manifolds

A lot of people I know are world-class in... N-body stuff.

I somewhat agree. Choosing a programming language involves only a part of the factors listed here (speed, memory, paradigm) but also community, resources, development time and available framework, tooling and libraries.

It is hard to quantify those through and stackoverflow posts and github repos are an insufficient metric

Fully agree, I like the Twitter/Facebook model, write the whole thing in a god awful 'slow' language that's quick to get code out the door, then rewrite in much 'faster' languages once the feature set solidifies.

k-means has enough problems that you (almost) never implement it on its own anyway. If you do, it's generally because you need something now and it's faster than learning how to marshall your data for whatever API you can find on github or sourceforge.

Lots of people have to dig into clustering/mining/stats of the data we gather to figure out how to pull money and from whom.

Exactly. Language Benchmark is probably the most useless and counter-productive place to start talking about language and platform comparison.

This is a bit exaggerated right? When you buy a car, you aren't racing with it, but the amount of time it goes to 60 mph still matters, even if you're looking for fuel efficiency or something else.

Not really. Programming is very different to driving in a straight line.

As an admittedly fairly poor analogy, in programming you generally still have to assemble the car first. Silly things like laying out controls, moving data from/to the db, etc.

Having a really easy to assemble car is still going to take so much more time than the time you spend driving from A to B. So it's much more important. Add on top that you're going to be constantly asked to disassemble it and reassemble it to change the wheel size, etc. because accounting forgot to say that you'd be driving off road.

I'm addressing the point above: "Language Benchmark is probably the most useless and counter-productive place to start talking about language and platform comparison."

This was the point that I completely disagree with. When somebody gives me a new programming language (Julia for example), I'm going to want to know the numbers just so I have that as a baseline understanding. Afterwards sure, I want to know all the bells and whistles the language gives me over C.

Reply on news.ycombinator.com