[self-interest] evolution of my programming style

[Randy Smith]

Just FYI -- StripeTalk was a "paper language" invented by Alan Borning, Tim O"Shea, and myself back in 1989 or 1990, while I was working for a year at EuroPARC (The European version of PARC in Cambridge England, now long defunct). Alan came in from the University of Washington for a few trips that year as a consultant. As I recall we wrote up a paper about StripeTalk and submitted it to OOPSLA, but it was rejected. :-)

--Randy

> On Mar 6, 2018, at 11:02 AM, 'Jecel Assumpcao Jr.' jecel at merlintec.com [self-interest] <self-interest at yahoogroups.com> wrote:
> 
> 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
> 
>