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
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@merlintec.com [self-interest] self-interest@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
Randy Smith wrote on Wed, 7 Mar 2018 09:08:22 -0800
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. :-)
Right, I forgot to include the reference:
https://constraints.cs.washington.edu/object-oriented/stripetalk.pdf
-- Jecel
Thanks ... I was off by one on the year and off by two on the authors list!
On Mar 7, 2018, at 9:18 AM, 'Jecel Assumpcao Jr.' jecel@merlintec.com [self-interest] self-interest@yahoogroups.com wrote:
Randy Smith wrote on Wed, 7 Mar 2018 09:08:22 -0800
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. :-)
Right, I forgot to include the reference:
https://constraints.cs.washington.edu/object-oriented/stripetalk.pdf
-- Jecel
self-interest@lists.selflanguage.org
-
Jecel Assumpcao Jr. -
Randy Smith