
The Lurking Smalltalk in Unix and Plan 9 [pdf] - mpweiher
http://plosworkshop.org/2013/preprint/kell.pdf
======
frik
Great paper. We need more discussions about such fundamental topics.

Remember the "Information at your fingertips" speeches of Bill Gates (Comtex
'90 and '94) and the Cairo operating system, its ObjectFS filesystem and later
WinFS?

* _Information at your fingertips_ Bill Gates Comdex Keynote 1995: [http://www.youtube.com/watch?v=o0O0Xjpjvfc](http://www.youtube.com/watch?v=o0O0Xjpjvfc)

* _Information at your fingertips_ Bill Gates Comdex Keynote 1990: [http://www.youtube.com/watch?v=jxUPSF2K7Cs](http://www.youtube.com/watch?v=jxUPSF2K7Cs)

* Microsoft's _Cairo_ operating system: [http://en.wikipedia.org/wiki/Cairo_(operating_system)](http://en.wikipedia.org/wiki/Cairo_\(operating_system\))

* Bill Gates' _The Road Ahead_ book: [http://en.wikipedia.org/wiki/The_Road_Ahead_(Bill_Gates_book...](http://en.wikipedia.org/wiki/The_Road_Ahead_\(Bill_Gates_book\))

* WinFS and its history: [http://en.wikipedia.org/wiki/WinFS](http://en.wikipedia.org/wiki/WinFS)

The current operating systems haven't really advanced since Windows 95 - the
user interface and the development APIs (not the kernel mode part). Some
mobile OS are even a regression. The idea of compound documents format was not
bad, just OLE2 was cumbersome (and a vendor lock-in). With HTML, its IFRAME
and HTML-based desktop GUI we could achieve the paradigm shift that Bill
envisioned.

~~~
DanBC
I'd be interested to know about best current environments for usable
computers.

I suspect it's going to be a BSD or Linux kernel with a tweaked OpenBox (or
similar) environment with a variety of web browsers and plugins.

It is a great shame that almost everyone has a powerful computer in their
pocket, but that they are unable to use the power of those computers because
they are locked into a variety of closed systems.

~~~
derefr
> I suspect it's going to be a BSD or Linux kernel with a tweaked OpenBox (or
> similar) environment with a variety of web browsers and plugins.

That sounds sort-of-but-not-quite like ChromiumOS. Actually, it puts me in
mind of how CoreOS would work if it were installed on a PC and each Docker
container was a desktop environment: one container for Chromium in OS mode,
one for Firefox, one for GNOME, one for XMBC, one for the SteamOS shell, one
for QEMU-KVM running Windows Embedded...

------
leoc
Reposting an earlier comment of mine
[https://news.ycombinator.com/item?id=6530180](https://news.ycombinator.com/item?id=6530180)
with context
[https://news.ycombinator.com/item?id=6526412](https://news.ycombinator.com/item?id=6526412)
:

> pjmlp 211 days ago | link | parent | flag

> Nice article, but it fails to explain the experience using Smalltalk
> environment really is. Smalltalk, like Lisp Machines, was originally a blend
> of GUI operating system, development environment and the first real IDE.

> agumonkey 211 days ago | link

> It's funny. Unix was also meant as an IDE (persistency, logic, machine and
> user interfaces). It seems they all were trying to reach the same goal in
> their own way. \-----

> 2 points by leoc 210 days ago | link

> The fact that dc was originally intended as basically the Unix system's
> bignums library
> [http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2...](http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2..).
> helped to open my eyes to this. I think you could talk about this idea of
> Unix as "big Unix" and the narrower understanding of Unix programming,
> dominated by the C APIs, as "little Unix". Little Unix took over the world,
> while big Unix collapsed under its own weight due to things like
> portability/versioning hell, robustness problems due to faulty tools and
> text-parsing errors, performance issues and so on. (Partly this was a
> success catastrophe, of course, for example in how the popularity of Unix
> resulted in a profusion of different Unix userlands with varying interfaces
> and bugs.) Also little Unix was more comprehensible from, and more portable
> to and from, the world of PC (MS-DOS/Windows/Mac) application development,
> where the environment is more or less the kernel's/OS vendor's APIs. The
> fact that clearly many more people have bought or read K&R
> [http://www.amazon.com/dp/0131103628/](http://www.amazon.com/dp/0131103628/)
> (with its very little-Unix perspective) than /The Unix Programming
> Environment/
> [http://www.amazon.com/dp/013937681X](http://www.amazon.com/dp/013937681X)
> reflects this divergence, and also surely helped to create it.

~~~
frik
Unix was Multics little brother:
[http://en.wikipedia.org/wiki/Multics](http://en.wikipedia.org/wiki/Multics)

------
lectrick
Did anyone here ever get a chance to play around with the Squeak VM?

[http://www.squeak.org/](http://www.squeak.org/)

It's basically "Smalltalk OS", running on any modern machine. Has some really
interesting ideas, such as every visible thing (and many invisible things)
being inspectable to see the code driving them, which can be changed live.

~~~
frik
We used Squeak in a computer science university course. It's a pretty
interesting Smalltalk environment.

Users have to learn to be careful, as one can destroy the whole environment by
modifying environment related Objects. So do regular backups of the whole
image, at least for the first few hours!

It could be a great playground for kids to get into computer science. The
playful colors may help too. Its GUI capabilities are more like Win95.
[http://en.wikipedia.org/wiki/Squeak](http://en.wikipedia.org/wiki/Squeak)

I would argue, JavaScript is like a modern successor. A modern browser with
its developer console (F12 shortcut) offers a comparable environment to
Squeak-light. A more feature-full release of the FirefoxOS/ChromeOS HTML5
shell release for desktop operating systems is probably the _next big thing_.

~~~
pjmlp
I kind of agree.

The problem is the Frankenstein model the HTML/CSS/JavaScript interaction
still offer.

HTML5 and the upcoming web components seem to be a step in the right
direction, but it is still not quite there.

------
lispm
Well, the MIT Lisp Machine was also a fully object-oriented system. Just using
Flavors (and later CLOS) instead of Smalltalk.

~~~
dfox
While you could meaningfully use dedicated smalltalk workstations without ever
coming across the concept of filesystem and use images for persistence, Lisp
machines were heavily file based.

In context of software development environments this distinction holds still,
in Smalltalk implementations getting some kind of source code that can be
versioned by normal VCS like subversion or git is generally an hackish
afterthought and source code is mostly stored in heap or one large binary
memory image, while in Common Lisp implementations the whole concept of images
is more or less equivalent to "artifact you get by building the project".

~~~
lispm
All Lisp Machines booted and saved images. For the Symbolics Lisp machine it
was not unusual to boot into remote image and save/load incremental images. In
Genera one typically loads a software into an image and then dump a new
incremental image and use that later. Source code was typically stored in
files (with versions) and maintained by a tool called 'system construction
kit'. There were some higher-level tools like KEE, which developed knowledge-
based systems mostly inside the image using GUI interfaces under program
control.

The first thing you do when setting up a personal Lisp Machine, is loading a
bunch of software. This is typically done by typing the name of the software
and the machine finds it in the software repository and loads it. 'Load System
'FOO''. Once the software is loaded one writes a new image, often an
incremental (delta) image. 'Save World :incremental ...'. After that the Lisp
machines asks whether to modify the boot sequence to use the new image... The
systems itself, were usually stored on a central file server and registered by
name. Often also a bunch of preconfigured images were provided.

Working with images AND files was already available in the 60s for example in
BBN Lisp. BBN Lisp could dump images, which one later loads for further use.

But what you think of Smalltalk as image based development was available in
Xerox Interlisp and Interlisp-D.

See: [http://larry.masinter.net/interlisp-
ieee.pdf](http://larry.masinter.net/interlisp-ieee.pdf)

> The file package removes from the user the burden of keeping track of where
> things are and what things have changed. For example, the file package keeps
> track of which file contains a particular datum, e.g., a function definition
> or record declaration. In many cases, it automatically retrieves the
> necessary lisp system during the interactive session. During this process,
> the primary copy of the program (the copy that is changed during editing
> operations) resides in the programming system as a data structure; editing
> is performed by modifying this data structure. For this reason, Imerlisp is
> called a residential system.'

> In a residential system, it is important to be able to take procedures
> represented by data structures and print them on text files in an input-
> compatible format for use as backup, for transporting programs from one
> environment to another, and to provide hardcopy listings.

...

> By this point, the Interlisp user did not have to worry about maintaining
> his source files, save for occasionally calling cleanup.

> The file package supports the abstraction that the user is truly
> manipulating his program as data and that the file is merely one particular
> external representation of a collection of program pieces. During a session,
> the user manipulates the pieces with a variety of tools, occasionally saving
> what he has done by calling the eleanup function.

> The user can also operate in a mode where programs are treated as residing
> in a data base, i.e., the external file system, with a variety of
> sophisticated retrieval tools at his disposal.

Btw., there are also current Common Lisp systems which make more use of
images.

[http://www.lispworks.com/documentation/lw61/IDE-M/html/ide-m...](http://www.lispworks.com/documentation/lw61/IDE-M/html/ide-m-101.htm#pgfId-865672)

------
jacquesm
I love all these 'other' architectures and platforms. What I can't seem to
find an answer to is how these would play nice with team development efforts
and revision control systems. Especially image based development is giving me
real headaches here.

Is there a generalized way to deal with this?

~~~
fractallyte
Modern Smalltalks (Squeak, Pharo) have Monticello for code management, and
Metacello for dependency management. These work 'in-image', easily and
efficiently.

The older enterprisey Smalltalks had (have?) ENVY/Developer - reputedly an
excellent and comprehensive version control system.

~~~
npsimons
_Modern Smalltalks (Squeak, Pharo) have Monticello for code management, and
Metacello for dependency management. These work 'in-image', easily and
efficiently._

See, this is what gets me about Smalltalk and other "cocooned" systems, such
as original Lisps. The languages have awesomely powerful features that are
only now being picked up by other languages, but the environments feel
constricting. Don't get me wrong, they are probably awesome for developing,
_in those languages_. But sometimes it's good to have competition, or even
just choice to suit programmer need/style, and saying that Smalltalk has <some
vc I've never heard of> is a big turn off. Why can't I use the vc of my
choice, as I can with nearly ever other language out there? Why can't I use
the editor/IDE of my choice, as I can with nearly every other language out
there? Having tools so tightly coupled just feels like bad design decisions.

~~~
fractallyte
You're probably thinking of Smalltalk as just another 'application' or
'language'.

Smalltalk is its own operating system, with an intrinsic (object-oriented)
language, and Smalltalk-specific applications. It's an alternative computing
_universe_ , and only runs in a VM because there's no native hardware, unlike
with Unix/C.

There's so little competition with software because there are relatively few
coders developing for Smalltalk. There's been some effort to develop a Git
client; with more developers on board, who knows what else might be possible?

At the same time, it would be wrong to shoehorn software on this system into
paradigms that work well in mainstream OSs. For instance, there's no real need
for an editor with the comprehensive feature-set of Vim or Emacs, because ST
code is not developed in that way!

------
abecedarius
The message-passing in Plan 9 seems basically different from Smalltalk's in
that a message is a sequence of bytes, not references to objects. This comes
up in the example in the paper where they pass the name of a file, which the
receiver then looks up in its own namespace (hoping to find the intended file
both there and accessible). I've used Smalltalk and not Plan 9, so I don't
know, but I'd expect that difference in the foundations to make a big
difference in what it's like to work in the system.

[http://en.wikipedia.org/wiki/Confused_deputy_problem](http://en.wikipedia.org/wiki/Confused_deputy_problem)
for one angle on this.

------
seanmcdirmid
Rob Pike seems like the last person who would design a Smalltalky system.

~~~
SixSigma
The strong design influence is Niklaus Wirth, mostly Oberon and Tony Hoare.

Rob is also a Squeak fan, implementing Newsqueak and adding Channels for CSP

[http://en.wikipedia.org/wiki/Newsqueak](http://en.wikipedia.org/wiki/Newsqueak)

This inspired Phil Winterbottom to create Alef for Plan9

[http://en.wikipedia.org/wiki/Alef_(programming_language)](http://en.wikipedia.org/wiki/Alef_\(programming_language\))

They then combined along with Sean Dorward and created Limbo

[http://en.wikipedia.org/wiki/Limbo_(programming_language)](http://en.wikipedia.org/wiki/Limbo_\(programming_language\))

This was sold off to Charles Forsyth & Co. at Vita Nuova where Roger Peppe was
employed.

Lucent lost loads of money in the telecomms crash and Bell Labs was decimated

Rob & Russ created Go at Google with similar ideas. Roger joined the Go
community and now works at Canonical doing Go development.

~~~
pdw
Newsqueak has nothing to do with the Squeak Smalltalk system, it was an
extension of an entirely unrelated Bell Labs language with the same name.

~~~
SixSigma
Oops, didn't read the paragraph far enough

Newsqueak was developed from an earlier, smaller, language, called Squeak
__(not to be confused with the Smalltalk implementation Squeak) __. silly me

------
akavel
[OT, sorry]

Is this done with the standard *TeX font ("Computer Modern"?), or some other?
I'm not sure why, but it looks somewhat not typical-LaTeX to me; if that's
because of font, could somebody possibly shed some light how I could get
similar effect? TIA

~~~
stephenrkell
Indeed, it's Nimbus Roman. I did nothing special -- the SIGPLAN template did
it for me. I had been assuming it just did \usepackage{times} internally,
though on inspection it does seem to be doing \renewcommand{\rmdefault}{ptm}.
Either way, it's fairly standard, but indeed not the default Computer Modern.

~~~
akavel
thanks for info!

------
pjmlp
Interesting read, although it misses the whole developer experience that is
part of Smalltalk.

EDIT: typo

~~~
Pacabel
The Smalltalk developer experience may in some ways be one of the better parts
of Smalltalk, but at the same time it's also one of the worst.

Getting tied into a particular environment often made it awkward, if not
practically impossible, to integrate with other editors, code manipulation
tools, version control systems, and so forth.

This might have been okay in academia, but it was far less acceptable in
industry.

