
Multi-Language Support in Smalltalk and Historical Lisp Environments - linguae
As of late I&#x27;ve become very interested in learning more about Smalltalk and Lisp machines.  I wasn&#x27;t around when Lisp machines were in their heyday, but I&#x27;ve read a lot of Hacker News comments and websites about them, particularly the machines that Symbolics produced.  I have also played in the Pharo environment.<p>There&#x27;s something very appealing about these &quot;turtles-all-the-way-down&quot; environments where all of the objects in the system are live and can be inspected by using a REPL, and how system behavior can be changed on-the-fly.  A part of me is very interested in taking an environment like Pharo and building some utilities within the environment with the eventual goal of using it as a daily-driver operating system, or at the very least an environment I regularly use on top of an existing operating system like Linux or Windows.<p>However, one question that I have about Smalltalk and historical Lisp machine environments is whether there has been any work done on implementing support for other languages, and what that would look like in these environments.  While I love the appeal of a system in which every program is implemented in the same language, the reason why different languages exist is because some problems can be expressed easier in certain languages.  For example, there are some types of programs that benefit from Haskell&#x27;s strong typing and functional programming approaches and thus would be easier to write in Haskell than in Smalltalk or Lisp.  It would be possible to write some type of Haskell interpreter or compiler that uses Smalltalk&#x27;s or Lisp&#x27;s object model, preserving the &quot;turtles-all-the-way-down&quot; feel of the system despite the fact that the code was written in Haskell instead of Smalltalk or Lisp.  However, I would imagine some limitations to this approach, such as porting a C program to this environment.
======
scroot
> However, one question that I have about Smalltalk and historical Lisp
> machine environments is whether there has been any work done on implementing
> support for other languages

Today's open source Smalltalk VMs are developed in and with Smalltalk itself.
To do this, they use a subset of Smalltalk that can easily be translated to C
called Slang [1]. Additionally, there are several parsing and parser generator
tools designed to allow people to compose DSLs or other languages that can run
in the Smalltalk context, including OMeta [2] which let to Ohm [3],
PetitParser [4], and SmaCC [5].

One could also imagine a mechanism by which a "Smalltalk Machine" could have
an optional method for executing instructions and interacting with memory (at
a low level) that is similar to the way the C world wants, and to compile C
code into this format -- imagine it encapsulated by some special Smalltalk
context object or something.

> There's something very appealing about these "turtles-all-the-way-down"
> environments where all of the objects in the system are live and can be
> inspected by using a REPL, and how system behavior can be changed on-the-
> fly.

I am of the belief that a whole new personal computing system -- from the
hardware on up -- designed around these principles would be of great benefit
to all. It would run directly counter to the current culture of computing,
which says that there are developers and users (scribes and plebs!) and
nothing in between. In fact, the people who had the greatest qualitative input
into the development of personal computing specifically thought that users
would be programmers, and therefore programming would need to be something a
bit different than it had been up until that time, and so would the computing
environment and all the rest (some of these people invented Smalltalk).

The major impediments to doing such a thing are time, money, and worldview.
Most developers today, or "computer people" who should presumably be in the
know, likely aren't very familiar with, if at all, these environments. There
is a very ingrained idea about "how things should be done" that is mistakenly
equivocated with "how things have to be done." There is also limited funding
for these endeavors. The business world is not set up to make these kinds of
leaps these days (short-termism and shareholder primary have dominated
enterprize thinking since the late 70s). I've said before on here that FOSS is
also not the solution: you need long periods of time and lots of money to make
something like this (as history shows), and people doing things in their free
time isn't going to cut it. Case in point: FOSS is for the most part premised
on Unix, because that's what was around and available for free when the
movement started. All "new OSes" are some form of Unix because it is
impossible for people to think outside of that context given the limited
resources available to them.

I will end this rant (sorry) with a couple of refs. The first is to the CogNOS
project, which was at one point an effort to get the OpensmalltalkVM running
on bare metal [6]. I do now know the current status. The second is to Lukas
Hartmann's Reform laptop project. Notable for being an entirely open hardware
and software platform, he began the project because he wanted to build a
custom machine for his own Lisp OS called Interim [7]. When I last asked him
about it, he said that he still has a goal of getting Interim to run on the
machine. But, of course, it's taken him years of work to even get to the point
he's at now.

[1] [http://wiki.squeak.org/squeak/slang](http://wiki.squeak.org/squeak/slang)

[2] [https://en.wikipedia.org/wiki/OMeta](https://en.wikipedia.org/wiki/OMeta)

[3] [http://wiki.squeak.org/squeak/4878](http://wiki.squeak.org/squeak/4878)

[4]
[http://scg.unibe.ch/research/helvetia/petitparser](http://scg.unibe.ch/research/helvetia/petitparser)

[5]
[https://github.com/SmaCCRefactoring/SmaCC](https://github.com/SmaCCRefactoring/SmaCC)

[6] [https://github.com/nopsys/CogNOS](https://github.com/nopsys/CogNOS)

[7] [https://github.com/mntmn/interim](https://github.com/mntmn/interim)

~~~
linguae
I have a similar vision as yours. I wish we had a computing environment today
that was a refinement of the Smalltalk and Lisp machine environments of the
1980s, where there was no distinction between user and programmer and where
everything is built up from objects. I dream of component-based software as
opposed to monolithic applications. I dream of the day where personal
computing is once again about the user having complete control and flexibility
over the computing environment.

I also agree with you regarding the funding landscape. Building even a clone
of Symbolics' Genera operating system from the 1980s will be a major
engineering effort. Academia might not the best venue since academia promotes
research, not product building, though I could foresee a professor taking
inspiration from Andrew Tanenbaum's Minix project and creating a Lisp- or
Smalltalk-based operating system for teaching purposes and to encourage the
study of non-Unix operating system designs, as systems research currently
(e.g., ACM SIGOPS, USENIX) is heavily Unix-dominated and has been for decades.
Regarding startups, the last VC-backed operating system-based startup that I
could think of is Be, Inc. from the 1990s, which failed to be a commercial
success since Be lost against NeXT during Apple's quest for a classic Mac OS
replacement in 1996, and since Be faced major hurdles with getting OEMs to
ship PCs with BeOS preinstalled due to agreements Microsoft made with top-
selling PC companies to encourage the proliferation of Windows. Every other
built-from-the-ground-up OS built since then has either been a research
project (Microsoft Research's Singularity, the L4 microkernel) or backed by a
large company with huge pockets (Google's Fuchsia). Interestingly enough,
while I believe the FOSS community would benefit the most from a Smalltalk- or
Lisp-based operating system since I believe component-based software design is
more amenable to the economics of FOSS development than the development of
large applications, I also agree with you regarding why the FOSS community
gravitated around Unix; RMS after all was a Lisp hacker who worked at MIT yet
decided to embark on GNU instead of creating a free Lisp OS.

It's a hard question, and a question I'm interested in since I'd love to work
on such an operating system and I feel there's a need for it, but I have bills
to pay.

------
lispm
Symbolics offered for the Lisp Machines various programming languages: C,
Pascal, Fortran and Prolog. They also resold a certified ADA system.

The C, Pascal and Fortran was based on a common substrate and they were all
written in Lisp. Editing was done in Zmacs with syntax editor support. One
could incrementally develop code in these languages and call them from Lisp.

For example the Pascal version of TeX was compiled and distributed with
Symbolics Pascal and the C-written X11 window server was compiled and
distributed with Symbolics C.

The Symbolics Genera demo by Kalman Reti showed a bit of the integration of C
and Lisp code:
[https://www.youtube.com/watch?v=o4-YnLpLgtk](https://www.youtube.com/watch?v=o4-YnLpLgtk)
He used a C-based JPEG library in the video showing the Symbolics Lisp Machine
system.

There were also various programming languages and development systems
available. On top of Lisp there were various extensive development
environments available: KEE, ART, Knowledge Craft - combining programming with
objects, rules, logic, ... Even the Nexpert Object system was initially
developed on a Lisp Machine.

One commercial system initially developed for software maintenance, software
porting and refactoring is REFINE. It is still available on current machines.
Targets were various assemblers, COBOL, Mainframe languages, ...

------
db48x
The Lisp Machine actually supported at least two languages that I know of;
Lisp Machine lisp and later they added Common Lisp.

Common Lisp is a very good multi-paradigm language; it can accommodate any
style of program you want to write. It's designed so that you can extend it to
be the right language for your problem, rather than to be a good language for
one type of program.

Integrating a non-lisp language wouldn't be impossible, but might be hard. How
would Haskell's type inference work when you're calling a Lisp function? What
would happen if a C program dereferenced a pointer to a Lisp object? There are
no immediately obvious answers to these questions, although these days there
are precedents.

------
CyberFonic
I have been experimenting with ES6 and Chrome Browser. Having DevTools Console
open and directly manipulating the environment entirely through the console.
It works. What it lacks is the nice tooling of Smalltalk, but that could be
implemented through a series of bootstrapping steps.

I have also played with Amber and SqueakJS. Interesting possibilities.

~~~
linguae
I was also blown away by Google Chrome's client-side JavaScript environment
(though Safari's environment is good for me, too). I started getting into web
development a year ago when I placed on a web-based project; I came from a
background where I was doing systems programming in C. I appreciate the power
of having a REPL and great graphical tools whenever I'm doing client-side web
development. I wish the tools on the server side were as sophisticated; the
debugging environment for Node.js is spartan compared to what's available in
the browser.

