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.
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.
Comments
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.