9 ms·

Doug McIlroy on Unix Taste (2014)

47 points by _acme 10y ago

uudecode 10y ago
This post is about more than emacs/vi. HN title should be renamed "Unix taste" because that is the subject line. I wish more programmers thought like McIlroy. Good taste is rare in programming. He has it.
- dang 10y ago
  Ok, we changed the title from "Doug McIlroy on Emacs/Vi".
signa11 10y ago
> An interesting question is how the corrective of taste manages ever to recenter the exuberance of evolution. can someone please parse this portion of the reply for me ? i think i can get the _glimpse_ of a meaning, but unfortunately don't / cannot grok its complete elegance...
- uudecode 10y ago
  Negative coding. Eliminate cruft. Drop "features". Go small. Stop modifying the same program to do more. Finish. Open to interpretation but that's my take. You use the word "elegance" and I think that's the idea. Alas, software usually does not "evolve" toward elegance. tr -h | wc
  - GFK_of_xmaspast 10y ago
    $ tr -h tr: illegal option -- h usage: tr [-Ccsu] string1 string2 tr [-Ccu] -d string1 tr [-Ccu] -s string1 tr [-Ccu] -ds string1 string2
    - uudecode 10y ago
      That's GNU, I'm guessing. BSD is a little different.
      - GFK_of_xmaspast 10y ago
        TR(1) BSD General Commands Manual TR(1)
        uudecode 10y ago
        FreeBSD. Got it. But not OpenBSD, NetBSD, or Solaris. Interesting how even with a relatively simple utility like tr, changes were made.
- rumcajz 10y ago
  The evolution is opportunistic, it doesn't favour elegant design. Just look at the human body with all its staggering complexity. Software, if written and adjusted incrementally, tends to evolve in similar way. Now, what Mr. McIlroy asks is how can personal taste (i.e. ability of a single person to create small and simple designs) correct that big evolutionary trend.
  - DonaldFisk 10y ago
    Software, if written and adjusted incrementally without refactoring, tends to evolve in similar way.
    - rumcajz 10y ago
      OTOH: http://classicprogrammerpaintings.com/post/143537166294/resolving-technical-debt-accumulated-technical http://classicprogrammerpaintings.com/post/143537166294/reso...
- 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.
cathartes 10y ago
Doug's message brings to mind Chuck Moore, the creator of Forth, who is probably as fierce a "negative" coder as anyone has ever seen, and he extended his approach similarly to his stack-based hardware. Sadly, Forth (in any guise/implementation) has been largely written off by the world, and is probably better considered a divergence in evolution from today's computing trends. But I think the lessons it teaches remain relevant today--its minimalism, similarly "born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities", is breathtaking, even if Forth is no longer quite practical to use in many of today's software/hardware ecosystems.
- DonaldFisk 10y ago
  Here, Chuck complains about bloated C programs: https://web.archive.org/web/20121028010948/http://www.colorforth.com/1percent.html https://web.archive.org/web/20121028010948/http://www.colorf... Of course, even C is a simple, tiny language compared to C++.
mhd 10y ago
If "recentering the exuberance of evolution" means BCPL -> C, then I'm okay with exuberance myself.
rwmj 10y ago
I don't understand his comment about less & wc. It appears to work for me: $ less --help | wc 237 1298 11912
- int0x80 10y ago
  It has a ridiculously big help section. It is a pager!
  - rwmj 10y ago
    So his complaint is that it is well documented and featureful?
    - int0x80 10y ago
      One could say that if a pager needs +1k lines of help, something is wrong. Complexity is usually not good. And never free.
      - rwmj 10y ago
        Is it affecting you adversely in some way? Almost all the time you can write: something or other | less and it does what you expect. The additional features and customization are there if you need them, and hide out of the way when you don't. If he really wants a pager with fewer features, then plenty of others exist, like plain "more": $ more |& wc 20 94 676 But people don't do that. They use less because it's better.
        int0x80 10y ago
        When you do `smthin | less' the other bazilion options are loaded in less, using resources. If you want to have a quick look a the help you can get overwhelmed by all the information. Having so many options in less can be seen as over-engineering. Bloating the system. There are duplicate features, features that probably don't belong in less etc. It goes against the minimalism of Unix. It probably isn't a big deal in this case, but as a general rule being simple and lean is a feature IMO.
int0x80 10y ago
I think a similar example of evolution of tech going wild is the web.
steveklabnik 10y ago
I've been thinking a bit about this lately, with my OS dev hobby. If you look at a project like xv6, and its implementations of the essence of coreutils... compare: https://github.com/mit-pdos/xv6-public/blob/master/cat.c https://github.com/mit-pdos/xv6-public/blob/master/cat.c to http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;h=8c392441b26973372d07fb31dacafa39084e448f;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f... https://github.com/mit-pdos/xv6-public/blob/master/echo.c https://github.com/mit-pdos/xv6-public/blob/master/echo.c to http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/echo.c;h=977bd5f2cb8cf8b22446b70736419cfc4550e860;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f... Or even something like https://github.com/mit-pdos/xv6-public/blob/master/grep.c https://github.com/mit-pdos/xv6-public/blob/master/grep.c That's not exactly to say these things are _better_, mind you: the tools have grown complexity for a reason. Namely, the simple versions are very much ASCII focused, for example... But sometimes, I wonder. I barely use any of the more advanced features of most of my tools anyway. Should I be using some distro or OS which mostly keeps it simple?
- jarcane 10y ago
  grep and regular expressions in general are a great example of something that Unix seems to excel at but that leaves me cold: shitloads of power, but all dependent on learning arbitary syntax by the bucketloads, thus requiring a time investment I just don't have to make. I marvel at and am impressed by the things that clever shell command chains or carefully constructed regexes can do, but the gap between being able to do those things and when you're awkwardly hunting through man pages and 40 year old docs just to do basic things is huge, and I so rarely need to actually do those things that putting that kind of time in is rarely worth it. Is 3 hours to save 5 minutes really worth my time? 99% of my use of grep is just a simple string search. I don't need an entire esoteric programming language to do that.
  - jdub 10y ago
    "arbitrary syntax"… by that implication, isn't all syntax arbitrary? Your 99% use case is handled by "grep needle". You don't need an entire esoteric programming language to do a simple string search.
jalfresi 10y ago
Isn't this what the "Tick-tock" method of releasing meant to resolve - the first phase, the tick, is all about new, bombastic features, the tock is about removing unused features and tidying up the codebase in general and focusing on performance. I always thought it was quite a neat compromise - you get the best of both.
505 10y ago
Perhaps classic McIlroy: calling Emacs and vi "baroque efflorescences totally out of harmony with the spirit of Unix"
- byuu 10y ago
  They are pretty words, for sure, but I'm not sure what "intricately designed blooming flowers" (baroque efflorescences) is supposed to even mean in this context. It feels like a sesquipedalian circumlocution by an ebullient iconoclast :P
  - catnaroek 10y ago
    One of the meanings of “baroque” is “Extravagant, complex, or bizarre, especially in ornamentation”, or so DuckDuckGo tells me: https://duckduckgo.com/?q=define+baroque https://duckduckgo.com/?q=define+baroque. Also see: https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.... And it's pretty clear that McIlroy used “efflorescence” as a metaphor for “proliferation (of features)”. This usage of “bloom” and its synonyms isn't uncommon.
  - 505 10y ago
    Perhaps he's saying vi users should be using ed, and emacsers TECO. Or maybe just magnetised needles.
HugoDaniel 10y ago
Just to complement: he is a notable user of the "sam" editor. http://sam.cat-v.org/ http://sam.cat-v.org/
anentropic 10y ago
great to have my own gut feeling put so eloquently
yuhong 10y ago
I think SVR2 only included vi because it was forced to, right? For fun, look up Mark Horton and terminfo vs termcap.

47 points by _acme 10y ago

This post is about more than emacs/vi. HN title should be renamed "Unix taste" because that is the subject line. I wish more programmers thought like McIlroy. Good taste is rare in programming. He has it.

dang 10y ago
Ok, we changed the title from "Doug McIlroy on Emacs/Vi".

signa11 10y ago

> An interesting question is how the corrective of taste manages ever to recenter the exuberance of evolution. can someone please parse this portion of the reply for me ? i think i can get the _glimpse_ of a meaning, but unfortunately don't / cannot grok its complete elegance...

uudecode 10y ago
Negative coding. Eliminate cruft. Drop "features". Go small. Stop modifying the same program to do more. Finish. Open to interpretation but that's my take. You use the word "elegance" and I think that's the idea. Alas, software usually does not "evolve" toward elegance. tr -h | wc
- GFK_of_xmaspast 10y ago
  $ tr -h tr: illegal option -- h usage: tr [-Ccsu] string1 string2 tr [-Ccu] -d string1 tr [-Ccu] -s string1 tr [-Ccu] -ds string1 string2
  - uudecode 10y ago
    That's GNU, I'm guessing. BSD is a little different.
    - GFK_of_xmaspast 10y ago
      TR(1) BSD General Commands Manual TR(1)
      - uudecode 10y ago
        FreeBSD. Got it. But not OpenBSD, NetBSD, or Solaris. Interesting how even with a relatively simple utility like tr, changes were made.
rumcajz 10y ago
The evolution is opportunistic, it doesn't favour elegant design. Just look at the human body with all its staggering complexity. Software, if written and adjusted incrementally, tends to evolve in similar way. Now, what Mr. McIlroy asks is how can personal taste (i.e. ability of a single person to create small and simple designs) correct that big evolutionary trend.
- DonaldFisk 10y ago
  Software, if written and adjusted incrementally without refactoring, tends to evolve in similar way.
  - rumcajz 10y ago
    OTOH: http://classicprogrammerpaintings.com/post/143537166294/resolving-technical-debt-accumulated-technical http://classicprogrammerpaintings.com/post/143537166294/reso...
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.

cathartes 10y ago

Doug's message brings to mind Chuck Moore, the creator of Forth, who is probably as fierce a "negative" coder as anyone has ever seen, and he extended his approach similarly to his stack-based hardware. Sadly, Forth (in any guise/implementation) has been largely written off by the world, and is probably better considered a divergence in evolution from today's computing trends. But I think the lessons it teaches remain relevant today--its minimalism, similarly "born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities", is breathtaking, even if Forth is no longer quite practical to use in many of today's software/hardware ecosystems.

DonaldFisk 10y ago
Here, Chuck complains about bloated C programs: https://web.archive.org/web/20121028010948/http://www.colorforth.com/1percent.html https://web.archive.org/web/20121028010948/http://www.colorf... Of course, even C is a simple, tiny language compared to C++.

mhd 10y ago

If "recentering the exuberance of evolution" means BCPL -> C, then I'm okay with exuberance myself.

rwmj 10y ago

I don't understand his comment about less & wc. It appears to work for me: $ less --help | wc 237 1298 11912

int0x80 10y ago
It has a ridiculously big help section. It is a pager!
- rwmj 10y ago
  So his complaint is that it is well documented and featureful?
  - int0x80 10y ago
    One could say that if a pager needs +1k lines of help, something is wrong. Complexity is usually not good. And never free.
    - rwmj 10y ago
      Is it affecting you adversely in some way? Almost all the time you can write: something or other | less and it does what you expect. The additional features and customization are there if you need them, and hide out of the way when you don't. If he really wants a pager with fewer features, then plenty of others exist, like plain "more": $ more |& wc 20 94 676 But people don't do that. They use less because it's better.
      - int0x80 10y ago
        When you do `smthin | less' the other bazilion options are loaded in less, using resources. If you want to have a quick look a the help you can get overwhelmed by all the information. Having so many options in less can be seen as over-engineering. Bloating the system. There are duplicate features, features that probably don't belong in less etc. It goes against the minimalism of Unix. It probably isn't a big deal in this case, but as a general rule being simple and lean is a feature IMO.

int0x80 10y ago

I think a similar example of evolution of tech going wild is the web.

steveklabnik 10y ago

I've been thinking a bit about this lately, with my OS dev hobby. If you look at a project like xv6, and its implementations of the essence of coreutils... compare: https://github.com/mit-pdos/xv6-public/blob/master/cat.c https://github.com/mit-pdos/xv6-public/blob/master/cat.c to http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;h=8c392441b26973372d07fb31dacafa39084e448f;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f... https://github.com/mit-pdos/xv6-public/blob/master/echo.c https://github.com/mit-pdos/xv6-public/blob/master/echo.c to http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/echo.c;h=977bd5f2cb8cf8b22446b70736419cfc4550e860;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f... Or even something like https://github.com/mit-pdos/xv6-public/blob/master/grep.c https://github.com/mit-pdos/xv6-public/blob/master/grep.c That's not exactly to say these things are _better_, mind you: the tools have grown complexity for a reason. Namely, the simple versions are very much ASCII focused, for example... But sometimes, I wonder. I barely use any of the more advanced features of most of my tools anyway. Should I be using some distro or OS which mostly keeps it simple?

jarcane 10y ago
grep and regular expressions in general are a great example of something that Unix seems to excel at but that leaves me cold: shitloads of power, but all dependent on learning arbitary syntax by the bucketloads, thus requiring a time investment I just don't have to make. I marvel at and am impressed by the things that clever shell command chains or carefully constructed regexes can do, but the gap between being able to do those things and when you're awkwardly hunting through man pages and 40 year old docs just to do basic things is huge, and I so rarely need to actually do those things that putting that kind of time in is rarely worth it. Is 3 hours to save 5 minutes really worth my time? 99% of my use of grep is just a simple string search. I don't need an entire esoteric programming language to do that.
- jdub 10y ago
  "arbitrary syntax"… by that implication, isn't all syntax arbitrary? Your 99% use case is handled by "grep needle". You don't need an entire esoteric programming language to do a simple string search.

jalfresi 10y ago

Isn't this what the "Tick-tock" method of releasing meant to resolve - the first phase, the tick, is all about new, bombastic features, the tock is about removing unused features and tidying up the codebase in general and focusing on performance. I always thought it was quite a neat compromise - you get the best of both.

505 10y ago

Perhaps classic McIlroy: calling Emacs and vi "baroque efflorescences totally out of harmony with the spirit of Unix"

byuu 10y ago
They are pretty words, for sure, but I'm not sure what "intricately designed blooming flowers" (baroque efflorescences) is supposed to even mean in this context. It feels like a sesquipedalian circumlocution by an ebullient iconoclast :P
- catnaroek 10y ago
  One of the meanings of “baroque” is “Extravagant, complex, or bizarre, especially in ornamentation”, or so DuckDuckGo tells me: https://duckduckgo.com/?q=define+baroque https://duckduckgo.com/?q=define+baroque. Also see: https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.... And it's pretty clear that McIlroy used “efflorescence” as a metaphor for “proliferation (of features)”. This usage of “bloom” and its synonyms isn't uncommon.
- 505 10y ago
  Perhaps he's saying vi users should be using ed, and emacsers TECO. Or maybe just magnetised needles.

HugoDaniel 10y ago

Just to complement: he is a notable user of the "sam" editor. http://sam.cat-v.org/ http://sam.cat-v.org/

anentropic 10y ago

great to have my own gut feeling put so eloquently

yuhong 10y ago

I think SVR2 only included vi because it was forced to, right? For fun, look up Mark Horton and terminfo vs termcap.