My encounter with Medley Interlisp
journal.paoloamoroso.com
journal.paoloamoroso.com
At heart, the InterLisp language itself isn't that different from MIT lisps, as Interlisp started down the road at BBN and there was a lot of cross fertilization in both directions. And CommonLisp, while heavily based on the "MIT" model has a lot of Interlisp influence in it.
But as far as the interfaces are concerned things are quite different. Writing code on an "MIT-style" machine was like writing it on the '10: type into an emacs and away you go. Interlisp-D's conception was heavily influenced by the SmallTalk experience: structured rather than text editing, mouse as a primary interface tool, and development based on images rather than files of code. It was much more intensely networked even than most computing today. Although I ultimately still preferred the MIT model, I learned a lot from Interlisp and there are many things I preferred in that environment. The most annoying part for me was the dependence on the mouse.
A nit:
> "The learning curve of such a complex system is steep, almost vertical."
This means you could effectively learn everything overnight. A shallow learning curve is the terrible one: takes a long time to learn.
I'd think the main problem was the underpowered hardware - especially the small address space (both for main and virtual memory) - which was too small for the more challenging Lisp programs and their data. Users moved to Symbolics and also very quick to UNIX based Lisps on SUNs.
> It was much more intensely networked even than most computing today.
I'd like to hear more about that... what was it like?
So the service implementations were smart: located via what was essentially an anycast and contacted via RPC. Everybody needed a client (for mail or whatever) but the implementations were easier.
The MIT style machines were of course networked and rarely had, say, a local filesystem either, but those services were typically provided by a host (typically a PDP-10): basically a client/server model. The D machine environments just treated the (LAN of course) cloud services and not much different from any other local resource. It was easier to write and run shared services in those days than to use websockets today.
Years later when I first encountered a Sun-3 I was shocked to discover it included an entire copy of sendmail and needed it to get the user's mail of the workstation! What an incredibly primitive approach, worse than I had had access to a decade before.
Of course that crappy model survived, but the apparently dominant model of (say) reading your mail is even more retrograde: gmail is just you logging into a remote computer and running a modern version of elm on it to get your mail. In the late 70s D-machine environments you grabbed an object (e.g. mail message) frm the network, maybe presented it to the user, then used it in a reply, and cast it into the void for someone else to take care of. None of the modern siloing which simply recapitulates the worst part of the PC era.
One of the reasons I like digital archeology is the way my degree was all about regarding computing evolution subjects, and we had a proper campus library to go along them, e.g. most published Xerox books.
It's peculiar as so much early CS came from people trained as mathematicians.
(a statement as true in 2023 as it was in 1963?)
This is my pet peeve about Smalltalk and I love Smalltalk. Image basically means a single huge file. It's fine if the IDE lets you navigate inside it when you are working alone. But with multiple authors the issue becomes how do you merge two or more huge files.
Within a file all parts of it must work together. If you have a huge file the number of pairs or parts which must work together is exponentially larger. So merging "images" together is a problem on a class of its own.
But things got tricky when different people use different base-images and it is so easy to create new base-images. When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Combine that with dynamic typing of Smalltalk. Then when you try to move to a different Smalltalk things just don't work and it takes time and effort to figure out why.
I guess the way to do it would be to never save your image, but that is so easy and convenient. But if you never save your image, it is as if you are not using the feature of having the "image", so you can't really say it is a good feature if you never use it.
When you do image-based development it is hard to control what and how many dependencies you create that are dependencies on the image you are currently working in.
Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests.
I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations.
In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image.
IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.
Compared to which other 1980's language?
> … smart team working together.
If the team isn't working together the language isn't the problem.
> Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right…
Compared to porting an app between which other 1980's languages?
Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.
(Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)
You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.
Even back in 1984 pre-ENVY the explicit advice was —
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)
1984 "Smalltalk-80 The Interactive Programming Environment"
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
> When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere.
Why would you do what you describe as "image-based" development when you had ENVY/Developer prerequisites "defining exactly which other code an application expects to access"?
https://www.google.com/books/edition/Mastering_ENVY_Develope...
Wouldn't that be like keeping code in your own personal folder hierarchy when the others were using git?
What guarantees such pre-requisites are accurately documented and abided by?
Again if you never save or switch the image it can't give you too many problems. But what's the benefit of image-based development then?
I think it is like GOTO. You don't need to use GOTO even if your language provides it. But it is a bad idea for a language to provide a GOTO because then many people will use it. and shoot themselves in the foot.
Remember when you used ENVY? You could save the image. You could come back next day and pickup your work where you stopped. Even though all the methods were versioned and shared.
I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on the long term maintainability and integrability of the software.
Say you had your source-code neatly stored and organized in Envy. Then could you just give your Envy-stored source to some developer in the field-office or an open-source collaborator around the world and say: Use this source-code to develop this further? Probably not. You would ALSO have to say by the way you must use this particular version of the base-image. Right?
And then, when there are several divergent base-images for different projects, how do you merge those base-images?
Envy is the cure to the problem that is reliance on the image. Then you say it is great. Yes because of Envy. Not because of the "image".
What exactly do you mean by "having undeclared dependencies" ?
Doesn't the changes file show everything that's been changed, added or removed?
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.
…
The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Incidentally multi-site development (page 89) and remote work (page 312) are discussed in "Mastering ENVY/Developer" but here's the part of your comment that puzzles me: you write this as-if it's some-kind-of gotcha?
> You would ALSO have to say by the way you must use this particular version of the base-image. Right?
To make the build process reproducible we start with the same thing and then add, remove and change stuff. Right?
That wasn't because of ENVY. That was something that would be written as a Smalltalk script — because reproducible.
I also don't like this convention, since it flips dependent-independent variable dichotomy on its head, but it seems to be the widely accepted norm now.
Worst example to me is the common use of the “ugly American” — in the book, he was the good guy who got out there and got dirty, as opposed to the pampered ones who stayed in the green zone, didn’t know any locals, and assumed everything in whatever country they were in was the same as in the ol’ USA, but just broken or corrupt.
I’m not American but I always cringe when I hear this usage. Why do people have to hollow out metaphors, destroying language in the process?
I write a lot about Lisp languages (and I offer free mentoring, and people often ask for Lisp advice) and for most people I actually recommend Racket Scheme as an introduction since it is a batteries included instant install on most platforms and the supplied IDE is pretty good. If anyone gets really interested in using Lisp, the big job is deciding which language and implementation to use. I love Common Lisp (LispWorks, SBCL+Emacs), Scheme (Gerbil, Chez, Gambit), and Haskell (which for some weird reason I think of as a Lisp language).
Sadly, I have none of my old Medley Interlisp code that I did in the early 1980s (I searched my old paperwork looking for program listings - no luck). I thought of writing up a short 50 page "tutorial and fun projects" book on Medley Interlisp, but the idea of starting over from scratch is daunting.
This is rare and great.
2022 Medley Interlisp Annual Report - https://news.ycombinator.com/item?id=34100600 - Dec 2022 (11 comments)
Interlisp Online - https://news.ycombinator.com/item?id=32621183 - Aug 2022 (9 comments)
Larry Masinter, the Medley Interlisp Project: Status and Plans - https://news.ycombinator.com/item?id=25379238 - Dec 2020 (2 comments)
Interlisp project: Restore Interlisp-D to usability on modern OSes - https://news.ycombinator.com/item?id=24075216 - Aug 2020 (24 comments)
The Interlisp Programming Environment (1981) [pdf] - https://news.ycombinator.com/item?id=5966328 - June 2013 (10 comments)
The Interlisp Programming Environment -- nice paper for those building tools - https://news.ycombinator.com/item?id=1889468 - Nov 2010 (1 comment)
Warren was the manager of Sun's Multimedia Group in which I worked on NeWS, and his contributions to programming environments and user interface design at Xerox PARC were important and underrated.
https://en.wikipedia.org/wiki/Warren_Teitelman
>Warren Teitelman (1941 – August 12, 2013) was an American computer scientist known for his work on programming environments and the invention and first implementation of concepts including Undo / Redo,[5] spelling correction, advising, online help, and DWIM (Do What I Mean).
Ten Years of Window Systems - A Retrospective View, by Warren Teitelman:
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
>4.1 INTRODUCTION
>Both James Gosling and I currently work for SUN and the reason for my wanting to talk before he does is that I am talking about the past and James is talking about the future. I have been connected with eight window systems as a user, or as an implementer, or by being in the same building! I have been asked to give a historical view and my talk looks at window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems.
>The talk focuses on key ideas, where they came from, how they are connected and how they evolved. Firstly, I make the disclaimer that these are my personal recollections and there are bound to be some mistakes although I did spend some time talking to people on the telephone about when things did happen.
>The first system of interest is Smalltalk from Xerox PARC.
Alan Kay commented in email on that paper and Warren's under-appreciated work:
>Windows didn’t start with Smalltalk. The first real windowing system I know of was ca 1962, in Ivan Sutherland’s Sketchpad (as with so many other firsts). The logical “paper” was about 1/3 mile on a side and the system clipped, zoomed, and panned in real time. Almost the same year — and using much of the same code — “Sketchpad III” had 4 windows showing front, side, top, and 3D view of the object being made. These two systems set up the way of thinking about windows in the ARPA research community. One of the big goals from the start was to include the ability to do multiple views of the same objects, and to edit them from any view, etc.
>When Ivan went ca 1967 to Harvard to start on the first VR system, he and Bob Sproull wrote a paper about the general uses of windows for most things, including 3D. This paper included Danny Cohen’s “mid-point algorithm” for fast clipping of vectors. The scheme in the paper had much of what later was called “Models-Views-and-Controllers” in my group at Parc. A view in the Sutherland-Sproull scheme had two ends (like a telescope). One end looked at the virtual world, and the other end was mapped to the screen. It is fun to note that the rectangle on the screen was called a “viewport” and the other end in the virtual world was called “the window”. (This got changed at Parc, via some confusions demoing to Xerox execs).
>In 1967, Ed Cheadle and I were doing “The Flex Machine”, a desktop personal computer that also had multiple windows (and Cheadle independently developed the mid-point algorithm for this) — our viewing scheme was a bit simpler.
>The first few paragraphs of Teitelman’s “history” are quite wrong (however, he was a good guy, and never got the recognition he deserved for the PILOT system he did at MIT with many of these ideas winding up in Interlisp).
David Rosenthal (who worked on Andrew, NeWS, X10, X11, and ICCCM) replied:
Alan, thank you for these important details. I’d like to write a blog post correcting my view of this history — may I quote your e-mail?
Is this paper, “A Clipping Divider”:
https://dl.acm.org/doi/10.1145/1476589.1476687
The one you refer to?
David.
Alan Kay replied:
Hi David
Thanks very much! Your blog is a real addition to the history and context needed to really understand and criticize and improve today.
I would like to encourage you to expand it a bit more (even though you do give quite a few references).
I had very high hopes for Sun. After Parc, I wanted something better than Smalltalk, and thought Sun had a good chance to do the “next great thing” in all of these directions. And I think a number of real advances were made despite the “low-pass filters” and exigencies of business.
So please do write some more.
Cheers and best wishes to all
Alan
Don Hopkins replied:
Yeah, it was very sad that Sun ended up in Larry Ellison’s grubby hands. And I sure liked the Sun logo designed by Vaughan Pratt and tilted 45 degrees by John Gage (almost as great as Scott Kim’s design of the SGI logo), which he just sent out to the garbage dump. (At least Facebook kept the Sun logo on the back of their sign as a warning to their developers.)
I truly believe that in some other alternate dimension, there is a Flying Logo Heaven where the souls of dead flying logos go, where they dramatically promenade and swoop and spin around each other in pomp and pageantry to bombastic theme music, reliving their glory days on the trade show floors and promotional videos.
It would make a great screen saver, at least!
-Don
David Rosenthal posted on his blog:
History of Window Systems
https://blog.dshr.org/2021/03/history-of-window-systems.html
>Alan Kay's Should web browsers have stuck to being document viewers? makes important points about the architecture of the infrastructure for user interfaces, but also sparked comments and an email exchange that clarified the early history of window systems. This is something I've wrtten about previously, so below the fold I go into considerable detail.
I archived a discussion that started with Alan's reply to the question "Should web browsers have stuck to being document viewers?":
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, NeWS and HyperCard
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
>Alan Kay answered: “Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).”
https://en.wikipedia.org/wiki/WIMP_(computing)
https://en.wikipedia.org/wiki/DWIM
>Critics of DWIM claimed that it was "tuned to the particular typing mistakes to which Teitelman was prone, and no others" and called it "Do What Teitelman Means" or "Do What Interlisp Means", or even claimed DWIM stood for "Damn Warren's Infernal Machine."
[==>]
>Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else's typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for ‘Damn Warren’s Infernal Machine!'.
>In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost.
>The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type delete *$ twice.
I'd like to put together a demo of DWIM at its best and worst.
DWIM is evolving!
DWIM evolved into ChatGPT!