Just for fun, here's the famous pic of Gates and Allen using what looks like a Teletype Model 33 [1], and of course Ritchie and Thompson in front of a PDP-11 [2].
For years (decades!) I never understood the purpose of line editors and why VI was such an improvement. Until one day I saw the pic of Gates and Allen and suddenly realized why, and how it worked. You already had a printout of your code (or text) in front of you. If you wanted to edit the text, you used a line editor to rewrite the line it was on. After a while you could print the whole thing again if you needed.
And this is why my TRS-80's BASIC editor worked the same way. It was just like the original time-share version from Dartmouth ported to a microcomputer.
On line-editors, it is bit funny that even the most hard-core cli enthusiastics draw the line there and use some sort of visual editor despite line editors being more pure cli thing. Has anyone seen anyone do any non-trivial coding or other work with line-editors?
I imagine that the code editing experience for blind people might be somewhat comparable to using line-editors? Although especially with hard copy terminals you don't need to keep everything in your head
I doubt many "hard-core cli enthusiasts" desire some sort of digital self flagellation, but instead strive for efficiency. Full screen editors are efficient, and was very quickly adopted when made available.
Line editors prevailed for a long time, not because of user preferences but because they were tiny and was shipped by default. In PC-DOS/MS-DOS edlin.com/exe was what was available until the full screen editor edit.exe shipped some years into the 90s. Almost all home computers came with a variant of BASIC in ROM, which also used line editing (not even with a proper editor but by substitution of whole lines).
I used line editors in the mid 80s on old-at-the-time systems. Some editors supported both line and screen modes, but we didn't have the more expensive terminal which would have allowed screen mode (there were a class of glass ttys with no cursor positioning commands available).
It's pretty easy to get used to line editors, you get used to using the search command to position the cursor on the correct line and change command to modify it. Some friendly line editors include DEC's EDI and EDT (PDP-11) and E (Motorola Exorciser).
UNIX ed is nice in that it has has regex support, but I don't like its side effects- that p, l and i change the cursor line.
I had no use for edlin since screen editors were available on the IBM PC.
I tried but never got used to TECO: this is like a screen editor, but no screen: meaning the cursor could be anywhere in the file, including in the middle of a line and it's up to you remember where it is. Some TECOs had a screen mode where it would show you the buffer and cursor position in one window, but accepted normal TECO commands in a separate command window ("TVI" on TOPS-20 worked like this, EMACS was a TECO extension).
I remember a post on here a while ago arguing for using ed. I think it was mostly about scripting contexts and batch processing, not interactive editing.
Note to anyone with HTTPS-only mode enabled in their browser: that second link won't work because it's only served over HTTP and not the HTTPS link it is replaced by.
> If you wanted to edit the text, you used a line editor to rewrite the line it was on. After a while you could print the whole thing again if you needed.
That's probably also part of why when you used line numbers in early BASIC, you left plenty of numerical gaps, so you didn't have to re-print as often.
I assume it’s also because reusing a line number means losing whatever code was previously there, and if you find a bug and need to add extra code you don’t want to rewrite part of what is correct just to add a few instructions in between, whether on a teletype or on a terminal with a screen.
The BASIC I grew up with (Applesoft Basic) didn't have a built-in command to renumber a program, but it did have a helper tool you could run from disk. Unfortunately, it only updated the number of each line - it didn't update the line number references in commands like GOTO or GOSUB, so it was pretty much useless for any program large enough that you might want to automate renumbering.
Gates actually wrote about the photo in a blog post he wrote after Allen passed away. [1]
> The first time I saw how passionate Paul could get about something, I was in 8th grade. This picture might make you think he was my teacher, but he was actually a sophomore, just a little less than three years older than me.
> This teletype is the thing that brought us together. Our school, Lakeside, held a rummage sale and used the proceeds to buy a teletype terminal. We were obsessed with it. The problem was, it was really expensive to use – 40 dollars an hour! The only way for us to get computer time was by exploiting a bug in the system.
The user interface of the current ChatGPT strikingly reminds me of the classic teleprinter interface. It's fascinating to think that, with a bit of ingenuity, one could potentially retrofit a 1960s teleprinter to interface with the ChatGPT API.
This thought leads me to ponder whether there are ongoing projects aimed at evolving this user interface into something more dynamic and interactive with LLMs. Specifically, I'm curious about initiatives that not only automatically better visualize results beyond Markdown but also "generates" innovative UI components and layouts. These would ideally support richer user interactions, such as touch, clicks, scrolling, and zooming for the input requests. Enhancing the interface in such a manner could revolutionize the way we interact with AI, making it more intuitive and engaging.
For verisimilitude there should be the big pixellated signboard up on a pedestal in the middle of the room, with the giant messages crawling across, and the clackety-clack that the film soundtrack played when the messages crawled.
Messages like "I'm sorry, Dave. I can't recall the ICBMs. Maybe you would like to play today's Wordle?"
If you watch enough B&W films, you can see Baudot code passing by. It's often the visual metaphor of the 40s and 50s for "we are very high tech" -A dead give-away is the low hole count across the tape. 5 holes, not 7+1 (parity)
One of the best examples of Teletypes and paper tape: "The House on 92nd Street".[1] They show a typing reperforator (not clear which model; it's not a Model 14) hammering out
TAKE INTO CUSTODY IMMEDIATELY ALL JAPANESE CLASSIFIED AS DANGEROUS HOOVER <=
ARREST ALL GERMAN NATIONALS KNOWN TO BE SUBERSIVE HOOVER <=
The movie was made with the full approval of J. Edgar Hoover.
(I used to restore old Teletype machines and had a working telegraph office at about ten steampunk conventions.)
Another one to one side, is a hollerith card sorting machine in the original Michael Caine film of "The Ipcress File" -Len Deighton used to refer to tech in the books, and wound up being gifted one of the first word processing systems by a contact somewhere like IBM, to write on: industry noticed he liked the tech.
Nicholas Freeling did the same with CERN/DESY type places and the CAMAC crate in his book "Gadget" -he asked people what you call the kind(s) of tech they used, and they gave him something to use. Could have been "Unibus" and "pdp11"
https://en.wikipedia.org/wiki/TTY disambiguates to Teleprinter, TDD, and Computer_terminal;
but not Terminal_emulator, Virtual_terminal (VT), Pseudoterminal (PTY), or this article
I got my first home computer in 1978 (a NASCOM-1 Z80 kit) and remember that used Teletypes (basically a printer with a keyboard) were still available back then, and more affordable than video terminals such as the VT52. The famous VT100 terminal only came out in 1978 and cost $1500 or so, so wasn't the sort of thing you would use with a $200 home computer.
I was recently thinking of playing with a VT102/220 emulator on a Raspberry Pi as an external 120 col display for a BBC micro. Cheap to do today, but not exactly retro-computing since it would have been prohibitive back in the day.
Decent article. I owned a 5-channel teleprinter for a while in my youth (they were junk at the time, while a real ASR-33 would be worth something). I had to generate baudot code by bit-banging an I/O pin in software because the UARTs even then didn't support 5-bit characters. It smelled of oil. No electronics, only lots of mechanical gubbins and a couple of electromagnets. The key point of the article is that teleprinters pre-date computers by decades; when people built the first computers they stole a teleprinter from down the hall to interact with it; then teleprinters further evolved to meet the computer use-case (transition from baudot to ASCII).
It's a little off-putting that he says punched paper tape was used in the early days of computing. Mostly it was punched paper cards, a different thing entirely.
I thought the use of paper tape was directly related to the teletypes (when used for I/O with a computer). Where the paper tape could operate as both an input and output mechanism, depending on if you wanted to input a program/text or save a program/text. Paper tape wasn’t a computer storage medium, as much as it was a teletype medium.
In this way, the paper tape hijacked the interactive I/O mode on these early computers to supplant it with a stored format.
Interesting - I wasn't aware of that. When I first learnt to program (in PL/1) in the 70's it was on a punched card system, but I never used paper tape myself.
So, was switching from keyboard to tape input, or from printer to tape output, done locally at the teletype, or could that be controlled by the computer it was attached to ?
I guess this implies the paper tape format was basically just a dump/listing of sorts that might otherwise have been directed to the printer, and when used as an input this would then be read into a program (e.g. editor) that was really expecting keyboard (tty) input ?
You could turn on the paper tape punch at any time, and it would record every character sent to the printer. Then you could load the tape into the reader and turn it on and it would act as if you were typing at maximum speed (a whole 10 characters per second!) I don't recall any way to control either function remotely.
Yes, in the early days of microcomputers teletypes were common, and paper tape was a part of that. I'm talking about the computers of the 1960's for example where interactive use was unheard of.
It's not at all a clean separation, but in early computers, paper tape is more common for loading programs than punched cards. The paper tape readers were faster, and the flexible length made more sense for software before compilers were involved. Punched cards were mostly used for application input/output (a very early example would be ENIAC which was not stored-program at all but had punched card I/O) where fixed record sizes made sense, and then later for software due to FORTRAN and contemporaries introducing well-defined statements.
Of course there are plenty of exceptions. I mostly left out punched cards because they have a completely different pre-computer history that could take its own article. One of the reasons people perceive punched cards as far more common than paper tape is because IBM used them heavily (although early IBM machines still tended to use paper tape for loading software). IBM used them heavily because IBM had already been manufacturing punched card equipment for pre-computer data processing. But that's also why early IBM computers supported punched card I/O: for interoperation with their data processing systems. For example, early IBM computers from the '50s even to relatively modern machines in the '70s were often used alongside older punched card data processing equipment. You might categorize records using a punched-card sorter and then feed the sorter bins into a computer for computing statistics, then take the cards output by the computer and put them into a punched card sorter again to order by the computed statistics. This is how might you produce a report of counties with the highest sales, for example. A hybrid of computer and pre-computer methods of processing data. But this emphasizes the difference between paper tape and punched cards: paper tape was continuous, good for variable-length material. Punched cards were discrete, good for fixed-size records that would be binned and sorted during processing.
Later the adoption of IBM punched cards for compiler input radically changed this situation, but that still came out of the sense that input to the compiler consisted of well-defined, discrete records identified by serial number.
You can imagine the practicalities. Machine-language software would not fit neatly onto punched card boundaries, the length of punched cards being historic and not well-correlated with the word size on machines. So there's a weird alignment problem you get that paper tape avoids. Plus you can't accidentally reorder paper tape, an advantage that paper tape equipment manufacturers actively advertised!
A major example relevant to the article is Digital - DEC PDP machines used paper tape for program loading and were rarely equipped for punched cards. This reflects their different heritage and market from IBM machines; Digital machines were less common (and not really designed for) batch record processing applications. Punched cards, on the other hand, are almost intrinsically a batched record format.
Yeah, magnetic tape is almost as old as the programmable computer, with the UNIVAC notably featuring magnetic tape drives. The main downside was that paper tape could be hand-punched using commodity equipment (often teletypes), while magnetic tape couldn't. Magnetic tape was also more expensive initially but I think that cost gap narrowed as paper tape fell out of use. Paper tape was probably becoming uncommon in most mainframe environments by the mid-1960s as the programming modality mostly became punched card source to magnetic tape object. Most IBM mainframes for example could IPL from any input channel, so while a paper tape reader was still a standard option on the 360 series in the mid-'60s, it probably only would have been used by more cash-strapped users. I think IBM generally stopped using paper tape as an exclusive or main I/O format by the end of the '50s. They were ahead of some of their competitors on that, though, probably due to their considerable expertise in both punched cards and magnetic tape.
Some minicomputers continued to use paper tape for initial program loading well into the '70s though, including the PDPs used for Unix development. A number of these computers couldn't "boot" from the tape drives because they were I/O peripherals, while the console and its attendant paper tape punch/reader interacted directly with memory. This arrangement was sometimes called an "autoloader," where you could set a switch and a starting address and everything coming from the console keyboard/reader were put directly into memory sequentially. I have also seen videos of PDP users hand-toggling a program to read from a tape drive into memory; I think that's mostly a flourish for modern demonstrations and contemporary operators would have used the tape reader, but it's not a long enough program to be infeasible.
While reading this article I looked around for some more information on the model 15 teletype he mentioned, and I found this great playlist about how they work, including using it with an Altair 8800 running CP/M and BASIC
Back in the early 80s, on an TTY connected to the campus CDC mainframe, I learned the hard way that the editor command "222d" does not delete line 222. Rather, it deletes the next 222 lines in the file!
Very interesting read, but the author has some peculiar notions about history. Why would is it intriguing that early experimentation with electricity would use clumsy measuring methods, or that the transcontinental telegraph preceded transcontinental telephone in the US by 50 years? It all sounds perfectly logical to me.
For years (decades!) I never understood the purpose of line editors and why VI was such an improvement. Until one day I saw the pic of Gates and Allen and suddenly realized why, and how it worked. You already had a printout of your code (or text) in front of you. If you wanted to edit the text, you used a line editor to rewrite the line it was on. After a while you could print the whole thing again if you needed.
And this is why my TRS-80's BASIC editor worked the same way. It was just like the original time-share version from Dartmouth ported to a microcomputer.
1. https://www.charterworld.com/news/wp-content/uploads/2018/10...
2. http://www.columbia.edu/cu/computinghistory/teletype/ken-and...