evolution of my programming style

[Jecel Assumpcao Jr.]

David Ungar mentioned a language called StripeTalk that I had not heard
of before. It didn't have any kind of inheritance, so every object was
completely separate from all others.You can add one or more "stripes" to
an object, sort of like tags in a blog entry. When you cloned an object,
it would start out with the same set of stripes as the original. But you
could then add or remove stripes to one or the other object so each
would evolve along a separate path. When making any programming changes
you could select a set of stripes and all objects which included that
set would be affected by the change.

This reminded me how my oen programming style in Self evolved over the
years. My first non trivial application was a CMOS simulator in Self
1.0, so I was programming in vi instead of a GUI. My first step was to
add a pair of objects to globals like

traits _DefineSlots: { | zack = ( | cloning* = traits clonable | ) | )

prototypes _DefineSlots: ( | zack = ( | parent* = traits zack | ) | )

and then I would fill in the classlike functionality in the first object
and the instancelike in the second. Even after we got the GUI in Self 4
I stayed with this Smalltalk programming style for a while.

But in the GUI it was possible to visually drag an arrow to change the
contents of a slot (even a constant slot) to point to some object on the
screen even if that object didn't have a proper name as a result of not
being inside globals or its parents.

In security we have the principal of least authority (POLA) where if a
worker needs to get into rooms 5 and 7 to get their job done, they
shouldn't have access to room 4. Globals violate this in a big way. So
my style evolved to creating initially empty objects and slowly adding
the functionality they needed. If they needed some other object to do
their job (the color "red", for example) I would add a local slot and
make it point to that. When the object first needed to be copied it
would get a parent slot pointing to traits clonable. When things got
awkward the object would get an empty object as a parent and then the
needed slots would be moved there.

This is like the agile motto: "you aren't going to need it". Some
programs ended up looking the same as my initial ones like Smalltalk,
but that was the end result and not how they started out. Other programs
ended up with many objects with no parents at all. In both cases there
were typically only one or two objects that could be directly reached
via globals. All others were more local.

The ideas in StripeTalk reminded me that there is still a lot to explore
beyond the familiar programming style of Smalltalk-80.

-- Jecel