These are my personal notes from the Workshop on Self-sustaining
[A quick note beforehand: The descriptions make use of a metric called
“lines of code” (LOC), which widely is regarded as being insufficient
for measuring program size. Due to lack of better means, I decided to
mention them nevertheless. Take them with a grain of salt.]
The conference started after lunch, but we got there earlier so we had
the chance to socialize with the HPI
Ian Piumarta gave the first invited talk on his
Late-bound lambda object architecture, wherein he decided to fight the fact
that software tends to become too complex by finding out how much you
can say with how little. He started by contrasting the three cubic
miles of paper that is the US case law to Maxwell’s four tiny
equations which are able to fully explain all electromagnetic
Moving to software, he showed the source code line counts of some
popular projects, and we could see, for example, that OpenOffice.org
has more lines of code than the entire FreeBSD operating system.
Comparing lines of code with the size of literary categories, he
decided that 20kLOC, which roughly resemble a 400 page roman, are the
maximum size of a program a programmer has the chance of fully
He continued explaining how it is possible to get much done in such
a limited amount of code by showing off how simple things like shape
rendering, which only consists of a few elementary transformations, is
enough to render fonts and essentially provide a full graphical
He gave a quick tour of other interesting ideas to be further
investigated, such as multiple subjective perspectives, which result
from the realization that objects have several roles, or regarding
computation as “fields” (re)acting on particles, a concept which makes
it easy to specify complex interactions between many objects.
Since predicting anything is difficult, he argues that it highly
important to be as dynamic as possible, by using the fewest minimal
abstractions that allow for any possible feature/paradigm to be added
to the language/system.
His design combines functions and objects into the foundation of his
system, COLA. Functions,
represented as s-expressions provide the proto-behavior, while
proto-structure expresses form by providing objects that messages are
sent to. They provide the dichotomic base, since without
function, form cannot be animated while function has no representation
without form. This results in a self-describing structure.
(Actually, after the talk he told me they are trying to unify
functions and objects into one thing, I’m very curious about the
His talk was larded with memorable insight such as looking at GTK+ and
noticing “C is highly deficient and wasteful” or encouraging the
students to look at the “old” papers where technology was severely
limited because “sometimes progress is behind you”.
The next talk was by Christophe Rhodes, who spoke on
SBCL – A sanely bootstrappable Common Lisp. After a short overview
of Common Lisp, he summarized the history of
SBCL, which started as a fork of CMUCL in 1998.
The main reason of the fork was that CMUCL was horrible to
bootstrap and it actually wasn’t possible to compile CMUCL without
already having the last version of CMUCL before that.
Christophe Rhodes emphasized the importance of a system being able to
rebuilt itself from a “blueprint” since it makes the result a lot
clearer, easier and predictable. He showed an example of a bug in a
core data structure which was easily fixed by changing the structure
and recompiling the system—without the ability to rebuilt from
scratch, magic hackery would have been required to modify the existing
structures to be compatible enough until they could replace
SBCL nowadays can be compiled using half a dozen of different CL
implementations and does, once built, not any dependencies on the build
This unusual level of self-sustainability has many benefits: it is
more fun, enables quicker turnaround, makes the system more
future-proof, and doesn’t limit improving the core of the system to
hackers with magic abilities. Instead, every developer can work on
the code because in the end it’s just another big Lisp program.
Because of this, more people can help with the system and maintain it,
thereby having more control over the destiny of the system as a whole.
Charlotte Heerzel was the next, presenting
Reflection for the masses, in which she showed how to implement
using CLOS. She noticed that programming languages are made powerful
by abstractions, but there are cases where one wants to get rid of
them, for example if you need access to the current continuation.
Reflexive languages, on the other hand, allow the programmer to
control internalization, normalization, and externalization within the
She showed lots of code, implementing a small Lisp interpreter in CPS
and then adding structural reflection by exposing the internal data
structures as abstract data types and behavioral reflection by
introducing reflective-lambda, which has access to the current
continuation, environment and code. For example, this allows to
when as a first-class function.
The first day ended with two social events: first, there was a boat
trip around Potsdam, where I had the great luck to sit on a table next
to Richard P. Gabriel and Pascal Constanza. We had a long interesting
discussion with them about the lack of (helpful?) limitations in
programming, what designers really do, how Java became popular, the
danger of the obvious and demonising copy and paste programming. I
learned one thing about how rpg decides which poems to publish, which
I cannot keep back:
Richard P. Gabriel writes a poem each
day, and once a year, he needs
to select six of them for publishing (six seems to be the usual amount
the publisher wants). So how does he do it? Using a computer, he
randomly picks sets of six, until all of them don’t suck. Then he
sits down and revises them.
We crystallized this as the essence of design: to choose the things
that don’t suck.
Afterwards, we had a dinner buffet on a restaurant boat until night.
The next day started with Daniel H. H. Ingalls (say it in German!)
demonstrating The Lively Kernel – a self-supporting system on a web pagex.
He admitted that web programming is complicated, but
While he explicitly mentioned that he is not proud of the code, he
thinks it’s easy enough and works well.
The whole Lively Kernel is
rendered using dynamically generated SVG and doesn’t include any
(visible) HTML at all. All drawn stuff are vector objects. In good
Smalltalky manner, the system uses MVC extensively.
After a short demonstration with some turtle graphics and live-code
editing, he pointed out some of the non-obvious features of it: For
example, to support multiple people working on it, they introduced a
parts of the system into version control. Also, they have a pretty
sophisticated system for profiling by dynamic method rewriting to
insert measuring code.
and already includes many details such as rich-text-boxes.
On the topic of security, Dan Ingalls proclaimed that his security
philosophy was like this: “Make it work, then make it secure,
and I hope someone else does step 2.”
Carl Friedrich Bolz presented a joint-work of eight Pythonists and
Back to the future in one week – Implementing a Smalltalk VM in PyPy
which they started in October during a five day
PyPy, initially a
Python implementation in Python, but now moving towards a general
compiler tool-chain, enables one to write highly flexible language
implementations because most things are late-bound. Therefore,
garbage collection, object layout and the threading system can be
exchanged easily and allow for lots of experimentation. PyPy aims to
autogenerate dynamic compilers from interpreters written in a reduced
set of Python called RPython with nevertheless allows full-fledged
compile time metaprogramming.
They already implemented all Squeak bytecodes and most of the
primitives. The resulting system,
SPy, can load unmodified Squeak
images and run simple benchmarks. It is roughly 10x slower than
Squeak itself, and they plan to support the graphical builtins in the
future as well.
The team continued hacking on SPy in a sprint in Berlin just after the
Guillermo Adrián Molina next introduced Huemul, a Smalltalk
implementation that directly generates native code. It is a very
small system of only 4.5kLOC since it doesn’t try to do everything but
instead reuse existing code. For example, he uses libc, pthreads,
setjmp/longjmp, GTK+ for the UI and OpenGL. The system is
MIT-licensed and inspite of lacking real optimizations already pretty
fast: It runs roughly 832 million bytecodes/s and therefore is comparable
to the performance of commercial Smalltalk systems.
Huemul looks very interesting and
certainly is a thing that deserves more attention.
Are bytecodes an atavism?, Theo d’Hondt wondered when he
noticed that people are fixated on virtual machines: They think
it’s the only way to write a fast system.
However, interpreters are the simplest way to express the semantics
of a language.
After a glimpse of the history of bytecode from BCPL over Pascal-P to
Smalltalk, Self and Java, he presented Pico,
a tiny language implemented using CPS that is smaller than Scheme that
was roughly as fast as PLT Scheme (as of 2004)
Based on his experience with Pico, he decided to write PicoScheme,
which is written in a subset of C and works by compiling s-expressions
into an abstract syntax tree that then is interpreted. Soon he
realized that “Scheme isn’t all that simple to implement”, but now he
has a very promising implementation of the most parts of Scheme
(nothing really relevant is missing) that is as fast as PLT by now.
It also is very compact: the GC only has 150 LOC.
After the talk, he promised to open PicoScheme to the public in the
The last talk was called On Sustaining Self by Richard P. Gabriel.
I only can recommend to take any chance to hear him
speaking because he’s doing excellent presentations—I’m unable to do
his audio-visual impressions justice, so please excuse the rough
sketches: The talk started off with playing Hogni Lisberg’s cover of “All
along the watchtower” while Noble and
words of their Manifesto in “Notes on Post-Modern
appeared on the screen. “There must be some way out of
The ultimate goal of all computer science is the program. The
performance of programs was once the noblest function of computer
science, and computer science was indispensable to great
programs. Today, programming and computer science exist in
complacent isolation, and can only be rescued by the conscious
co-operation and collaboration of all programmers.
There are three ways to build self-sustaining systems according to
Gabriel: First, Designed Perfection, which is what most people try
to do today; it is very efficient, but entropy will get you. Second,
Instinctual Adaption, which is resilient and flexible. Third,
Learning, which is costly, but gives the best results in a highly
A poem assembles on the screen; to brilliant guitar music there
and it morphs into:
Abstraction ignores the relevant,
therefore it requires ignorance!
He does a case-study on
overcame the limitations and plannedness of itself and turned into a
He presented a case of artificial evolution showing the FPGA
that generates very effective chip designs that
nobody really understands how they work.
Finally he enters an dialogue with himself asking “How are cities
designed?” At first look, they look modular, but they are so full of
interconnected dependencies that they are impossible to modualize
really. Also, the nature of the city is not planned.
In the end, the recognizance: Design is an illusion.
(I highly recommend you to watch the video when it is online.)
Summary: Attending the conference has been a great pleasure.
Although being rather short and small (only one-and-a-half days and
maybe 50 attendees), there were top-notch invited talks and many
important people (and also many unknown, but friendly, clever and
interesting ones!) around that everyone simply could talk to. The
social events were well organized (free dinner, free beer) and
actually allowed to socialize.
I seriously hope S3 can turn into a periodic conference because I’d
really like to attend it again.
[Let’s also mention the not-that-good-stuff, just for the sake of
completeness and so you see there’s not much to dislike:
introductionary marketing speeches; the “Workshop” in the name
misrepresents the conference; occasional WiFi failure.]
NP: Bob Dylan—I Believe In You