

Rob Pike: Geek of the Week - signa11
http://www.simple-talk.com/opinion/geek-of-the-week/rob-pike-geek-of-the-week/

======
signa11
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.

~~~
6ren
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".

~~~
signa11
> 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.

~~~
singular
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.

