Build libraries with a spec, encourage competing implementations.
This is how it's been done for many years in Java land, and it's good; really good. But it does come at a price: change is much, much slower, and eventually people might get impatient and just do their own thing.
The way it works now in Java land, is that a new idea or technology comes along (e.g. web sockets), some projects implement it with no spec, and a couple of years later (hopefully; it sometimes takes much longer) a spec is created, and you get lots of compatible implementations.
Sometimes you want to pull your hair out in frustration at the pace, but sometimes you're so glad to have 4 or 5 high-quality implementations for a standardized API to choose from.
Excellent point! I think it is important to derive specs from working implementations and not the other way around ton begin with. But yes, once the spec is in place change gets harder. Bonus points for having a clear versioning / feature addition & deprecation strategy that allows quick development.
I'm quite happy to rip optimizations out of code whether they be optimizations for speed, extensibility or reusability if -
a) I don't especially need speed, extensibility or reusability at that moment in time
and b) it hurts readability and maintainability.
I love this! To me, nearly every good programming practice either boils down to or is dependent upon eventually picking a nice spec and separating out the implementation. It's not to say that that should be the first step: the first step is often a prototype and learning phase where you discover what a good spec would even look like, but instead that a medium-term goal of any good project should be to spit out one or many formalizations of what to expect this library to be/do.
Jan, was the conference where Yehuda avoided you Froscon a few years ago by any chance? I remember having a chat with him about the issues I was having with Mustache at the time and him hinting at solving all of them in his own project.
We're still using Mustache.js for server side rendering at https://starthq.com even though we experimented with Hogan for a bit, but it proved to be less stable.
> does "clearly, not cleverly" essentially go out the window when the pro programmers get their hands on things?
No.
Mature software tends to accumulate requirements ("1) must work and 2) must be fast and/or small"), that are different than the original requirements ("1) must work and 2) must be easy to modify because I'm still figuring it out").
When those requirements eventually become more important than the original ones, the way you code it changes to match. It's a natural progression.
Top-notch programmers find ways to keep all 3 requirements, to the extent permitted by the problem space.
Though the article is a nice read, I am not sure exactly why the author is mentioning that Yehuda "avoided him during the rest of the conference". I feel that it's highly irrelevant to the article itself, kind of gratuitous and furthermore really seems like a personal opinion rather than something based in facts.
This is how it's been done for many years in Java land, and it's good; really good. But it does come at a price: change is much, much slower, and eventually people might get impatient and just do their own thing.
The way it works now in Java land, is that a new idea or technology comes along (e.g. web sockets), some projects implement it with no spec, and a couple of years later (hopefully; it sometimes takes much longer) a spec is created, and you get lots of compatible implementations.
Sometimes you want to pull your hair out in frustration at the pace, but sometimes you're so glad to have 4 or 5 high-quality implementations for a standardized API to choose from.