He did have access to dedicated single-user machines like that; in fact he built some of them himself with Bart Locanthi a couple of years before. But he had no idea what to do with them, so he programmed them to act as multiwindow terminals for a remote Unix system, running a window system over a serial line. I know that sounds like a joke but it sounds like it was kind of cool — I'd love to play with a Blit (oh hmm, they've released the firmware and an emulator in 9front and 8th Edition Research Unix) — but it also sounds like a real waste of a 68000 to me.
I think the thing he was saying about FTP was when the only copy of a file he wanted was on somebody else's local disk. It sounds like he was doing more stuff with Dorados pretending to be Altos than was normal at the time, and, yes, trying to get them to act like batch-mode programming environments.
(Didn't Cedar's FS support having local files too? Obviously I've never used Cedar, just read papers about it.)
> Didn't Cedar's FS support having local files too? Obviously I've never used Cedar, just read papers about it.
It may have but I only farted around in it bc my real job was in interlisp (plus it was strongly typed iirc which i was allergic to in those days). Yeah, all the D machines booted into an Also mode (which itself was a kind of NOVA).
Even the KL-10 clone (MAXC) had an Alto as its front end processor (real dec ones used a PDP-11!)
There were, barely enough Dorados to go around; I worked mostly at night so I could be sure to get one, but as far as I remember everybody had a console on their desk (keyboard/mouse/bitmapped display). Perhaps, as he was a visitor, he didn't have a desk of his own?
Dorados were ECL machines (so obviously quite expensive), part of a family of D-machines (Dolphin was an earlier, less powerful machine, and the Dandelion workstations (which didn't need to be in a machine room) were later marketed as the Star. Typically you booted up an entire environment (including environment-specific microcode -- I wrote some of that): Smalltalk, Interlisp-D or Cedar/Mesa. Each language environment was a complete OS written in that language.
It's possible that he had previously never had had access to dedicated single user machines like that; by the time I went to PARC I was used to having CADRs at MIT (again, in machine rooms with the consoles in offices) so the concept of these machines was unremarkable in itself.
But what he says about files and FTPing stuff around makes no sense. The environment by 1984 was heavily networked, with the email system (like a modern IMAP environment) entirely client/server living abstractly as a network service. Files lived on fileserver too and opening a remote file was, well, how you did things. Since I didn't have a dedicated machine once I connected to one I simply booted up and had my whole environment available. I never used FTP at all. Similarly what he said about not saving state unless he was using an Alto (or running the big D machines in Alto mode -- then they did have local disk). The other environments all inherently saved state, like a modern iOS or Mac app. Likewise the three environments I mentioned all handled integrated printing as would be familiar to anyone today -- and by 1984 (actually by the late 70s) there were laser printers (Dovers and even color Pengin printers) which were lickety-split; you rarely waited.
In fact his statement "In fact, the whole world outside your machine, Ethernet notwithstanding, is a forbidding world." is cute but inexplicable: not only were various resources available on the net in what we'd call today an any cast (see what I wrote above about grapevine, the mail system) but by 1984 the ARPAnet had switched over to TCP so I routinely transparently used resources from MIT from my Interlisp environment similarly to how you might open a URL in a text editor today.
I agree with what he said about not using text editors in a traditional mode (Interlisp's preferred mode was a structure editor) and indeed it would have been nice to have had 'grep' in Smalltalk!
It reads as if he was unfamiliar with exploratory programming environments (like Smalltalk, Interlisp, and the Lispms). He's clearly trying to map the debug-exit-edit-compile-restart model onto a different paradigm, that of an integrated interpreted-compiled environment. I had the same experience in reverse when I started using Unix: it was weird to me that an error caused the process to exit and dump core; I was used to an error in any application stopping and entering the debugger with all file, process, network etc descriptors all live and inspectable/pokeable and being able to fix the bug in situ and continue. That was the 1970s programming environment I'd learned on.