There are too many good things to say about the Design Principles
Behind Smalltalk. A few of my favorites:
Scope: The design of a language for using computers must deal with internal
models, external media, and the interaction between these in both
the human and the computer.
This one is really obvious until you get to the last four words. The
human and the computer. Luckily we’re starting to take for granted
the primacy of human communication in programming lately (mostly), but
when Smalltalk was created, I’m sure its designers received no
shortage of grief when they steered towards humane optimizations.
Uniform metaphor: A language should be designed around a powerful
metaphor that can be uniformly applied in all areas.
Smalltalk is largely objects and messages. Lisp is largely lists and
functions. Erlang is largely pattern matching, functions, and
actors. These aren’t perfect languages, but once you deeply
understand, really grasp the core concepts, you have the whole
language at your command.
Operating System: An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.
The first sentence is a great principle when considering what should
go in the core of a system and what should go in the surrounding
ecosystem of libraries. The second sentence is wonderfully bold, in
that it cuts against what nearly every successful system has done
since Smalltalk was prominent and in that it contradicts the first
sentence. I’m not sure what practical use to make of this principle;
its density of intrigue is that keeps me coming back to it.
Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.
I stopped worrying about what might supplant Ruby a long time
ago. Someday, it will happen. And when it does, whatever succeeds Ruby
will have to be really awesome to fill its shoes. I’m looking
forward to seeing what that is. But the same goes for any technology;
they are often replaced with something wholly awesomer than the
incumbent.
I’ve never done it, but it seems like it would be intriguing and
vastly informative to sit down with one of the systems I work on daily
and try to extract these principles post-hoc. What values and
principles are embedded in the system? What does that say about the
team and why the system is the way it is? What principles are enablers
and what bad habits should the team work to correct?
Adam Keys is typing 