Hacker News Reader

Comment by jacquesm | Hacker News Reader

That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers.

I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. And there already is one example from a company whose founder I knew that made serious bank on just knowing what they were not, so this advice has applicability far outside of computer programming language design.

Thanks for posting this.

View on HN

> Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use.

One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what not to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing in one thing is the clearest way I know to free up mental capacity for the things I do want to put care into.

I see the value of deciding what not to do for version(s) X of something, but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?

There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on.

Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time the version number is incremented. "Not in the foreseeable future" is effectively understood as a far out roadmap item, no matter how much you don't mean it that way.

I'd rather see a humble "we thought that we would never X, but we were wrong" repeated for many different X than a single misleading "we absolutely commit to not be adding GOTO before 2025".

> Eternity can be surprisingly short when everybody agrees that it is time to move on.

That relies on having a decision-making process and culture that accommodates that. In my current job I'm stuck dealing with inadequate tools because of tool choices made in 2002 that no-one has the political capital to revisit.

In all likelihood an entirely new product will be a better fit in that case, anyway. Especially if whichever direction you do pick completely precludes what you decide not to do.

In practice (and with some experience) most decisions do not prevent revisiting them later.

I believe C would be a good example for negative space. The spirit of C [0] explicitly contains "keep the language small and simple".

[0] http://beza1e1.tuxen.de/articles/spirit_of_c.html

Came here to comment on C. IMHO it remains a gem in the space of languages, probably because it remains small and simple. It has many warts, but it does not suffer in the way C++ does.

People claim Rust is a better C++ and as from my outsider point of view it looks like it is. One of my fears is that it will follow C++ down the very road the author is concerned about.

Small yes.

Simple, only for those that never read ISO C, or tried to write actual portable C code, instead of using gcc C and GNU/Linux everywhere.

Don’t forget secure, too. It can be done, but at what cost.

Reply on news.ycombinator.com