Why you should be willing to believe that ed(1) is a good editor

October 18, 2018

Among the reactions to my entry on how ed(1) is no longer a good editor today was people wondering out loud if ed was ever a good editor. My answer is that yes, ed is and was good editor in the right situations, and I intend to write an entry about that. But before I write about why ed is a good editor, I need to write about why you should be willing to believe that it is. To put it simply, why you should believe that ed is a good editor has nothing to do with anything about its technical merits and everything to do with its history.

Ed was created and nurtured by the same core Bell Labs people who created Unix, people like Dennis Ritchie and Ken Thompson. Ed wasn't their first editor; instead, it was the end product of a whole series of iterations of the same fundamental idea, created in the computing environment of the late 1960s and early to mid 1970s. The Bell Labs Unix people behind ed were smart, knew what they were doing, had done this many times before, had good taste, were picky about their tools, used ed a great deal themselves, and were not afraid to completely redo Unix programs that they felt were not up to what they should be (the Unix shell was completely redesigned from the ground up between V6 and V7, for example). And what these people produced and used was ed, not anything else, even though it's clear that they could have had something else if they'd wanted it and they certainly knew that other options were possible. Ed is clearly not the product of limited knowledge, imagination, skill, taste, or indifference to how good the program was.

It's certainly possible to believe that the Bell Labs Research Unix people had no taste in general, if you dislike Unix as a whole; in that case, ed is one more brick in the wall. But if you like Unix and think that V7 Unix is well designed and full of good work, it seems a bit of a stretch to believe that all of the Bell Labs people were so uniquely blinded that they made a great Unix but a bad editor, one that they didn't recognize as such even though they used it to write the entire system.

Nor do I think that resource constraints are a convincing explanation. While the very limited hardware of the very earliest Unix machines might have forced early versions of ed to be more limited than prior editors like QED, by the time of V7, Bell Labs was running Unix on reasonably good hardware for the time.

The conclusion is inescapable. The people at Bell Labs who created Unix found ed to be a good editor. Since they got so much else right and saw so many things so clearly, perhaps we should consider that ed itself has merits that we don't see today, or don't see as acutely as they did back then.


Comments on this page:

I think ed fossilized too quickly, before many other Unix features actually appeared. E.g. why can't ed pipe a region through a filter? (Likely because ed was there before pipes.)

Likewise, editing multiple files is tedious without job control (which probably only appeared after the machines had enough memory to support multiple files easily).

By Edward Berner at 2018-10-24 01:41:23:

Kernighan and Plauger's Software Tools in Pascal (1981) has some interesting context at the beginning of chapter 6 on Editing:

All interactive computing systems (and some batch systems) have some form of editing facility, but it is often rudimentary. The ability to do context searches with regular expressions, make global changes, or do arbitrary file I/O is often left out of even "advanced" editors. Those that include these features often have a command syntax so cumbersome that it is largely unused.

The editor we present here is modeled after the latest in a long family of conversational text editors that have achieved wide acceptance. Concern for human engineering dominates the design -- edit tries to be concise, regular, and powerful. Because edit is primarily intended for interactive use, it is streamlined and terse, but easy to use. This is especially important for a text editor: for most users it is the primary interface to the system. (On our Unix system, the editor accounts for fifteen percent of all commands executed, more than three times the nearest competitor.)

They also mention that it is not a full screen editor, and basically say that a full screen editor would be larger and less portable than what they want to tackle within the scope of the book.

By Greg A. Woods at 2018-10-25 15:58:51:

Thanks Edward! I knew there was something somewhere written about the state of editing and the motivations for ed (outside the Unix documentation itself that is). I had completely forgotten that a variant of ed that had been presented in Software Tools.

The quoted text you show is verbatim in the 1976 edition as well.

Written on 18 October 2018.
« When metrics disappear on updates with Prometheus Pushgateway
Link: Vectorized Emulation [of CPUs and virtual machines] »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Oct 18 00:42:26 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.