Hacker News Reader

Comment by Jakob | Hacker News Reader

Did you try to rewrite the app in C++ and look on how many percent reduction you get from that second try? I think it’s fair to compare that second app in C++ with the rewrite in another language since a rewrite will likely always be shorter independent of the language.

View on HN

I understood the problem pretty well before writing the C++ version, having done some prototypes beforehand. The C++ version went through some reasonable refactoring too, so it's not like that code was just the first working version that g++ would accept.

I didn't do a full C++ rewrite of course. I think it's fair to say that whenever you are doing lots of concurrency/multithreading/evented stuff in a language like C++, the savings will be enormous when you switch to a language that has a nice concurrency model (ie, not just threads and shared mem and mutexes).

Good point, but it's also not quite a fair comparison to go back and forth between implementation languages.

Changing the language changes your thinking about the problem. If you translate a program from erlang to C++, the result might be shorter and more reliable than if the first version is in C++ and you rewrite it in C++. It also might not be, of course, but the fact that it could be muddles the comparison.

In my own experience, programmers vary more than languages do.

I worked with someone who produced very elaborate designs for the most trivial tasks. Unfortunately, his code was more clever than he was, so it often didn't actually work. Whenever I re-wrote something he'd written in the same language, I managed to do it in 1/10th to 1/15th the number of lines, while adding the "actually works" feature.

it's not that programmers vary - its that the same mistakes are made across the board:

1. memory management is hard - this is mostly a solved problem because the difference between C and $GARBAGECOLLECTEDLANG was great enough that it outweighed most differences in programmer ability. The mass move to web servers put paid to the need to develop for Windows APIs and Linux Syscalls and the a erage software project actually got better. (well ... worked)

1.a. business rules work better in languages that treat functions as first class objects and even better in languages that are logic based and really well in DSLs. most programmers don't reach the first so ... well we await the next mass change if languages.

2. Choice of algorithm. For loops are nice. just not everywhere. O(n^2) hurts. You can see the same in Unindexed table scanning queries.

3. Metrics. measure your own programs. write dynamic do s that update profile information in them. if you are not measuring then ... how do you know you improved? passing another hundred tests does not tell you if those tests measure what is valuable. tests are regression. metrics are progression.

4. I'm ranting too much today, blood pressure is rising :-)

One of the big differences I've seen between better and worse programmers is that the better ones have much greater abilities to create useful abstractions. I've also seen massive decreases in the number of lines of code when rewriting other peoples' code in the same language, and it frequently comes down to the original programmer not having seen that the dozen cases that the code needs to handle are really just the same case with minor differences, and the common behavior can be factored out. The extreme case of this kind of redundancy is copy-and-paste programming, where absolutely identical code is replicated all over the place.

Reply on news.ycombinator.com