Hacker News Reader

Comment by cs702 | Hacker News Reader

Great essay -- I agree with its main point: "worse" products triumph over "the right thing" when they are a better fit for the evolutionary and economic constraints imposed by an evolving competitive landscape.

Some examples:

* In the case of the rise of Unix, the market of the 1960's and 1970's valued simplicity and portability over "correct" design.

* In the case of the rise of the x86 architecture over the past three decades, the market valued compatibility and economies of scale over the simplicity and elegance of competing RISC architectures.

* In the case of the current rise of ARM architectures for mobile devices, today's market values simplicity and low-power consumption over compatibility with legacy x86 architectures.

View on HN

Yes, a great explanation, especially the wrap-up at the end.

You can see how people with too narrow a view of technical design would misconstrue this point. If you're hell-bent on (shallow) perfectionism, you perceive the dichotomy as perfect vs imperfect. One step more healthy is simple vs. complex, because it means you've recognized that time is finite, and too much complexity can legitimately kill a project; it's one of the first real-world constraints on viability that intrudes. "Viability" is really the goal, though, typically, when you include the motivations of the humans involved, like seeing their project be successful and have an impact.

The more you can align your moral compass with viability rather than turning smaller issues into battles between good and evil, the more successful you will be.

Actually, making it simple is often harder. If it where things like the STEPS project[1] would be widespread by now.

Unix didn't won because it was simpler. It won because it was easier to implement. In terms of overall simplicity, Lisp systems were probably far ahead.

[1] The punchline is "Personal computing in 1 book (20KLoC)" Compiler suite included of course. http://www.vpri.org/pdf/tr2011004_steps11.pdf

There were Lisp systems that were simpler than Unix, such as AutoLISP, Scheme, and later XLISP, but the ones that were competing with Unix in the 1970s were things like MACLISP, Zetalisp, and Interlisp, which were much more complex than Unix was at the time. I mean, Zetalisp had its own microcode, its own hypertext documentation, its own GUI, transparent persistence, and a WYSIWYG text editor, at a time when Unix had a couple of C compilers, man pages (its own typesetting system, to be fair), @ and # as the defaults to erase a line and a character, and ed as the standard text editor.

That's just the point, neither imperfection nor simplicity leads to viability, but taking less time and delivering something more appropriate does. You can make something simpler by stopping too soon or thinking too long; make something imperfect by not testing enough or sitting around adding bugs. ;)

> If you're hell-bent on (shallow) perfectionism, you perceive the dichotomy as perfect vs imperfect. One step more healthy is simple vs. complex, because it means you've recognized that time is finite, and too much complexity can legitimately kill a project

What follows is the recognition of the difference between complex and complicated. One can lose time focusing on the complexities, and create a time-consuming complicated system. Or one can build a simple system which allows (or will allow) for complex possibilities (but is not complicated) and shrink down time consumption by a significant margin.

Also, the Web. One of the main reasons Xanadu's in development hell is how it tries to handle broken links. On the Web, the browsers just throw up a 404 error. This is unacceptable for Ted Nelson.

Reply on news.ycombinator.com