Hacker News Reader

Comment by azov | Hacker News Reader

One big difference (which the article seems to mostly ignore) is that the shortest project was written by a single developer, while all others were a team effort.

Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage. Even ignoring communication overhead, there might be subtle duplication of code simply because different people choose to do similar things in slightly different ways.

While the ratio of Rust to Python code kind of matches my expectations, I wonder how much of it might be due to the difference in team structure vs the difference in chosen language.

View on HN

These were different teams of students taking a class. Variance in student effort/quality is generally high.

There were two Rust teams. One had 3x the code and passed less tests than the other. This is our only reference for how much noise is owed to team rather than language; no other language was used by more than one team.

Python did best (least amount of code, yet also the most features) less because of Python, but more because the best programmer was using it.

Would the other students have been able to take advantage of the duck typing and metaprogramming in the same way, or ended up following different designs? I'd have my doubts about the second Rust team.

Although that Python allowed these is a feature, but I think we're really just looking at noise.

And then again still, the “best programmer” sacrificed code quality in pursuit of quickly producing features. The article doesn’t define code quality measures but I’d still take the lines of code metric as either not a measure of value in itself or with a massive grain of salt.

That was the right tradeoff for the situation. I think any attempt to use this case study to draw conclusions about maintainability would be a mistake; that's just not what this is useful for.

Hi. I wrote the python implementation. I've had prior experience with compilers and I'm obviously biased but I would say it's quite readable. The main compiler part (without optional features or the LR(1) or lexer generator) is 2040 lines and contains very little magic. It would be easy to translate 1-1 to idiomatic C++ for instance - it would just be much more verbose. eval() is only used by the lexer generator. The metaprogramming could have been avoided by using dataclasses (but the marker used python 3.5).

(To be clear, the optional portions in which I implement SSA, various optimizations, a Hack-style allocator and some ad-hoc codegen is much less readable.)

Sounds really cool! As someone who programs a bit for work to help with automating processes and fun, but is not a computer scientist I'm a little jealous of never having taken a true database, compilers, PLT, or theory of computation course.

It sounds like you and your classmates are top notch and will go on to some pretty freaking cool careers (ex: I'd work at Jane Street if I was not a parent and a lot smarter :)). Out of curiosity, what are the typical places your classmates go upon graduation?

As I have aged, I have learned that duplication of code can become a feature in terms of building redundancy inside of teams. This is one of the reason that "enterprise code" really sucks, but the people turn-over and need to transfer knowledge over generations is more important than minimalism and the power of individuals (sadly).

> […] I have learned that duplication of code can become a feature in terms of building redundancy inside of teams.

Could you elaborate on how this works?

It runs to the idea that perfection is the enemy of good, and how do you change perfection?

In a growth company with massive scale, a system always has some risky red-line, and so it is better to spin up some competing efforts with different perspectives to tackle different needs in different ways.

The key is to have redundancy of people over time and to create multiple thought leaders within a company; this makes it interesting. Then, at a future date, a "re-org" will happen to condense efforts and the real product is having a number of people familiar with the ideas spread across the company.

This makes zero sense for start-ups, but when you are a risk taking company with massive budgets... strategies are interesting. You see this with VCs having stakes in similar investments as well, and the idea is the same... diversify over people rather than perfect minimal code.

> Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage.

It's also a big disadvantage if that one person ever wants to move on. I write this from personal experience; don't be a solo developer on a large project if you can help it.

Reply on news.ycombinator.com