ed was the standard Unix editor, and is present on all POSIX certified systems (though it's not installed by default in Debian, FWIW).

It's a line editor (meaning, you can't see all the text at a time. You query line numbers and it spits it back, but it came before vi[1], where you can use hjkl to navigate up and down the screen).

How was it used? I find it hard to believe that people memorized their code well enough that they could remember what was going on in line 5 when working on line 20[2]?

Did people write code on a paper and then type it in (sort of like in the punch-card days), editing the paper and then modifying code through ed?

[1]. Small point, ed gave birth to ex, and vi was ex's "visual mode", and ex's legacy is still visible in modern vim/neovim (when you type :COMMAND, like :w, that's vi running an ex command), so ed's legacy is still around to this day.

[2]. Programs weren't too long in the 70s. There just wasn't enough RAM for them. But even a short 20 line program is still too complicated to fully keep in my brain, line by line.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Commented Feb 2, 2018 at 8:38
  • 3
    MSDOS had a variant named edln (edlin / edline?) for line-editor and it was the same interface as 'ed'. Commented Jun 22, 2018 at 16:24
  • Modern gamers use wasd or ijkl to move the entities or to move the background: not very different from using hjkl
    – cup
    Commented Jul 14, 2018 at 21:11
  • One plus of ed and other line editors are that they normally don't keep the whole file in memory, only current line and maybe 10 to 20 lines before and after. So the file can be almost as large as the current disk.
    – UncleBod
    Commented Sep 13, 2018 at 16:37
  • 2
    Re, "I find it hard to believe that people memorized their code well enough..." And yet, some of us are able to work in code bases that have hundreds of thousands or millions of lines of code, using editor windows that can show us no more than a few hundred lines at a time. Commented Sep 9, 2019 at 15:08

19 Answers 19


It's a line editor (meaning, you can't see all the text at a time. You query line numbers and it spits it back, but it came before vi, where you can use hjkl to navigate up and down the screen).

How was it used? I find it hard to believe that people memorized their code well enough that they could remember what was going on in line 5 when working on line 20?

Using a line-based editor isn't that hard.

  • For one, yes, real programmers (as we all were back then) do remember their lines. (*1)
  • Next, when on a writing terminal, one lists the working on section once, so all you need to do to take a look is pull the paper.
  • On a dump terminal one could just issue a list (print) command for the actual range, or ,p for all, as often as needed.

Did people write code on a paper and then type it in (sort of like in the punch-card days), editing the paper and then modifying code through ed?

Yes and no. Before writing a program one sits down and draws a rough structure. Something I'd assume everyone still does today. How else do you get a first glimpse if your idea for a structure is valid? After that, ed (or similar editors on mainframes) is all a programmer needs. A program grows in your head; the screen is just to dump the result, isn't it?

Also, assembling/compiling did usually produce a listing which could be used to go thru on paper (if printed out), add remarks and new lines before hacking them in again. And no, you didn't compile every few seconds and remove just the top warning/error. One worked thru the whole error list before compiling again.

Programs weren't too long in the 70s. There just wasn't enough RAM for them. But even a short 20 line program is still too complicated to fully keep in my brain, line by line.

How are you able to understand your own program if you can't visualize it in the first place? (I'm serious here: I couldn't, and I don't know how it would work otherwise.)

And again, in all seriousness, I worked with line editors over years and on programs with more than 200 lines. In fact, ed already has more features than are absolutely necessary, as edlin has everything you really need to program.

*1 - I can't stop myself from adding a 'little' story about how real programmers remember their code here:

From Grandpa's Vault:

How Real Programmers Remember Code

In the mid '80s (~1985) I was working mostly for a somewhat large, /370 based, mainframe application. At that time the software consisted of about 1.1 million lines of hand written assembly (~1.2M including secondary programs, Only statements, excluding empty lines, etc.). It had its own database engine (*2), screen handling (more than 800 different screen layouts), own editor (*3), own networking stack, own runtime and so on. A typical installation had, at this point about 100-300 full-time users.

The project had been around since the early 1970s. We worked on a policy of no-wrappers, which means only modules were used which we did understand and if necessary were modified to fit the system, and redoing the whole code base every 4-6 years, to avoid ageing code. After all, in a real world application requirements change all the time and so does code. It's a matter of style to avoid rucksack solutions. Nonetheless, 'lint' accumulates over the years and a start over was done every 4-6 years.

At that time we also had scored a new contract with a very promising customer(*4), so a lot of changing and adaptations were needed to incorporate the functionality of two other large scale systems and put them out of business. So a perfect time for a 100% redesign. We were a core team of 4 programmers. Unlike previous times we didn't have a relaxed schedule, but had to implement everything until an already agreed roll-out date, set less than 3 years away. Not cool. We still had (wanted and needed) to go ahead with a total redesign, so management (*5) did assign 14 additional men and we were moved into something like a designer and lead programmer role.

Of course, these were all 'super specialists' and way better than anything we were ... the usual game. And as so often they came up with the same questions, why not use a high level language(*6), a standard DBS and so on. The usual crap. Seriously, with an application of that size, writing such components is just a minor add on. Eventually needing less code than using a standard interface requires - not to mention being faster because being tailored exactly to our needs.

Anyway, let's go for the story. One of these 'specialists', lets call him Mr. W., claimed that no one can oversee such a large codebase, not even partially. Heck, no one can even remember all code written by himself in 5 or more years. Ha! That was a claim that I couldn't let stand uncontested, so one word yielded the next. Bottom line: we agreed for a bet, one beer, that I will be able (he said not able) to identify source name when presented a 10 line snippet, from random programs I did within the existing codebase. We agreed on 10 examples. Date was set the next morning.

Morning came, I didn't prepare nothing, but he came up with a stack of paper and a case of beer. I guess his intention was to show how much I didn't gain by presenting every fail with a bottle. Also, he was so generous as to make the snippets a whole page each. I didn't really need that. I named not only each routine he handed me, but also which module it belonged to, what's the purpose, some workings, why variables are named the way they are, some caller or what was to be found on the pages before or after. Further, I also named the original programer (*7), as he inserted a few pages from programs I didn't write and identified a piece of code that was no longer used, told why and what has replaced it - he pulled it form a very old version :))

The whole case of beer, bottle by bottle, changed sides :))

The same time Mr. W. became more and more quiet. Needless to say that there was no further argument about readability of code or the ability to handle a large code base. Sure, there was still the database fight, but that's a different story.

*2 - Up to 10.000 user transactions per hour with even more DB access per transaction on a 1 MIPS machine with 1.25 MiB RAM - that's mainframe to you :))

*3 A full screen editor on block based terminals. Think of it like ed on steroids. There was no scrolling or alike, but you could edit any of the 20 displayed lines locally before sending that 'page' back to the host to be sorted into the source again (everything was based on sets of libraries, which again worked as a versioning system).

*4 - About a dozen planned installations. For mainframe ERP software, that's like hitting the jackpot, maybe comparable to selling several million copies of a game or such.

*5 - Management also changed at that time, lucky us :(

*6 - Until today, no one could explain to me how Buffer := Record. is supposed to be more readable than MVC BUFFER,RECORD - no, we are not talking C, only real languages were up for decision :)

*7 - Programmers have a 'handwriting' no matter what language is used. There is a way conditions are formed, a likeliness for the selection of field names and so on. When working for some time with others, one clearly knows to 'hear' this like a voice speaking.

  • 31
    The reader should appreciate the 100-300 full time users statistic. Much of that is lost today. We had an installation of our system that supported 150 users. On a 50 MHz 68030. We had special hardware to manage all of the serial traffic, of course. Powerful stuff for the day. Imagine what we could have done with a $20 Raspberry Pi. Commented Jan 4, 2018 at 6:07
  • 48
    "Before writing a program one sits down and draws a rough structure" ... the modern equivalent to that would be writing the outermost control structures straight in your editor, and later fleshing them out. However, probably most people these days will go a different route: Having a very rough concept in their head, and then writing whatever part of the implementation they are right now sure of, simplifying the mental model more and more by dropping what they have already written out of it. Rinse, repeat. Bottom up, in the end. Commented Jan 4, 2018 at 12:43
  • 7
    You would also normally have a full listing of the code base on fanfold paper to refer to. Commented Jan 5, 2018 at 18:55
  • 4
    Yeah, the story should be taken with a pinch of salt. Nobody fully rewrites a working system from scratch "every four to six years" especially if it is a million lines of code long. That's just asking for disaster. If you are doing a rewrite you definitely would not avoid high level languages.
    – JeremyP
    Commented Sep 10, 2018 at 13:12
  • 6
    @JeremyP I guess than My Name Is Nobody :)) Disaster is to continue extending a software for more than 10 years without a redesign. We are talking live software for daily business, not close cases. Every change gets harder until a point is reached where a redesign will free up many resources used to haggle with old code. And (for considerable sized applications and in a mainframe environment) I still can't see a reasoning to switch to a new HLL. That's wasting of resources. You may want to investigate into what Assm on a mainframe means.
    – Raffzahn
    Commented Sep 10, 2018 at 13:33

The reason you can't keep a 20 line program in your head is because you don't have to any more. Same reason you probably don't know any phone numbers.

But back in the day, we certainly did do this. I have written thousands of lines of code and text and documentation using line editors (not ed). At 110, 300, 1200 and 2400 baud. The 2400 baud terminals were nice, but 1200 was completely usable. 300 and 110, not so much - functional, but not preferred. On a single screen which was only 80x24. I never cared for the printing terminals. They were OK, but the glass ttys were so much better.

I used to write English papers on the school mainframe. We had something akin to RUNOFF or troff. You think a line editor is bad, you should try using an actual typewriter some day. The line editor is much better.

My English teacher was kind enough to accept composition papers printed on the back of greenbar.

Many of the habits from line editors carry over to editors like vi and emacs. And old habits die hard. In a line editor you don't simply page or scroll through your code. Rather, you search. It still drives me nuts to watch someone in a code file with hundreds of lines scroll and "aim" for a section of code when they could have simply searched for the function name to get there instantly. At least use the page down key, man!

What I would do, and I can't cite specifics, as I've forgotten the editor commands, and don't know ed), but simply I'd search and then print the next 10 lines.

As you get adept, you quickly learn to string commands together. Search for a line and delete it. Go to a line, make a change, etc. Almost every command I made ended with the "print the line" command so I could see what I did. The editor I used allowed editing commands on the command line so I was able to make changes without actually "entering" the editor.

You could use sed for that today.

sed -i -e '10s/old/new/' file.txt

Go to the 10th line, change the first "old" to "new", and overwrite the file (file.txt).

Today, we are very fortunate in terms of computing resources and powerful code editors and word processors. And we get quite jaded. It is quite difficult to "go back". A single screen, no scroll back, no command history, a line editor, using Ctrl+S and Ctrl+Q to stop and restart output. If any of this sounds terrible to you, it was leaps and bounds above using cards. Cards were terrible.

  • 1
    vi is just a visual version of ed. If you look at the number of hard links to vi, you will see more than 1. The editor starts up in different modes, depending on what it is called.
    – cup
    Commented Jan 4, 2018 at 7:23
  • 4
    I wonder how deeply the phone number analogy goes: I still know the mid-'90s phone numbers of all my teenage friends. Is there a similar effect for those who switched from line editors to document editors? The final few things they needed to memorise eerily remaining decades after the fact, because they developed the skill, used it up to a certain time, and haven't needed it since?
    – Tommy
    Commented Jan 4, 2018 at 16:23
  • 5
    Upvote for typewriter vs. line editor :-). One could continue with typesetting vs. typewriter ... Commented Jan 4, 2018 at 17:22
  • 1
    @PeterA.Schneider Thankfully, my english comp classes needed little more than margins, so I didn't need to get in to typesetting. :) Commented Jan 4, 2018 at 19:31
  • 5
    As an aside, I think programming with cards and then waiting minutes to receive the paper output for each run, just to get a typo diagnosed, was much like writing a thesis with a typewriter. You really thought hard before writing something. When modern word processing and laser printing became available, some time around 1990, a political science teacher remarked that he had never seen such good-looking papers with such a low quality before. I suppose something similar can be said about code. Copy/paste for example was not a good option with cards... Commented Jan 4, 2018 at 19:53

Before the advent of interactive terminals (and version control programs), most programmers were used to keeping their source code on 80-column punched cards. On the first mainframe that I worked on (a Honeywell system), work-flow was typically as follows:

  • Initial source code would be entered on 80-column coding pads, and these would be transferred to punched cards by the punch-room typists. This would be a lot quicker than typing it yourself, even if you had access to a card punch. The punch-room girls (yes, they were all women) would also do paper tape, but this was universally loathed, and was only used for systems that had no card reader.

  • Any edits to your source code would either be done via the punch room, or by yourself if you had a card punch. This might either be a manual card punch (which were readily available), or a punch/interpreter similar to those in the punch room.

  • When you got your program working, you would then store your code in a source code library. Note that this was not a version control system. It simply allowed you to save your working code on disk (and then archive the card deck in a secure cabinet). You then had the option of archiving the entire library on magnetic tape once you had a fully working program.

  • All of the compilers and assemblers would accept standard line editor commands, so that you could modify the code in the source libraries on the fly without having to update them.

  • Once you got your modifications working, you could then update the source code libraries using the standard line editor, and re-archive the library.

  • Edit decks could then either be merged with the original card decks or stored as incremental updates, in case you lost the source code libraries (usually due to disk failure).

The system was cumbersome, but it worked, and the transition to line-oriented terminals was seamless. If you think that this way of working would drive you mad, bear in mind that you would be lucky to get two compiles in a normal working day. Even then, your jobs would be run by operators; you were not allowed to run the jobs yourself since computer time was an expensive commodity. The more knowledgeable operators would correct simple typing errors for you if your compile failed (and they had time to do so).

enter image description here

Manual 80-column card punch

enter image description here

IBM 029 80-column card punch/interpreter

enter image description here

Honeywell Series 60 Level 62 small business computer (circa 1975)

An 80-column card reader can be seen on the far right. This was capable of reading 2,000 cards per minute. An 80-column card punch/interpreter can be seen next to it. I cannot remember its speed, but it was probably around 100 cards per minute. This demo-centre machine lacked 9-track magnetic tape drives. Otherwise, it was fairly similar to our development machine.

  • 11
    +1 THIS! You guys had ed? Hah! My first job (Honeywell Marine Systems Division, West Covina) was punched cards exactly as described above - 3 to 4 day turnaround from the keypunchers, then each developer had hands-on access to the computer twice a week for one hour each time. What did we do while waiting? Well, do the words "desk check" mean anything to you? Probably not, you slackers. Anyhow, @Mick, I did punch my own cards frequently - only one on the team (new college grad) - and even programmed both the 026 and 029! Woohoo! I remember those days - but don't exactly miss them ...
    – davidbak
    Commented Jan 5, 2018 at 4:49
  • 3
    P.S. Just so you know I wasn't a total troglodyte, Harvey Mudd owned a DECSystem10 (KA10, no paging) we could access with 110 baud (then later, 300 baud) terminals (ASR33, ASR43). But that was school. Honeywell was industry!
    – davidbak
    Commented Jan 5, 2018 at 4:52
  • 3
    P.P.S. We didn't use ed on the DEC10 either - that was for lightweights. We used a real editor, a powerful editor, a line editor awesome enough you could write Emacs in it: TECO. (P.P.P.S.: Only attempt to write Emacs in TECO if you're a g**-dam*ed genius!)
    – davidbak
    Commented Jan 5, 2018 at 5:00
  • 3
    Keypunch operators eh? Luxury! We had it tough. We had to cut the chads out with an X-acto knife, and when we went to the RJE station... Commented Jan 6, 2018 at 2:03
  • 2
    Don't forget to use a marker to put diagonal stripes across the top of your card deck (better yet: punch sequential numbers in the cards)
    – user8725
    Commented Aug 16, 2018 at 14:07

You have to remember that 'ed', originally, was as often as not being used on a teletype, not a video terminal, so the line-oriented paradigm made sense. Even then, knowing enough 'ed' to get around files was valuable when, for example, you were using a really dumb terminal (I recall an IBM 3101 that for reasons I forget I was forced to use occasionally that was just easier to use 'ed' on), or when you'd borked up your tty params to the point you couldn't get the full screen editors to work.

  • 2
    We still had DECwriter terminals at the university where I work, back in the 1980s (certainly in 1984, and for a few years after that). We had terminals, too, but a lot of students doing programming liked the DECwriters because you'd get hard copy of all the work you did, which you could take home and study. A line editor was a necessary thing on such machines. Commented Jan 3, 2018 at 23:20
  • My University's CS department had a bunch of ADM-3E terminals, which weren't really what you'd call dumb terminals, except that almost nobody had a termcap entry for them, so any system you tried to use them on outside of the CS department you'd be stuck without full screen capabilities.
    – Jules
    Commented Jan 4, 2018 at 0:30
  • 2
    It was only about 15 years ago I was using ed and putty's local editing mode to work around a really lousy Internet connection.
    – user722
    Commented Jan 4, 2018 at 1:52
  • 2
    @Jules Nop. The ADM3E is the perfect embodyment of a dumb terminal. Its funcionality is exactly like the 3A (hence the name). Cursor movement and positioning are about the only functions 'higher' than with a TTY (+FF for clear screen and LF to scroll). Each and every data was displayed. There are no 'inteligent' features. No formating, no screen manipulation, or beware, block mode. The only part that differs from a 3A (beside screen size and keyboard) is the ability to localy programm strings (data to be send) for function and edit keys (10 total IIRC). Using an ADM 3A termcap is all to do.
    – Raffzahn
    Commented Jan 4, 2018 at 3:47
  • 2
    @KJSeefried Not sure what you try to prove. ADM3A/E are the definition of a dumb terminal. CR, LR, FF plus cursor movement and controll. No interaction possible without the host and ofc, everything is possible_due_ controll by the host.
    – Raffzahn
    Commented Jan 8, 2018 at 3:33

ed was the standard Unix editor, and is present on all POSIX certified systems (though it's not installed by default in Debian, FWIW).

Indeed it was and when I first went to University in 1984, they taught me how to use it. Then they said "there's also vi, type man vi". vi by the way was actually little more than some extensions on another line editor called ex in those days.

By the way, if you were working on a paper teletype (we weren't, we had glass terminals that emulated the VT52), you had to use a line editor.

It's a line editor (meaning, you can't see all the text at a time. You query line numbers and it spits it back

Not true. Each command was prefixed by an address which could be a line number, a range of line numbers or a pattern (if my memory serves correctly). So you could do 1,$p which would print the whole file. On a glass VDU printing the whole file in this way was typically a pointless waste of time because all but the last 25 lines would have scrolled off the top of the screen and there was no scrolling back to find them like you get with modern terminal emulations.

How was it used? I find it hard to believe that people memorized their code well enough that they could remember what was going on in line 5 when working on line 20

Well the situation wasn't much better with full screen editors because you could only see a window of 24 lines (with vi, the bottom line was the command line). The way I used to work was to print off a hard copy of the code periodically and have it beside me on the desk when writing or debugging code. When I changed something, I'd mark up the paper listing, not necessarily with the change but with a mark to remind me that that section was now out of date.

Did people write code on a paper and then type it in

No. At least I didn't. Well, when I got my first job we did that, but that is because our company office didn't have a computer of the right type for the client we were working for. We'd do our debugging and changes on paper using paper listings and then drive to the customer's site to type in the changes.

Programs weren't too long in the 70s

Is that what you think?


In case it is not clear that the above is a flat denial of the assertion that there were no long programs in the 70's, it's fair to say there were long programs. For example, compilers and operating systems tended to be very large. In fact, in the 70's most operating systems were written in assembler meaning the Unix kernel as originally written in assembler would have more lines of source code than the C version (assuming the C version didn't have too many extra features).

Of course, individual source code files could be of arbitrary length and still can be. So, in a 100,000 line program you might have 50 C code files, each 2,000 lines long on average and you still would today.

  • 3
    I didn't program during those times, but even by the time I started, printing out the code regularly was still a common practice - it was quite a bit more comfortable to read and more importantly, add notes. But oh so much paper and ink wasted, the greenheads of today would go crazy :D
    – Luaan
    Commented Jan 4, 2018 at 22:53
  • "Programs weren't too long in the 70s / Is that what you think?" You've written an 'answer', yet replied to a question with a question. Can you edit and make a point there instead or delete that part, please.
    – TonyM
    Commented Jan 5, 2018 at 8:27
  • 5
    @TonyM It's called a rhetorical question. It's saying "yes they were".
    – JeremyP
    Commented Jan 5, 2018 at 9:10
  • 3
    Thank you for addressing my rhetorical point with an edit. Clear and justified answers beat rhetoric or sarcasm in friendly discussions. Thanks again.
    – TonyM
    Commented Jan 5, 2018 at 10:19
  • 1
    I, for one, appreciated the rhetorical tone here.
    – mindthief
    Commented Feb 5, 2021 at 4:10

As a university undergrad in the 1980s we were not allowed to use vi as an editor, only ed, because of the limited resources of the VAX 750 shared by the thousands of undergrads on campus.

It wasn't a problem because you learned how to use your tools. For example, you want to list the lines 1 through 10, you would just type 1,10p (or 1,10n for a numbered listing, or 1,10l to show non-printing character, or...). You had no need to memorize you code, you could just see it on the screen. For larger chunks, you'd just send the whole file to the line printer.

Try using gdb from the command line. It's pretty much the same experience even today.

  • gdb has a TUI mode. (layout src). It's pretty good for debugging asm with layout reg to show a "window" of the registers, highlighting ones that changed since the last update (great while single-stepping): sourceware.org/gdb/onlinedocs/gdb/TUI-Commands.html Commented Jan 5, 2018 at 7:46
  • 1
    @PeterCordes it still leaves much to be desired: it has bad alignment of registers with different-length values (e.g. eax=0x0, ecx=0xabcd1230 — problem inherited form info reg), tui reg float displays FPU registers as st(n), resulting in "all changed" on a step into fstp, ... Sometimes some scripts like gdb-dashboard are much better than built-in TUI: they are much more powerful, while still being text-based, not using ncurses.
    – Ruslan
    Commented Jan 7, 2018 at 15:18
  • @Ruslan: yeah, gdb's TUI stuff is not very good, only pretty good. :P It's nearly garbage for vector regs, because you can't choose what format (16x uint8 vs. 4x float or whatever), so I usually use a display command for them. And it needs a control-L refresh very often because it's crap at not breaking the screen layout. Thanks for the suggestion of gdb-dashboard, will check it out next time I want to debug something. Commented Jan 7, 2018 at 15:23

Blind people still program this way today. Those screenreaders they use are only 120characters wide and 3 lines high. This is for a very expensive model (like the price of a car).

  • 4
    I remember a blind lady using CP/M's ED way into the 90s as personal data base. Including 8 Bit and control characters as abrevations and field delimiters. In fact, ED is next to perfect for the one line 80 character display she had. One entry as one line using the whole 'screen'. Her secretary using a CRT had to learn to recognice weired graphics characters and foreign letters as meaningful codes :))
    – Raffzahn
    Commented Jan 8, 2018 at 14:08

Something not mentioned in other answers here here is that pretty much everyone learning computer programming on microcomputers through the mid-80s used line editing by default. The most common programming language was BASIC, and the most common "editor" was the line-oriented editing system provided as part of the BASIC implementation. You'd use the LIST command with line numbers to see some part of your current program, and retype lines by typing the line number followed by the new code. If you were moderately lucky, you could move your cursor up the screen to a line printed by that LIST command, edit it, and hit ENTER to have it replace that line.

Even when moving to other languages, assembly language being the most common after BASIC, line editing was the general rule. Apple's EDASM and Atari's Assembler Editor cartridge both used line-oriented editors.

So for someone coming from this background (as I did), the general use of ed was no big deal; it was more or less the same as what we'd been doing before. It was just a bit nicer because it had some extra features that weren't always present in microcomputer systems, at least when working in BASIC:

  • You could easily insert new lines, with line numbering being completely automatic. That is, 2i followed by a line of text and . (end input) would make the newly inserted line number 2, and what was line 2 became line 3.
  • Line numbers became "metadata," rather than part of the line itself, as it had been in BASIC.
  • We had the concept of a "current line."
  • We had commands for making specific edits to part of the current line, and we could look at the result and do further edits based on that. (s/foo/baz/p, examine result, try s/baz/bar/p.)
  • We had better commands for moving to a new current line, especially via searching (/foo() to jump to the function definition).

This turns out to be not much different from how an effective Vim user works nowadays anyway, except that you'd manually "print" or "number" some lines on to the screen before entering various editing commands to change them. A typical bit of editing might be:

/^int foo(          Set current line to the function defintion.
                    (The line is printed so you can see it's correct.)
.,.+15n             Print first 15 lines of function with line numbers.
                    (Let's say that the first line printed was 70.)
70s/)/, y)/         Add another parameter to the function
83a                 Append after line 73 (in this example, the last
                    line of the parameter declarations).
int y               Declare type of new parameter
.                   End of input
88i                 Insert new code for new parameter before line 88,
                    which was 87 before inserting the above line

And so on. So just as with modern editors you still had the bit of code you were working on displayed on the screen (not the whole file), you edited based on what was on the screen, and you moved your "viewport" around as you worked on different parts the file. The commands were usually slightly more awkward (.,.+20p instead of Ctrl-F to show the next "page") but not unduly so.

ex was a rather more sophisticated line editor (basically, vi without full screen mode) and offered an easier way of making edits within a line if you were using a "glass TTY," i.e., a screen-based terminal that didn't have an addressible cursor. Called "open mode," it was basically a one-line visual editor that used backspace, carriage return and reprinting of characters to move the cursor around so you could use the standard visual left/right by character and word etc. commands to move back and forth within the line. Moving up or down would simply start a new line on the screen showing the line above or below that you'd moved to.


Cool thread! I thought of something I could contribute, an ed session captured just now, which as I came up with it, reminded me how not bad ed is:

$ ed hello.c
hello.c: No such file or directory
#include <stdio.h>
int main() {
  printf("hello, world!\n");
  return 0;
$ cc -o hello hello.c
$ ./hello
hello, world!

okay, so that could have been done more easily with cat > hello.c, but now let's edit the file:

$ ed hello.c
#include <stdio.h>

int main() {

  printf("hello, world!\n");
  printf("hello again, world!\n");
$ !cc
cc -o hello hello.c
$ ./hello
hello again, world!

that's pretty cool, IMO. Doable over a hard tty with no cursor movement.

  • 4
    Actually, I would have done the second session with /hello (which would move to the line containing that pattern and print it for confirmation; if it were the wrong one I'd type / again to move to the next match) followed by s/,/ again,/p and wq. Two features that made ed considerably easier to use than, e.g., the standard microcomputer BASIC editing systems were the ability to move via searching and easily change part of a line (without arrowing all over the place and mucking with the INS key).
    – cjs
    Commented Sep 9, 2019 at 5:38

Beyond what has already mentioned in other answers, keep in mind that sometimes you know exactly what you need to change and where, especially during the typical edit-compile-test cycle typical of classical software development. Think for example of the output most C compilers give when they hit a compilation error, you get a line number and an excerpt of the line where the error was. In such a case, it's not all that difficult for someone with even a very basic understanding of ed to make the necessary change.


Back in the late 1980s, I worked with multiple infant Unix mutants whose terminal support was an afterthought. If I had to tweak a file, I would telnet in and use a line editor like ex or ed to make the fix. Jumping to a particular line number or searching for a distinct pattern was necessary to navigate large files. Wholesale changes were usually done by ftp, local edit using a screen editor, and ftp back. I do remember struggling with a file that was too large for my screen editor; I may have used a line editor to complete the edits or merely partition the file.

IIRC Real Programmers used

% cat - >foo

not ed to write code.

  • 17
    cat - >a.out right?
    – kubanczyk
    Commented Jan 4, 2018 at 8:02
  • 1
    Real Programmers
    – JeremyP
    Commented Jan 4, 2018 at 10:03
  • 2
    @kubanczyk I have created short shell scripts this way and have watched others type source code using cat. Never saw anyone create a binary this way. Commented Jan 4, 2018 at 12:44
  • 2
    @JeremyP: real programmers edited inodes with a magnet. Commented Jan 5, 2018 at 7:50
  • 3
    @Peter My memory is volatile; my logic, imperfect; and ed is not teco, but together, we got the job done, often without curses. Commented Jan 6, 2018 at 4:57

I started to write my thesis using ed and I got very good at searching for unique words I could remember using. I was on a vdu so I could print out a range of lines to review what I had written or run the scribe compile job and send it to the line printers.

Then we got to upgrade to vi and latex and life became much easier.

  • Did you not go through the nroff/troff stage before latex?
    – cup
    Commented Jun 16, 2020 at 6:38
  • No, we used Scribe initially
    – Ian Turton
    Commented Jun 16, 2020 at 7:49

My first several years of college included a variety of line editors on different systems. Many thousands of lines of code as I wrote 3D image generation and analysis systems. Oddly, the programming devices were old 80x24 text terminals and our high-end graphic output device was a ComRecorder... a $300,000 machine that in fact was nothing but sealed black box containing a tiny color monitor with a Nikon camera pointed at it... (turn on a pixel, cycle the shutter, repeat). Took 26 hours of compute time to generate a 3000x2000 pixel image, then wait 2 days to get the film developed.

One of the line editors of the day was called xedit -- I still call what I do everyday the "xedit-compile-damn" loop.

On keeping code in your head... this was something you could actually do partially because you wrote everything. There were practically no libraries of code you could browse and integrate. The few that existed often needed a complete rewrite to work with your OS or compiler. My story...

I was working on a new Dell 386-based machine in '87 running a flavor of Unix, writing the database admin UI for a barcode scanning system (the back office app for a grocery store). The video card failed in the computer and I continued to edit code, modify the database design, and compile systems for 6 days without ever seeing a single character on the screen until a new video card arrived. This was likely 30-50,000 lines of code spread through a substantial folder structure. That was the mind-muscle-memory you developed from never taking your fingers off the keyboard. The machine was slow, so you were used to typing into a command buffer and being 3-5 commands ahead of what was actually running. It was normal then, but a skill that could never be developed after the mouse became a primary input tool. I certainly couldn't do it today.

  • 1
    That story isn't a particularly good fit for this site... but would make a great blog post. If you want to, you can write one!
    – wizzwizz4
    Commented Jan 5, 2018 at 19:38

As others have said, around 1975-1978 we would write a program by hand on coding pads and send it to the punch room to be punched onto 80-column cards. It would then be taken down to the computer room for the first attempt at compilation; if you were lucky you got the output back 2 hours later. Compilation would always produce a complete line printer listing of the program, complete with line numbers (we used lorry-loads of line printer paper). The compiler error messages would also refer to line numbers, so you could then see where the errors were.

There were then several ways you might apply the corrections (in my case I was using (a) in 1972, (b) in 1975, and (c) in 1978):

(a) punch replacement cards yourself for the incorrect lines, and insert them into the card deck.

(b) punch a set of editing commands into a new deck of cards, and submit a batch job to apply these edits to the disk-based file containing the source code

(c) wait until an interactive terminal became available - initially a teletype, subsequently a VDU that essentially emulated a teletype - and enter the editing commands interactively at the terminal. (Usual practice was to start at the end of the file and work towards the front, so that the line numbers on the line printer listing remained valid as long as possible). Then submit a batch compile job, and wait two hours to get the listing back, generally with a new set of error messages.

By about 1979 we were starting to see editors developed to take advantage of VDU capabilities (vi being a not-particularly-good example); but we carried on using line-oriented editing because once you had memorised all the commands available, it was actually faster.


On the line editor I used (SOS on a DEC-10, ca. 1984), the lines surrounding the line you were working on were visible, and you could scroll back and forth as necessary. It could be disconcerting to see lines appear in reverse order as you scrolled back up through the file, but it was something you got used to relatively quickly. Not quite as speedy as using a mouse and scroll wheel, but not crippling either.

Of course, once we upgraded to a VAX and got screen-based editors (EDT, LSE, etc.), we never looked back.

  • I went to a technical high school in the early/mid 80’s and was fortunate to have a PDP-11 running RSTS/E, but they cheaped out and bought ADM-3A terminals which were not VT52 or VT100 compatible, so we had to use EDT in line mode, much like ed and ex. I was envious of tales of using it in visual mode. I got an internship at a company using Unix and was in heaven with vi.
    – mannaggia
    Commented Jan 5, 2018 at 0:58
  • @mannaggia - your school needed a better terminal definition. My university had a bunch of ADM-3Es, which I understand supported exactly the same control set, and they were able to run full screen editors. Unless I connected offsite, and then everything stopped working, because nobody else had a correct termcap entry for them.
    – Jules
    Commented Aug 19, 2018 at 12:25
  • We weren’t running Unix. As far as I know (and i was just a newbie) RSTS/E and EDT did not have the equivalent of termcap, it only knew DEC terminal codes. Or am I mistaken?
    – mannaggia
    Commented Aug 19, 2018 at 16:37
  • This was also more or less how ex open mode, the "line-oriented" version of visual mode in vi, worked. (It was designed for terminals without full-screen capabilities, the so-called "glass TTYs," which still could generally use backspace and CR for movement within a line.) You could use the standard vi insert/etc. commands and visually see your changes within a single line, but moving to a different line would start a new line on the screen to be edited in the same way.
    – cjs
    Commented Aug 13, 2019 at 16:08

If you are used to a modern editor then it is likely that using ed seems impossible but this applies to many modern items. How did people cope before they existed? You need to try to imagine that computers were new exciting things. They could do things that were previously unimaginable. ed didn't seem hard because we never dreamed of modern editors. If you wanted to program then you learned ed or some similarly limited editor.

In some ways, programs might actually have been bigger in those days, especially Cobol ones, as modular techniques were not so well supported or known. Thousands of lines was not uncommon. We did not memorise whole programs, well at least I didn't, but nonetheless we could usually find our way around successfully.

I have programmed with even more restricted editors. I used to own a Psion Organiser II and I programmed it on the device itself. At the time, I travelled a lot on business and I often wrote programs to pass the time. The display was 2 lines of 16 characters so you typically could not even see a complete line of your program at once. An example of a program that I wrote was a jet lag avoidance clock. I would input the take off time and time zone and the landing time and time zone. It would then run the clock fast or slow depending on whether I was going east or west. So, no sudden time change. A larger program was a costs log for my car, petrol, service, etc, and even depreciation.

Psion Organiser (Wikipedia)


I haven't used 'ed' seriously, but I've used several line-oriented editors: the Eldon 2 'amender' (EE KDF9), the George3 editor (ICL 1900), SOS (TOPS-10, on DECsystem-10). They all are similar editors, though with one significant difference: could you revisit 'previous' lines in the file or not?

The George3 editor/Eldon 2 amender were, if memory serves, single-pass sequential editors; SOS held a 'page' at a time, so you could revisit lines on the same page.

The navigation commands available in all of these were basically 'go to line N' or 'go to the next line containing X'. Then to edit, you got facilities for retyping the entire line, replacing substrings, and various other operations. If you needed to go backwards, this was accomplished by writing out the rest of the file and starting again from the top (depending on editor, there might be a command to do that, otherwise you did it 'manually').

For 'big changes' you might well list the program source on a lineprinter and mark it up, not necessarily with exact changes, but whatever you needed to know what you're doing. For minor stuff, well, you wrote the code, you knew what it looked like. And last week's listing, not entirely accurate now since the code had changed, would be a memory-jogger.

A certain amount of work was done away from the teletype, but this had as much to do with the fact that there were generally more teletype users than teletypes, so you wanted to maximize your efficiency when you got some machine time.

Even TECO, a character-oriented editor rather than a line editor, required similar skills to keep track of whether you are, though it did have the benefit that you could navigate backwards, at least up to the last page boundary/yank command.

So, yeah, in response to the 'how' part of the question: we learned how to work with the tools we'd got, or to come up with incremental improvements within the technological limits of the systems we worked on. Because whatever limits there were on interactive editing, it was much better than working offline with papertape or punchcards.

As regards to programmers remembering their code, or not, I once was fairly sure I could intimately remember up to 3K PDP-11 words of MACRO-11 assembler. This was fine since I was writing kernel code that had to be structured as 'processes' of no more than 4K words (there were several such processes making up the 'program', of course). I can't really remember, but I think that 3K words is about a couple of inches of lineprinter paper.

  • Cool. Only marginal related - have you as well worked with ICL 1501 desktop units?
    – Raffzahn
    Commented Sep 4, 2019 at 0:14
  • 1501, nope. Big iron only(*): 1906A, George 3, MOP teletypes - university computing service. (*) Well, unless you include SIMH :-)
    – dave
    Commented Sep 4, 2019 at 0:27

There is a book Ed Mastery by Michael W Lucas, that might be a good source if you are interested.

I guess, in the beginning it was supposed to be a bit of a joke, but it became useful for connecting the dots and I basically read it in an afternoon and actually used some of the knowledge/ approaches later on professionally.


It's perhaps worth noting that line editors were originally developed for printing teletypes, before addressable CRT terminals were widely available. They did require a certain amount of holding your program file in memory, although you could print out sections of the code. In practice, this was a cognitive skill that programmers using them tended to learn.

Uphill both ways etc. Now get off my lawn.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .