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.