| > If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. Buying a fast machine only gets you so far. Large C++ projects take minutes to compile even on the fastest machines available. Plus, you'd need to buy one for every developer. > when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X. While this is true in theory, in practice I think the effect is not quite as large. As the project grows, developers take ownership of certain parts of the code and become ignorant of other parts. This is the whole point of abstraction. Under these conditions it will take a heavy investment of time and effort to find and replace the things in common between the two halves. So you might cut 250 lines in common between two 1000-line halves, but you're not going to cut 25,000 lines in common between two 100,000-line halves without a serious amount of work. I think Go's design shows awareness of this effect. The Go literature does not preach the battle against code duplication as strongly as, say, Java. The goal is to make it easy to understand the other team's 100,000 lines, even if that comes at the expense of some code duplication. Note: I am not a Go programmer, but I do think that optimizing for ``code entropy'' (lack of duplicated code) over all else is a mistake. |
Maybe. I find the same patterns tend to show up in a lot of code, so very high-level libraries like scalaz or recursion-schemes (that you can't even think without a powerful type system) turn out to save code virtually everywhere.
> Note: I am not a Go programmer, but I do think that optimizing for ``code entropy'' (lack of duplicated code) over all else is a mistake.
Intuitively it does seem like other things should be more important, but I've become more attached to that measure through experience. Even seemingly innocuous duplication tends to go wrong over time.