Simplicity, The Art of Unix Programming, and Taekwondo
Posted 02-28-2010 at 05:15 PM by bartonski
My former Taekwondo had a saying "Never do anything in which does not give you an advantage, or reduce your disadvantage". The theory being that doing anything else wastes time and energy, and leaves your opponent open to increase his or her advantage.
Eric Raymond writes in The Art of Unix Programming
I'm a great fan of simplicity. The problem is that simplicity is hard. Figuring out what doesn't need to be there is very difficult. Removing lines of source code requires proving to yourself that what has been removed won't break something else.
Complexity can be covered up using various forms of abstraction: running -print "foo\n";' in perl requires a perl interpreter, written in C, compiled to assembler, assembled to machine code made of microcode executed as binary. Adding layers of abstraction is a very good thing... it means that programmers writing 'print "hello, world\n";' in Perl don't have to worry about which bits to toggle in memory in order to turn on the correct pixels on the screen to form the words 'hello, world'. None the less, these levels of abstraction do incur overhead.
Removing complexity can be a very good decision in terms of marketing and mind-share. The Mozilla web browser did not catch on until it was stripped of its mail client and html editor... at which point it was renamed Firefox, and took off like gang-busters, because people like a clean, fast web browser.
There are counter-arguments to the Unix philosophy that programs should do one thing and do one thing well: Perl, and to a certain extent Emacs have been sited as programs which combine features to become greater than the sum of their parts.
In the end, it comes down, once again, to "Never do anything in which does not give you an advantage, or reduce your disadvantage". There may be tradeoffs between abstraction and performance, between making large tools which have many features or small ones that do one thing well. Choosing correctly when faced with these decisions will give you an advantage, or remove a disadvantage. Choosing badly, or neglecting to make a choice results in a waste of time, energy and effort.
Eric Raymond writes in The Art of Unix Programming
Quote:
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Many pressures tend to make programs more complicated (and therefore more expensive and buggy). One such pressure is technical machismo. Programmers are bright people who are (often justly) proud of their ability to handle complexity and juggle abstractions. Often they compete with their peers to see who can build the most intricate and beautiful complexities. Just as often, their ability to design outstrips their ability to implement and debug, and the result is expensive failure.
Either way, everybody loses in the end.
The only way to avoid these traps is to encourage a software culture that knows that small is beautiful, that actively resists bloat and complexity: an engineering tradition that puts a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces, and that reflexively fights attempts to gussy up programs with a lot of chrome (or, even worse, to design programs around the chrome).
That would be a culture a lot like Unix's.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
‘Big’ here has the sense both of large in volume of code and of internal complexity. Allowing programs to get large hurts maintainability. Because people are reluctant to throw away the visible product of lots of work, large programs invite overinvestment in approaches that are failed or suboptimal.
Many pressures tend to make programs more complicated (and therefore more expensive and buggy). One such pressure is technical machismo. Programmers are bright people who are (often justly) proud of their ability to handle complexity and juggle abstractions. Often they compete with their peers to see who can build the most intricate and beautiful complexities. Just as often, their ability to design outstrips their ability to implement and debug, and the result is expensive failure.
The notion of “intricate and beautiful complexities” is almost an oxymoron. Unix programmers vie with each other for “simple and beautiful” honors — a point that's implicit in these rules, but is well worth making overt.Even more often (at least in the commercial software world) excessive complexity comes from project requirements that are based on the marketing fad of the month rather than the reality of what customers want or software can actually deliver. Many a good design has been smothered under marketing's pile of “checklist features” — features that, often, no customer will ever use. And a vicious circle operates; the competition thinks it has to compete with chrome by adding more chrome. Pretty soon, massive bloat is the industry standard and everyone is using huge, buggy programs not even their developers can love.
-- Doug McIlroy
Either way, everybody loses in the end.
The only way to avoid these traps is to encourage a software culture that knows that small is beautiful, that actively resists bloat and complexity: an engineering tradition that puts a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces, and that reflexively fights attempts to gussy up programs with a lot of chrome (or, even worse, to design programs around the chrome).
That would be a culture a lot like Unix's.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
‘Big’ here has the sense both of large in volume of code and of internal complexity. Allowing programs to get large hurts maintainability. Because people are reluctant to throw away the visible product of lots of work, large programs invite overinvestment in approaches that are failed or suboptimal.
Complexity can be covered up using various forms of abstraction: running -print "foo\n";' in perl requires a perl interpreter, written in C, compiled to assembler, assembled to machine code made of microcode executed as binary. Adding layers of abstraction is a very good thing... it means that programmers writing 'print "hello, world\n";' in Perl don't have to worry about which bits to toggle in memory in order to turn on the correct pixels on the screen to form the words 'hello, world'. None the less, these levels of abstraction do incur overhead.
Removing complexity can be a very good decision in terms of marketing and mind-share. The Mozilla web browser did not catch on until it was stripped of its mail client and html editor... at which point it was renamed Firefox, and took off like gang-busters, because people like a clean, fast web browser.
There are counter-arguments to the Unix philosophy that programs should do one thing and do one thing well: Perl, and to a certain extent Emacs have been sited as programs which combine features to become greater than the sum of their parts.
In the end, it comes down, once again, to "Never do anything in which does not give you an advantage, or reduce your disadvantage". There may be tradeoffs between abstraction and performance, between making large tools which have many features or small ones that do one thing well. Choosing correctly when faced with these decisions will give you an advantage, or remove a disadvantage. Choosing badly, or neglecting to make a choice results in a waste of time, energy and effort.
Total Comments 0
