I don't really understand this memo. I also worked at PARC when Pike was there though I didn't interact with him or even know he was there. If he hadn't said PARC and Dolphin up front I would have thought he was talking about a completely different place.<p>There were, <i>barely</i> 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?<p>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.<p>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.<p>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.<p>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.<p>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!<p>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 <i>any</i> 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.
I too recall early encounters with Smalltalk (albeit 1989), and also recall that feeling of missing grep - and it was only years later that I realised I had missed a hugely important point... possibly the most important point. Smalltalk is so elegant, malleable and simple that it was only 5 lines of code to implement a more interactive grep... d’oh. Why didn’t I think of it at the time? Too cocky?<p>Code completion was trivial to implement even back then, particularly as code is an object like anything else. Sometimes you miss the obvious and hold yourself back.<p>Sadly the industry hasn’t innovated much since PARC, those much mailigned Smalltalk images are now called Docker ;)
Wow, this is really deep:<p>>One philosophical point is that each window is of a type: a browser, a debugger, a workspace, a bit editor. Each window is created by a special action that determines its type. This is in contrast to our style of windows, which creates a general space in which anything may be run. With our windows, it is easy to get to the outside world; the notion of Unix appears only when a Unix thing happens in the window. By contrast, Smalltalk windows are always related to Smalltalk. This is hard to explain (it is, as I said, philosophical), but a trite explanation might be that you look outwards through our windows but inwards through theirs.
>For example,<p><pre><code> 2 raisedToInteger: 3
</code></pre>
is perfectly readable, but chatty at best.<p>For the life of me I will never understand this opinion. If you're trying to eek out the last bits of memory, fine, verbosity is a valid concern, but at least today code should be written to be read by a human, the more easily it can be read and understood the better.
Fascinating article.<p>meta: There's a <style> tag with 2400 lines (47k+ characters) - a 'Blogger Template Style' - occupying most of the page source. Guess I shouldn't be surprised at the length, but I was. ...What's the record for that sort of thing?