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 Feb 2 at 8:38
  • 1
    MSDOS had a variant named edln (edlin / edline?) for line-editor and it was the same interface as 'ed'. – Kelly S. French Jun 22 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 Jul 14 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 Sep 13 at 16:37
  • Here's a nice video that shows how you developed with a tty and a line editor (not Unix, but still very much the same): youtube.com/watch?v=bGjTZxRdYD8 – tofro Oct 10 at 12:08

14 Answers 14

up vote 90 down vote accepted

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?

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.

  • 13
    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. – Will Hartung Jan 4 at 6:07
  • 32
    "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. – rackandboneman Jan 4 at 12:43
  • 1
    Comments are not for extended discussion; we have an almost unused chat room for that! – wizzwizz4 Jan 5 at 16:44
  • 4
    You would also normally have a full listing of the code base on fanfold paper to refer to. – Neuromancer Jan 5 at 18:55
  • 1
    wow I thought that only blind programmers remember their lines – phuclv Jan 8 at 9:24

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 Jan 4 at 7:23
  • 3
    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 Jan 4 at 16:23
  • 3
    Upvote for typewriter vs. line editor :-). One could continue with typesetting vs. typewriter ... – Peter A. Schneider Jan 4 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. :) – Will Hartung Jan 4 at 19:31
  • 2
    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... – Peter A. Schneider Jan 4 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.

  • 7
    +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 Jan 5 at 4:49
  • 2
    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 Jan 5 at 4:52
  • 2
    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 Jan 5 at 5:00
  • 2
    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... – Solomon Slow Jan 6 at 2:03
  • 1
    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) – Jan Doggen Aug 16 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. – Jim MacKenzie Jan 3 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 Jan 4 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. – Ross Ridge Jan 4 at 1:52
  • @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 Jan 4 at 3:47
  • 1
    @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 Jan 8 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?

Edit

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.

  • 2
    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 Jan 4 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 Jan 5 at 8:27
  • @TonyM It's called a rhetorical question. It's saying "yes they were". – JeremyP Jan 5 at 9:10
  • 1
    Thank you for addressing my rhetorical point with an edit. Clear and justified answers beat rhetoric or sarcasm in friendly discussions. Thanks again. – TonyM Jan 5 at 10:19

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 – Peter Cordes Jan 5 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 Jan 7 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. – Peter Cordes Jan 7 at 15:23

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 Jan 5 at 19: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.

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

  • 1
    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 Jan 8 at 14:08

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.

  • 12
    cat - >a.out right? – kubanczyk Jan 4 at 8:02
  • 1
    Real Programmers – JeremyP Jan 4 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. – Lurker Larry Jan 4 at 12:44
  • 1
    @JeremyP: real programmers edited inodes with a magnet. – Peter Cordes Jan 5 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. – Lurker Larry Jan 6 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.

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 Jan 5 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 Aug 19 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 Aug 19 at 16:37

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)

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.