blue ideas
Jecel Assumpcao Jr
jecel at merlintec.com
Mon Aug 19 23:33:20 UTC 2002
I wrote a page with five ideas to simplify Self (slightly blue plane
stuff):
http://www.merlintec.com:8080/software/11
The jargon there is very Self oriented and so might not make much sense
to Squeakers. Some of the ideas at least could be applied to Squeak -
1) unified block/method/context objects
in Self, methods are supposed to be prototypes from which we obtain
contexts by cloning. In practice it doesn't work that way and this is a
call to take the idea seriously. Since Squeak is class based we are
already used to the idea that an object and the template from which it
is created are very different, so the idea doesn't have the same
impact.
2) up arrow as binary selector
Squeak has little special syntax: <- (or :=), ^, self, super,
thisContext, true and false. Self has even less and I would like to
take advantage of idea 1 and make ^ be just another binary selector.
This doesn't apply to Squeak since it doesn't have the "implied self
receiver" syntax.
3) simpler syntax: no literals
This idea would work just as well in Squeak and we already have a taste
of it in MathMorphs and eToys. If you can embed a graphical
representation of any object in source code, you don't need syntax for
literals.
4) simpler assignment
This is an attempt to make assignment and message argument binding be
the same thing. A side effect would be to allow more flexible keyword
messages with default arguments.
5) removing inheritance from the base-level
parent slots are a neat language design "pun" (a single thing is used
for both "has-part" and "inherits-from" relations) but it would be
better to have all program structuring stuff live exclusively in the
meta-level. Squeak doesn't have parent slots, of course, but does have
#class, #isKindOf: and other unmarked portals into the meta-level
underworld.
===
As I was thinking about the pink plane / blue plane stuff, I came to the
conclusion that there is a related but separate dimension. A project
can seek "synergy" or it can work towards a "separation of concerns".
If you add a JIT, for example, it might be an optional plug-in that
makes things faster when present, like in Jitter 3. Everything can work
either with it or without it. An alternative would be to make it a
central aspect of the design (like Self or Jikes) and try to see what
can be made simpler because of it. Can name spaces be simpler? Modules?
3D graphics?
My personal taste makes me favor synergetic designs but there are
problems. It is harder for more than a small group (or even a single
person) to work on it. It is harder (impossible?) to understand a part
of the project without learning all the rest. New requirements might
come along and it might be easier to throw away the system and build a
new one than to adapt it.
The "separation of concerns" step-by-step development is the way to go
in the pink plane. But what is the best style for Squeak on the blue
plane?
-- Jecel
More information about the Squeak-dev
mailing list
|