5 ms·

It's essentially design vs. evolution. Evolution has no taste -- it only cares what works. If a system is full of contradictions and inconsistencies and redun

by chubot 10y ago

It's essentially design vs. evolution. Evolution has no taste -- it only cares what works. If a system is full of contradictions and inconsistencies and redundancies, that's OK. What survives is right, by definition. Design implies a coherent intention achieved by a single person or small group of people. Unix was designed by a relatively small group Bell Labs, with a distinct culture. Linux is probably the best example of evolution, and Linus has explicitly pledged his allegiance to this force. The irony is that Linux would have never succeeded if it were a greenfield project; it needed the "bones" of Unix in order not to collapse on itself. It needed the 20+ years of tribal Unix knowledge spread throughout the world. (See "In the Beginning was the Command Line" by Stephenson) I do think McIlroy is right. You need taste to "correct" the ugliness of evolution, at least in software. Evolution is important, but so is design. Like all things, neither extreme is right. Linux exploded on top of the design of Unix. It's time for more design. Here is a good example of design errors Linux has been making, when it has been trying innovate without the lessons of the Unix model: https://lwn.net/Articles/574317/ https://lwn.net/Articles/574317/ "To begin with, he said, much of what is being done with control groups is new; all of it is new to Linux in particular, and some is new in general. So the community did not have any sort of model to follow when designing this new feature."

mhd 10y ago
A lot of the "design" of Unix was just happenstance, though. It didn't start from a tabula rasa, but mostly be reimplementing existing systems within a very constrained environment. And until you arrived at what's recognizably "Unix" for most people, there already was quite some evolution in place (At least V3, probably more V5). Just look at all the ad-hoc languages and semi-languages you've got there. Or the source code for the Bourne shell. roff formating. Then add BSD stuff on top of it (e.g. vi, sockets), the X window system, some more outside stuff (emacs, TeX) and you've got a bewildering plethora of icongruent systems way before Linux even splattered onto the scene. And I would say that McIlroys biggest invention (pipes) is the prime reason why this "mess" actually worked out, by providing a common way to tie these baroque and/or ad-hoc systems together. Unix never was a bright and shiny diamond of singular design beauty (there we'd have to look at language-based systems, IMHO, like Smalltalk, Lisp Machines, Mesa or Oberon). As for editors, well, with any application you end up having to trade simplicity for speed or power. For straight-forward text manipulation, "shelling" out is often a good alternative -- those tools might be arcane and baroque too (it's not like regular expressions are particular intuitive), but at least it's something you can use in other contexts, too. But when it comes to speedy and expedient movement through text and files, it's hard to beat a keyboard. And yes, I've used both acme and sam. Why would a shortcut be the epitome of mystery anyway? Sure, it's not evident on my screen/keyboard etc., but neither is having to use "==" for equality, '.*' for "match some characters" or, heck, these weird English words I'm now typing.
- chubot 10y ago
  I disagree. The main design idea behind Unix is composition. Uniformity enables composition, which means the overall system is smaller and doesn't collapse under its own weight. That means it survives, which we have observed empirically. Composition shows up in the following ways: 1) Everything is a file -- open() / close() / read() / write() are polymorphic, with ioctl() and others for the necessary hacks that don't fit the model. Devices are files; sockets are files; pipes are files; /proc is a file system and not a bunch of C APIs. Compare with Windows. This is not to say there's no cost to this uniformity. There is -- serialization and escaping bugs -- but in practice the benefit seems to have outweighed the cost. You can't underestimate composition, because without it your code collapses under its own weight.) 2) In addition to files composing, file systems compose. mount() is a way of composing a uniform namespace from disparate entities. (Not true under Windows) 3) Processes compose. You can do stuff like "sudo chroot ls ...". fork/exec allows one process to set state for another, without code changes to the child. (Also not true under Windows) 4) Language heterogeneity. Via the simple mechanism of the shebang line, shell can invoke awk/sed/Python/Perl/Ruby/JS in the same way. And the shell itself. (You could call this an instance of the Composite Design Pattern). Unix is certainly messy NOW, but that's because it is so widely used that everyone needed to add their own stuff to it (threads and shared libraries being very popular and arguably anti-Unix). You can try to make something "cleaner", but it will likely collapse under its own weight. There is no uniform model that encompasses all of computing. It's all little truths in specific situations. That's why there are so many little languages. I've had this argument before on HN: Lisp is not a better Unix. Lisp is solving a simpler problem; decades of experience have shown that. Unix is solving a harder problem, doing it in a somewhat simplistic and strained fashion, but it's the best we know how to do right now. Lisp or Smalltalk don't solve the same problem by any stretch of the imagination.
  - pjmlp 10y ago
    UNIX stated getting messy the moment they added sockets and ioctl to it. I really don't know where this ideal model of UNIX lives. All your "not true under Windows" can be extended to all other OSes that aren't UNIX. Windows isn't the only non UNIX OS, although it appears to be like that to most HN eyes.
signa11 10y ago
a nice explanation. thank you ! i do have a follow up question though: > I do think McIlroy is right. You need taste to "correct" the ugliness of evolution, at least in software. Evolution is important, but so is design. Like all things, neither extreme is right. do you think, 'correction' might actually prune some branches in evolution ? but, honestly, i think that is like predicting the future...
- chubot 10y ago
  Yes, design is pruning the "bad" branches of evolution. You are ruling out what you think are bad features / designs. You could be wrong at predicting the future, in which case your system will fail. And that happens all the time. But someone else will succeed (I guess that is another level of evolution, among competing systems rather than evolving features within a system.)

by chubot 10y ago

mhd 10y ago

A lot of the "design" of Unix was just happenstance, though. It didn't start from a tabula rasa, but mostly be reimplementing existing systems within a very constrained environment. And until you arrived at what's recognizably "Unix" for most people, there already was quite some evolution in place (At least V3, probably more V5). Just look at all the ad-hoc languages and semi-languages you've got there. Or the source code for the Bourne shell. roff formating. Then add BSD stuff on top of it (e.g. vi, sockets), the X window system, some more outside stuff (emacs, TeX) and you've got a bewildering plethora of icongruent systems way before Linux even splattered onto the scene. And I would say that McIlroys biggest invention (pipes) is the prime reason why this "mess" actually worked out, by providing a common way to tie these baroque and/or ad-hoc systems together. Unix never was a bright and shiny diamond of singular design beauty (there we'd have to look at language-based systems, IMHO, like Smalltalk, Lisp Machines, Mesa or Oberon). As for editors, well, with any application you end up having to trade simplicity for speed or power. For straight-forward text manipulation, "shelling" out is often a good alternative -- those tools might be arcane and baroque too (it's not like regular expressions are particular intuitive), but at least it's something you can use in other contexts, too. But when it comes to speedy and expedient movement through text and files, it's hard to beat a keyboard. And yes, I've used both acme and sam. Why would a shortcut be the epitome of mystery anyway? Sure, it's not evident on my screen/keyboard etc., but neither is having to use "==" for equality, '.*' for "match some characters" or, heck, these weird English words I'm now typing.

chubot 10y ago
I disagree. The main design idea behind Unix is composition. Uniformity enables composition, which means the overall system is smaller and doesn't collapse under its own weight. That means it survives, which we have observed empirically. Composition shows up in the following ways: 1) Everything is a file -- open() / close() / read() / write() are polymorphic, with ioctl() and others for the necessary hacks that don't fit the model. Devices are files; sockets are files; pipes are files; /proc is a file system and not a bunch of C APIs. Compare with Windows. This is not to say there's no cost to this uniformity. There is -- serialization and escaping bugs -- but in practice the benefit seems to have outweighed the cost. You can't underestimate composition, because without it your code collapses under its own weight.) 2) In addition to files composing, file systems compose. mount() is a way of composing a uniform namespace from disparate entities. (Not true under Windows) 3) Processes compose. You can do stuff like "sudo chroot ls ...". fork/exec allows one process to set state for another, without code changes to the child. (Also not true under Windows) 4) Language heterogeneity. Via the simple mechanism of the shebang line, shell can invoke awk/sed/Python/Perl/Ruby/JS in the same way. And the shell itself. (You could call this an instance of the Composite Design Pattern). Unix is certainly messy NOW, but that's because it is so widely used that everyone needed to add their own stuff to it (threads and shared libraries being very popular and arguably anti-Unix). You can try to make something "cleaner", but it will likely collapse under its own weight. There is no uniform model that encompasses all of computing. It's all little truths in specific situations. That's why there are so many little languages. I've had this argument before on HN: Lisp is not a better Unix. Lisp is solving a simpler problem; decades of experience have shown that. Unix is solving a harder problem, doing it in a somewhat simplistic and strained fashion, but it's the best we know how to do right now. Lisp or Smalltalk don't solve the same problem by any stretch of the imagination.
- pjmlp 10y ago
  UNIX stated getting messy the moment they added sockets and ioctl to it. I really don't know where this ideal model of UNIX lives. All your "not true under Windows" can be extended to all other OSes that aren't UNIX. Windows isn't the only non UNIX OS, although it appears to be like that to most HN eyes.

signa11 10y ago

a nice explanation. thank you ! i do have a follow up question though: > I do think McIlroy is right. You need taste to "correct" the ugliness of evolution, at least in software. Evolution is important, but so is design. Like all things, neither extreme is right. do you think, 'correction' might actually prune some branches in evolution ? but, honestly, i think that is like predicting the future...

chubot 10y ago
Yes, design is pruning the "bad" branches of evolution. You are ruling out what you think are bad features / designs. You could be wrong at predicting the future, in which case your system will fail. And that happens all the time. But someone else will succeed (I guess that is another level of evolution, among competing systems rather than evolving features within a system.)