
Doug McIlroy on Unix Taste (2014) - _acme
http://minnie.tuhs.org/pipermail/tuhs/2014-August/004890.html
======
cathartes
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
Here, Chuck complains about bloated C programs:
[https://web.archive.org/web/20121028010948/http://www.colorf...](https://web.archive.org/web/20121028010948/http://www.colorforth.com/1percent.html)

Of course, even C is a simple, tiny language compared to C++.

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

~~~
chubot
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
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
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.

~~~
mhd
> The main design idea behind Unix is composition

The _design_ was "strip away as much from Multics to get it running on this
crappy computer". That after a few iterations this might generate a
_philosophy_ of composition is another matter entirely. And I'm not really
arguing against that, at least for a very small subsection of Unix' timeline
(around v5-ish?). But the assumption that this was all a masterstroke of, erm,
intelligent design seems a bit outlandish.

It seems to have been an element of Plan 9's design, though.

And let's not get into "decades of experience" and "empirically". There's way
too few data points and way too much simple economics muddying those waters.
By the same argument I could say that Unix really failed, as the biggest
applications (nay, the systems themselves) on today's variants are quite
monolithic and/or isolated subsystems themselves (browsers, languages, most
servers).

~~~
chubot
Plan 9 was basically more Unix than Unix. More things were files, and more
things were file systems (Networking was done with file systems.)

The design ideas originated with Unix. They were quite explicit, read this
book:
[http://www.catb.org/esr/writings/taoup/html/index.html](http://www.catb.org/esr/writings/taoup/html/index.html)

------
steveklabnik
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...](http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;h=8c392441b26973372d07fb31dacafa39084e448f;hb=HEAD)

[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...](http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/echo.c;h=977bd5f2cb8cf8b22446b70736419cfc4550e860;hb=HEAD)

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

~~~
jarcane
That's exactly the point.

------
HugoDaniel
Just to complement: he is a notable user of the "sam" editor.

[http://sam.cat-v.org/](http://sam.cat-v.org/)

------
uudecode
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
Ok, we changed the title from "Doug McIlroy on Emacs/Vi".

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

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

~~~
byuu
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
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...](https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html).

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.

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

------
rwmj
I don't understand his comment about less & wc. It appears to work for me:

    
    
        $ less --help | wc
            237    1298   11912

~~~
int0x80
It has a ridiculously big help section. It is a pager!

~~~
rwmj
So his complaint is that it is well documented and featureful?

~~~
int0x80
One could say that if a pager needs +1k lines of help, something is wrong.
Complexity is usually not good. And never free.

~~~
mhd
Is the code particularly buggy or inefficient? If not, having a feature that
you don't use doesn't really affect you. There's an argument that lets you
squeeze together multiple blank lines into one. That's arguably superfluous,
as you could pipe your text through a sed/awk/ed/perl/snobol script
beforehand.

I've never used that argument. But I never had less crash on me because of it,
and I don't think it caused a big security impact. If having that command
means that every second procedure in the code has to handle special cases
because of it, then yes, it's probably not worth it. If it's just a few lines
in one place, plus another command line argument parsing section, plus a line
in the docs, then why not?

Extraneous features can cause harm, but one shouldn't be too extremist about
this and consider each case. When it comes to handling text, there are a lot
of special cases that require little code and thus don't really hurt. That's
one of the main reasons why GNU utilities might be considered bloated, but
most of the time it's no big deal beyond philosophy/aesthetics. (I'm sure my
Python/Perl standard lib has a lot of modules I'll never use, too)

On the other hand, I'm not quite sure whether I'll ever need the Tektronix
emulation of xterm...

~~~
benbenolson
This is going against exactly what Doug is arguing, though: Unix taste
includes having many small, perfectly-designed programs to achieve great
power. Adding more and more features to something simple adds complexity, and
therefore, in Doug's opinion, makes it less elegant.

Obviously `less` is a pretty bad example for this, because it's so simple. But
that's his point-- it should just be a pager, that's it. But it doesn't just
do that-- it does a great many other things, has all sorts of arguments that
you can pass to it unnecessarily.

Regarding your xterm comment, you might want to consider the `st` terminal
emulator, a suckless tool. It's really great, consists of one C file, and is
extremely minimal.

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

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

------
anentropic
great to have my own gut feeling put so eloquently

