Hacker News new | ask | show | jobs
by di4na 907 days ago
One thing i think forgotten here, which actually is in the Worse is Better talk. But people tend to miss it.

These ST and Lisps systems failed at another aspect. Reuse. The biggest change of the past 2 decades in software engineering compared to previous generations is the amount of reuse. It is tremendous.

It is hard to talk of cause and effects here, but mostly this is due to the Internet. At this point, the vast majority of code running on any proprietary system is... Open source infrastructural packages.

This condition a lot of the current ecosystem. You can only reuse code on systems in which said code runs well. As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable".

Yes i know. It is far from magically portable, but it is far more than full machine living image SmallTalk or Lisp like.

As such, these "living code" are fundamentally evolutionary deadend. They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism.

On top of this, a lot of the elements to make this kind of machine works does necessitate deep in depth expertise. As the piece shows, the Newton is a pale copy of the goal because they did not have that knowledge in house nor the time (or money) to create it.

Same thing all over the stack. A good efficient logger need deep expertise. Same for a good localization library. Same for a good set of graphic servers. Same for audio servers. Same for a http parser or a network library. A good regexp engine is knowledge knows by less than 10 people in the world probably.

Once you realise that, you realise that at scale reuse is the only realistic way forward for software so ubiquitous as it is today. And that is how we got the current FOSS ecosystem, not because the code is better but because it would need too many licences to be manageable without breaking the bank in numbers of lawyers.

Same thing for the Worse is Better. It works because it provides extension points and can adapt. Something the Lisp and SmallTalk machines fundamentally failed to provide. And that is something Richard Gabriel focuses on far more than the whole New Jersey schtick in his talk.

3 comments

> They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism.

The code of a Symbolics Lisp Machine is written in so-called "systems". A "system" is a collection of files in a directory. Moving the code to another machine is either a) a copy of the directories to another directory or b) dumping an archive to copy to somewhere else or c) most of the time not necessary, since the Lisp Machine edits files on NFS file servers , which makes it possible to share the Lisp code directly with other Lisp systems in the network.

The Symbolics keeps track of versions of files and systems, something other Lisp systems typically don't do themselves.

> As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable".

There is little stability. The main theme is ever evolving fragmentation. Linux / BSDs is fragmented in zillions distributions, variants, versions, competing library variants, software archive systems, ... and open source UNIX is fragmented into various BSDs, Linux variants, ... Look at some portable code, it uses a huge configuration checker, which looks for all the variations of code and libraries. Zillions of checks...

yes but it is portable. On the lisps machine, you could not port to a different type of machine by another producer in general, even less across version. The Linux ABI is stable.
Sure you could, if you wanted. There were a bunch of software developed on the Lisp Machines, which were available over a range of different machines. In 1984 Common Lisp was presented as defined language, available from PCs up to supercomputers (Cray, Connection Machines). Common Lisp was the standard language for applications in Lisp. Symbolics itself had a Lisp system for the PC/Windows, which was thought as a delivery system, called CLOE (used for example to run Macsyma on the PC, IIRC). Early on a bunch of Lisp applications were ported to UNIX-based Common Lisp. These platforms appeared in the mid/end 80s (Allegro CL, Lucid CL, LispWorks, CMUCL, AKCL, ...) and especially the first three got very powerful. All the big expert system development tools were on those, too. The Symbolics graphics suite was ported to UNIX and Windows NT using Allegro CL. Stuff like that can be more demanding, given on how many machine features are needed.

The whole motivation to develop Common Lisp (which is mainly based on the ZetaLisp language for the Lisp Machine) was to have a common language for application development and delivery across operating systems and machine types.

When the Common Lisp Object System was developed in the end 80s, it was developed for ~15 Lisp implementations, from Lisp Machines to Apple's Macintosh Common Lisp.

To give you a recent example: ASDF is a built tool for Common Lisp software. It's 13k lines written in Common Lisp. I have here literally the same source file (Version 3.3.6) loaded into SBCL (macOS 14.2) and a Lisp Machine (Symbolics Portable Genera 2.0.5, running on an iMac Pro): https://i.redd.it/h94h3emjap8c1.png

> The Linux ABI is stable.

That's only a part of the Linux fragmented eco-system: CPUs, distros, ... A few days ago I have installed the Linux subsystem for Windows 11 on an ARM64 machine. Obviously it is not that easy to get all kinds of Linux software running on it...

This is a fundamental misunderstanding of what was the a tual problem with sharing code, at least with Lisp systems (can't speak of then commercial Smalltalks as I have no experience with those).

The lisp environments were fragmented, so sharing code between different systems was a problem - even assuming Common Lisp, a group working in facility A might be using Symbolics machines and depend on software packages like Dynamic Windows and Symbolics specific network stack, which mean portable core logic would be missing various usability elements like GUI when ported to facility B running CMU CL with Motif on Unix, or facility C which had TI Explorers.

Another issue was that the machines were powerful enough you didn't have to contact others just to get running. Working in C meant you either spent a lot of time filling in basic functionalities, or you collaborated with others.

This was compounded of course by C and Unix being effectively free for huge chunk of zeitgeist-creating masses in academia.

> depend on software packages like Dynamic Windows

That was the reason for specification&development of the "Common Lisp Interface Manager" (CLIM), which was a portable reimplementation of Dynamic Windows to Common Lisp and CLOS. It supported to build the presentation-based user interfaces of Dynamic Windows. Implementations of CLIM were available for Lisp on Genera, Unix, Mac and Windows. CLIM 2 then was an attempt to blend better into the other GUIs.

https://github.com/franzinc/clim2

https://mcclim.common-lisp.dev (McCLIM is an independent reimplementation of the CLIM 2 "standard".

TI came up with a UIMS (User Interface Management System) based on Common Lisp + CLOS + CLX , called CLUE (Common Lisp User Environment) and CLIO. That one was then also used by LispWorks for its GUI and IDE as the low-level UIMS system. LispWorks later replaced CLUE with their own UIMS, called CAPI, which supported/s Motif (now obsolete), Gtk, Windows and macOS.

https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...

Yup!

But if you didn't write with portable interfaces, you might not have bothered to port it later, etc.

Lisp and Smalltalk failed because it was near impossible to share the code. Living images are really hard to merge.

Smallltalk did eventually get a fantastic solution for code sharing between living images (Envy/Developer) but by that stage it was too late.

All that philosophical guff about “worse is better” had nothing to do with the practical ease of sharing files rather than a tangled mess of code that Lisp and Smalltalk encouraged. Sharing files is definitely not “worse” by any definition.

You say Smalltalk encouraged "a tangled mess of code" when we can all see that Smalltalk encouraged code sharing in external files:

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

1984 Smalltalk-80 The Interactive Programming Environment page 46

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

Sharing those changes was never that easy. Because it was encouraged to make additions and even changes to the base classes along with the project, we would inevitably end up with clashes. A typical scenario was filing in one programmers changes, then a second set of changes only to find they didn’t work together requiring a 3rd set of changes to be produced. Rinse and repeat in a big team and you’ve lost all the benefits of Smalltalk in hideous merges.

The change sets did not have hash based versioning or anything like that, so we tried cramming entire classes into SCCS or PVCS which kinda worked but quickly got unmanageable as base class extensions grew.

The Smalltalk change sets were fine for tracking one programmers work but quickly multiplied into a giant headache in any team.

> encouraged to make additions and even changes to the base classes

By whom?

"Guideline 120 Avoid modifying the existing behavior of base system classes."

1996 Smalltalk with Style page 95

https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...

You had to be there. Those books were not available when I was using Smalltalk and not all programmers really “got” the system or the implications of their changes on their team.
You must have been a very early user, this was published in 1984 —

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

Without a defined software development process, that everyone habitually uses, we can usually make "a tangled mess of code" with any programming language.