The traditional Unix view of the world, however, is so attached
to minimalism that it isn't very good at distinguishing between the
adhocity-trap problems of vi and the
optional complexity of Emacs.
|
The reason that vi and emacs never caught on among old-school
Unix programmers is that they are
ugly
.
This complaint may be “old Unix” speaking, but had it not
been for the singular taste of old Unix, “new Unix” would
not exist.
|
|
| --
Doug McIlroy
|
|
Attacks on Emacs by vi users — along with attacks on vi by
the hard-core old-school types still attached to ed — are
episodes in a larger argument, a contest between the exuberance of
wealth and the virtues of austerity. This argument correlates with
the tension between the old-school and new-school styles of
Unix.
The “singular taste of old Unix” was partly a
consequence of poverty in exactly the same way that Japanese
minimalism was — one learns to do more with less most effectively
when having more is not an option. But Emacs (and new-school Unix,
reinvented on powerful PCs and fast networks) is a child of wealth.
|
As, in a different way, was old-school Unix. Bell Labs had enough
resources so that Ken was not confined by demands to have a
product yesterday. Recall Pascal's apology for writing a long
letter because he didn't have enough time to write a short one.
|
|
| --
Doug McIlroy
|
|
Ever since, Unix programmers have maintained a tradition that
exalts the elegant over the excessive.
The central tension in the Unix tradition has always been
between doing more with less and doing more with more. It recurs in a
lot of different contexts, often as a struggle between designs that
have the quality of clean minimalism and others that choose expressive
range and power even at the cost of high complexity. For both sides,
the arguments for or against Emacs have
exemplified this tension since it was first ported to Unix in the
early 1980s.
Programs that are both as useful and as large as
Emacs make Unix programmers uncomfortable
precisely because they force us to face the tension. They suggest
that old-school Unix minimalism is valuable as a discipline, but
that we may have fallen into the error of dogmatism.
There are two ways Unix programmers can address this problem.
One is to deny that large is actually large. The other is to develop
a way of thinking about complexity that is not a dogma.
On this view, the main difference between the shell and
Emacs is that Unix distributors don't ship
all the world's shellscripts along with the shell. Objecting to
Emacs because having a general-purpose
language in it feels like bloat is approximately as silly as refusing
to use shellscripts because shell has conditionals and for loops.
Just as one doesn't have to learn shell to use shellscripts, one
doesn't have to learn Lisp to use Emacs. If
Emacs has a design problem, it's not so
much the Lisp interpreter (the framework part) as the fact that the
mode library is an untidy heap of historical accretions — but
that's a source of complexity users can ignore, because they won't be
affected by what they don't use.
This mode of argument is very comforting. It can be applied to
other tool-integration frameworks, such as the (uncomfortably large)
GNOME and KDE desktop projects. There is some force to it.
And yet, we should be suspicious of any ‘perspective’ that
offers to resolve all our doubts so neatly; it might be a
rationalization, not a rationale.
Therefore, let's avoid the possibility of falling into denial
and accept that Emacs is both useful
and large — that it
is
an argument against
Unix minimalism. What does our analysis of the kinds of complexity in
it, and the motives for it, suggest beyond that? And is there reason
to believe that those lessons generalize?
[an error occurred while processing this directive]
