back
5 comments
this is my favorite take away from the whole thing:

That need to rewrite is important and often neglected when coding. Modern programming languages, especially object-oriented ones, are interface heavy. This means that before you can make anything happen you need to write down a lot of preliminaries, often making important API decisions before the best design has emerged. Once it does emerge, there's so much written down already that it feels counterproductive to back up and rework the interfaces. These languages create a penalty for rewriting that encourages working around early design mistakes rather than fixing them. I believe this dependence on interfaces before code is a major reason for programs being so much bigger than they used to be.

Interfaces tend to be hard to change, anyway. The more code that relies on them, the harder it is to change them. This includes unit tests. In design, they are supposed to represent the things that aren't anticipated to change anyway, while allowing change in what's hidden behind them. A huge benefit of interfaces not changing is that everyone else who relies on them is safer. One could argue that difficulty in changing interfaces is a net benefit to the platform, as a whole; and this may be one reason why java (harder to change interfaces) has more 3rd party libraries than lisp (easier to change interfaces).

A huge detriment of interfaces, along with other such back-compatibility, is horrible, horrible, inefficient ugly inelegant stupid code. This is the problem that intel's x86 has, windows has, and java has.

It's a bit like "rich people's problems".

> Interfaces tend to be hard to change, anyway...

"taste" matters a lot here imho. starting from a bare minimum set, and growing it organically seems to be one way out of the tar pit.

Sure, but the big problem with a static structure is that once you are down the road the inevitable 'unknown unknowns' creep in, no matter how tastefully you've designed your interfaces (whether they are literally java/c#/etc. interface types, or class definitions, hierarchies, etc.), and it becomes incredibly difficult to modify things without there being a lot of work involved in fixing things up.

I really do think go's 'real interfaces' i.e. types being implicitly convertible to interfaces which have matching method sigs is a tasteful stroke of brilliance, especially for a lowish level language.

On the flip side, I like the fact I can make an interface change and then fix the resulting compiler errors. Sometimes I'll execute the change in such a way as to generate more errors than the direct path. Not sure how it is on saving time, but it helps the programming paranoia.