The Lurking Smalltalk in Unix and Plan 9 [pdf] | Hacker News Reader

The Lurking Smalltalk in Unix and Plan 9 [pdf]

humprog.org

91 pointsmpweiher38 comments

Original URL: http://plosworkshop.org/2013/preprint/kell.pdf (https://web.archive.org/web/20140624212433/https://plosworks...)

Strange Loop talk: https://www.youtube.com/watch?v=LwicN2u6Dro

Open articleView on HN

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

* Information at your fingertips Bill Gates Comdex Keynote 1990: http://www.youtube.com/watch?v=jxUPSF2K7Cs

* Microsoft's 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...

* WinFS and its history: 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.

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.

> 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...

Reposting an earlier comment of mine https://news.ycombinator.com/item?id=6530180 with context 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.... 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/ (with its very little-Unix perspective) than /The Unix Programming Environment/ http://www.amazon.com/dp/013937681X reflects this divergence, and also surely helped to create it.

Unix was Multics little brother: http://en.wikipedia.org/wiki/Multics

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

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.

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

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.

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.

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

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".

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

> 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...

Yes, but they got their inspiration from Smalltalk, as Interlisp is younger than it.

The Interlisp manuals have some references to it.

Anyway, both systems are great. And their strong typed brother Mesa/Cedar also. Which was Wirth's inspiration for Oberon.

Only someone that never used these systems can find similarities between them and Plan9, in terms of overall experience.

Interlisp is older than Smalltalk.

a) the MIT Lisp Machine did not run Interlisp, they ran Lisp Machine Lisp, which is based on Maclisp out of the 60s.

b) Interlisp is a renamed BBN Lisp, which started in 1967. BBN Lisp was based on L. Peter Deutsch's PDP 1 Lisp from the early 60s. L. Peter Deutsch later worked at Xerox PARC on Smalltalk, too. He developed the virtual machines, etc.

Smalltalk was influenced of earlier Lisp work like BBN Lisp and Planner. Lisp Machines were influenced by Smalltalk - but they were developed roughly at the same time: starting early 70s.

I got that understanding from this website:

http://www.chilton-computing.org.uk/inf/literature/books/wm/...

<quote> "Interlisp-D was a real system with about 1000 users and was influenced by Smalltalk: it was an object-oriented system." </quote>

That's Interlisp-D, not Interlisp. As I said Interlisp is out of the 60s and had already an IDE, interactive development (but not with mouse/windows), could save and boot images, had a structure editor, had source code management, ...

See for example Teitelman's paper on 'Automated Programming' from 1972: http://www.softwarepreservation.org/projects/LISP/interlisp/...

Interlisp was ported to the Alto in the early/mid 70s and to the Dorado.

Interlisp-D is the single user, window/mouse/keyboard/workstation variant of Interlisp.

"Interlisp-D is both a revision and an implementation of the lnterlisp virtual machine specification [Moore, 76] for the Dolphin and Dorado personal computers."

PDP1 Lisp -> BBN Lisp -> Interlisp -> Alto Lisp -> Interlisp-D.

Sure it was influenced by Smalltalk.

Thanks for the clarification. It is always a pleasure to discuss such issues with you.

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?

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.

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.

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!

Objective-Smalltalk ( http://objective.st/ ) is a work in progress that tries to combine the Unix and the Smalltalk side. On the one hand you can easily use ST in scripts, which are just small text files, as well as interoperate with (Objective-)C. On the other hand, you get hierarchical naming and use of filesystems and REST APIs from within the language.

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 for one angle on this.

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

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

This inspired Phil Winterbottom to create Alef for Plan9

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)

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.

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.

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

Right, you got Newsqueak wrong, nothing else suggests smalltalk fandom. I got into an argument over lunch with Rob Pike about Java, and I got the impression that full OO just wasn't his style (he's more of a modules, interfaces, and everything-is-a-file person).

His famous quote is "Object Orientated design is the Roman numerals of computing"

Right. If anyone could be called the anti-Kay, it would be Rob Pike.

And I don't think he did: http://www.jerf.org/iri/post/2931

It's interesting to compare and contrast the foci within the linked PDF and my post there.

...on purpose. Well, that's what makes it interesting!

[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

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.

thanks for info!

Looks like Nimbus Roman: http://www.tug.dk/FontCatalogue/nimbus/

thanks! interesting link

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

EDIT: typo

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.

Reply on news.ycombinator.com