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