
Interface Builder's Alternative Lisp Timeline (2013) - kick
https://paulhammant.com/2013/03/28/interface-builders-alternative-lisp-timeline/
======
lispm
The video shows an early Interface Builder written in Lisp.

It runs on a Lisp Machine board for the Mac II range: the TI MicroExplorer.
That was a Nubus board with TI's Lisp chip. The Lisp system was originally
developed at MIT and then by LMI. TI had a license and developed their own
range of machines and the software for it for a few years. Beginning of the AI
winter TI closed that business.

The TI Lisp chip was a 32Bit microprocessor designed to run Lisp applications
in compact computers. Earlier Lisp Machines were much larger.

The Lisp Machine inside the Mac had an interface to the Mac OS, so that one
could write Lisp applications on the MicroExplorer with Mac-like user
interfaces.

The software was probably already written in Common Lisp (or ZetaLisp). It was
also ported to the Mac using Common Lisp directly on the MacOS, without
needing a Lisp Machine board. Earlier versions actually originated on the Mac
and were written in LeLisp, a french Lisp dialect.

~~~
gdubs
This comment, and the parent post are perhaps my favorite HN type of content.

Dylan [1] the language underpinning the Newton was also a kind of LISP. Fairly
close timeframe as well. I wonder what the overlap was there; would be
interesting to track the lineage of the LISP contingent at Apple. I would
imagine Alan Kay would have some overlap with those folks as well.

1:
[https://en.m.wikipedia.org/wiki/Dylan_(programming_language)](https://en.m.wikipedia.org/wiki/Dylan_\(programming_language\))

~~~
lispm
Dylan was used in early prototypes of Newton-like systems and an early Newton.
Dylan was a Lisp-derived language (originally with a Lisp-like syntax), mostly
developed in Macintosh Common Lisp and itself. The released Newton MessagePad
product used C++ and NewtonScript (because of extremely small RAMs of just
640kb).

Apple developed lots of new stuff in their Advanced Technology Group (ATG),
which used Lisp in many projects. Lisp was used for Dylan, but even the
prototype for the NewtonScript development environment was written in
Macintosh Common Lisp - and then released in a C+ version.

Alan Kay was there, but Alan was more interested in Smalltalk projects, I'd
guess. But one driving force for Lisp at Apple was Larry Tesler (
[https://de.wikipedia.org/wiki/Larry_Tesler](https://de.wikipedia.org/wiki/Larry_Tesler)
), who also worked with Smalltalk at Xerox Parc. See here:
[http://lispm.de/docs/prefix-
dylan/book.annotated/foreword.ht...](http://lispm.de/docs/prefix-
dylan/book.annotated/foreword.html)

~~~
mikelevins
Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It
also had some features meant to make it easier to generate small, fast
artifacts--for example, it had a module system, and separately-compiled
libraries, and a concept of "sealing" by which you could promise the compiler
that certain things in the library would not change at runtime, so that
certain kinds of optimizations could safely be performed.

Lisp and Smalltalk were indeed used by a bunch of people at Apple at that
time, mostly in the Advanced Technology Group. In fact, the reason Dylan
existed was that ATG was looking for a Lisp-like or Smalltalk-like language
they could use for prototyping. There was a perception that anything produced
by ATG would probably have to be rewritten from scratch in C, and that created
a barrier to adoption. ATG wanted to be able to produce artifacts that the
rest of the company would be comfortable shipping in products, without giving
up the advantages of Lisp and Smalltalk. Dylan was designed to those
requirements.

It was designed by Apple Cambridge, which was populated by programmers from
Coral Software. Coral had created Coral Common Lisp, which later became
Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp.
Coral Lisp was very small for a Common Lisp implementation and fast. It had
great support for the Mac Toolbox, all of which undoubtedly influenced Apple's
decision to buy Coral.

Newton used the new language to write the initial OS for its novel mobile
computer platform, but John Scully told them to knock it off and rewrite it in
C++. There's all sorts of gossipy stuff about that sequence of events, but I
don't know enough facts to tell those stories. The switch to C++ wasn't
because Dylan software couldn't run in 640K, though; it ran fine. I had it
running on Newton hardware every day for a couple of years.

Alan Kay was around Apple then, and seemed to be interested in pretty much
everything.

Larry Tesler was in charge of the Newton group when I joined. After Scully
told Larry to make the Newton team rewrite their OS in C++, Larry asked me and
a couple of other Lisp hackers to "see what we could do" with Dylan on the
Newton. We wrote an OS. It worked pretty well, but Apple was always going to
ship the C++ OS that Scully ordered.

Larry joined our team as a programmer for the first six weeks. I found him
great to work with. He had a six-week sabbatical coming when Scully ordered
the rewrite, so Larry took his sabbatical with us, writing code for our
experimental Lisp OS.

Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was
a radical application builder that has been described as "HyperCard on
Steroids". It was much more flexible and powerful than either HyperCard or
Interface Builder, but Apple never figured out what to do with it. Heck, Apple
couldn't figure out what to do with HyperCard, either.

~~~
gdubs
I know my comment doesn’t add much value to the conversation, but I’d be
remiss if I didn’t say thank you for taking the time to respond here and below
with such interesting history.

~~~
mikelevins
Sure. My memories of Newton, Dylan, and SK8 are fond. I loved working with
them and I like writing about them.

Anyone who wants to pay someone to work on similar things is encouraged to
contact me. :-)

------
robto
This reminds me a bit of hyperfiddle[0], which I've looked at a few times but
never really explored. I know the author (dustingetz) hangs out around here,
and I wonder if any of this interface builder stuff was prior art.

In any case, I wish we had more tools for interactivity these days. I use
emacs and it's given me a taste for what's possible, and I'm excited to see
Guix[1] mature because it has fantastic sympathies with emacs. But it seems
destined to be niche, even though it's such a wonderful vision of what
computing could be.

[0][http://www.hyperfiddle.net/](http://www.hyperfiddle.net/)
[1][https://guix.gnu.org/](https://guix.gnu.org/)

------
mark_l_watson
Great write up.

Denny’s company ExperTelligence sold a product that I wrote in Lisp. He got
Apple to pay for a full page ad in Scientific American for my product. He was
really a lot of fun to work with.

------
pcurve
that video was fascinating and depressing to watch at the same time. I know
it's not apple to apple comparison, but I feel like 30 years of computer
progress should've put us in better place in terms of ease of app dev.

~~~
em-bee
i am reminded of this every time i work with lisp or smalltalk. it feels like
we barely made any progress since half a century ago. at best rust is a form
of progress, and maybe pure functional programming (which lisp isn't),
although the latter feels more like an exploration of boundaries (how pure can
we make functional programming) rather than a technological advancement that
actually helps us write better code.

~~~
0x445442
I'm with the Raskins, the problems derive from interacting with computers via
applications. This may or may not be at the forefront of your mind but your
fondness of Lisp and Smalltalk systems supports my claim. Other systems such
as Oberon fall into this camp but I would also include early PC systems like
the Commodore 64 and DOS machines, even though they loaded individual
applications.

The commonality with these systems is the somewhat ubiquitous interface. I
think this is why power users love the command line. These HCIs reduce the
cognitive load of the application model where there are wildly disparate UIs
to deal with on a continual basis. The growth of "web apps" has made this
exponentially worse on the user because they're not bound by widget tool kits.

I also see modern markers to support the claim. From what I understand, in
China a huge amount of activity on smartphones that we would conduct through
various apps, they conduct through WeChat and WeChat bots. They do this
because it's more convenient and my claim is this is the normie's equivalent
of attempting to push all their computing needs into Emacs.

~~~
scroot
It is absolutely nuts that we don't have a greater diversity of computing
platforms (as we did in 80s 90s) considering we have such widely adopted
standards today that overcome the "compatibility" problems. There's fertile
ground for exploring more Smalltalk/Oberon/Hypercard/Lisp-machine like
computing systems, with the confidence that they will be able to interact in a
meaningful way with the outside world.

Unfortunately, Computer Science continues to train people in Unix.

~~~
0x445442
> It is absolutely nuts that we don't have a greater diversity of computing
> platforms (as we did in 80s 90s)

I'm seeing signs of a possible resurgence here with the reduced cost of PCBs,
FPGAs and the like along with the increased approach-ability to the space.

------
QuamStiver
Nice timeline! As the author of “Action!”, I’ve mused over the years at the
poor quality of interface tools / environments. I’m happy to say that Apple is
on to something with “SwiftUI’. They have completely rethought out a
declarative UI, kept it quite interactive, and made it much easier to build
quality IOS applications.

------
oracle2025
Most of the currently popular frameworks follow the pattern of organizations
that make the case that "Designers" and "Programmers" need to be strictly
separated.

~~~
zozbot234
Interfaces _should_ be strictly separated from the internal application code,
with generic layers between them. To do it otherwise means ending up with a
"big ball of mud" style app, that cannot have its interface redesigned in any
way other than by refactoring it completely.

