Michael --

At 1:47 AM +0000 7/5/02, Michael Roberts wrote:
>Hi Alan,
>
><snip>
>>  Well, I think this is a confusion with "objects" and some of today's
>>  "object-oriented systems". In the "Early History of Smalltalk" paper
>>  I wrote back in '93, I seem to remember pointing out that the first
>>  three principles of objects that came to me in '66:
>>     * Everything is an object
>>     * Objects communicate by sending messages (which thus must be objects)
>>     * Objects can remember (memory thus via objects)
>>  had stood the test of time. In fact the most annoying properties of
>>  today's Smalltalk/Squeak stem from the parts that haven't been
>>  completely objectified.
>
>I was just wondering which bits you find the most annoying/least 
>objectified in todays Smalltalk/Squeak?

This is about today's version of Smalltalk/Squeak -- some past 
versions have done some of these ...
      On this list, I've mentioned several times that variables and 
instances should be objectified. This has been done in several other 
systems to provide much better leverage on a number of important 
problems.
      Messages and message sending could be more objectified. This 
would allow a much more flexible approach to trying delegation 
schemes, finding alternatives to inheritance, etc.
      Another larger area that I'm astounded that no grad student has 
done a thesis on, would be to take the "Smalltalk VM in itself" that 
we use for bootstrapping, and make it into a real OOP model itself. A 
large part of this is just to restructure the messy workable thing we 
have now.
     Methods could stand to be more objectified. I'd like to see 
methods that have a vertical bar down the middle. On the left would 
be the "reference code": the simplest code that does what the method 
should do. On the right would be the "pragmatic code": a bunch of 
cases for running the meaning efficiently. You should be able to run 
both sides when debugging, etc.
     Another method objectification would be to have many polymorphic 
methods be instances of a class that guards the meaning of the 
polymorphism. This is part of having a model for both variables and 
"slots", etc.

      One way to play with this would be to just take the three 
"principles" above and make a complete model. This is pretty easy. 
The important thing that CLOS (e.g.) did was to make the additions to 
the models compilable so that metachanges could be as efficient as 
the kernel. We kind of have this with SLANG, but the whole apparatus 
could be much much cleaner.

Cheers,

Alan

>
>Cheers
>
>Mike
>
>p.s.
>
>I think your comments on the lasting effect of the first paradigm 
>one learns and your early experience with learning so many different 
>languages very interesting. 
>
>There was a thread recently discussing Python and it became quite 
>thought provoking but I didn't pipe up at the time -
>
>I find it interesting that different language communities each 
>define, implement, and to different degrees defend, their own 
>versions of 'OO'.  I find that some people who learn OO through one 
>language can be left with a lasting understanding that is at odds 
>with others who have learnt in a different language/environment.  I 
>find this particularly with respect to paradigms and the 
>implementation of design abstractions.
>
>I don't wish to appear critical with any particular language but I 
>never manage to resolve some of my following thoughts when I follow 
>discussions on how best to teach objects, and software more 
>generally, to people :-
>
>Python, for example, lets you write (and think) in three paradigms - 
>procedural, functional and object oriented.  I had no understanding 
>of functional programming before I met Python and it provided a neat 
>way for me to learn totally new ideas.  Deep within a complex 
>systems programming task, however, I found it difficult to 
>understand code that constantly switched between all three 
>paradigms.  It evolved in this state, because this was the favoured 
>style.  It's not necessarily right or wrong but prompted me to think 
>about the differences between languaes that provide power through 
>simplicity and languages that provide power through features; and 
>how a paradigm, or a number of paradigms is presented and offered 
>for use. 
>
>Moving from the paradigm to the implementation of it in a specific 
>language I find lots more juicy things to think about.  Reuse 
>through templates in C++, for example.  Also, different languages 
>provision of object references and how they can be passed around. 
>The difference between static and dynamic typing.  Casting!!!  I 
>won't go on.
>
>I think I'm just tying to illustrate that the lasting impression of 
>the object paradigm, if you could only experience one of (for 
>example) Java, C++, Python, Delphi, Smalltalk is going to be 
>different, possibly not the best impression, and thus undesirable. 
>It's only by taking a meandering path through these languages (and 
>more) that I'm maybe beginning to appreciate the qualities of the 
>paradigm rather than that of the language.  I started thinking down 
>these lines when you mentioned that you had experienced lots of 
>different ideas early on and after all, they're just ideas.  I think 
>that maybe these days, with many languages, a lot gets in the way of 
>the fundamental 'ideas' and to see them you have to experience many 
>languages to extract the gems.  I wouldn't wish some of my language 
>experiences on anyone :-)
>
>Am I right in thinking that one could provide an object environment 
>to learn in that removes the emphasis from learning the language to 
>squarely learning the paradigm - and thus not leave an inappropriate 
>lasting impression? I guess this is what you have done with E-toys 
>but I hadn't thought about extrapolating that style of environment 
>to (i'm not sure of the right word) an 'older' or maybe more 
>'involved' audience until you expressed the ideas for media-rich 
>learning environments. 
>
>Is the problem therefore that by teaching the object paradigm 
>through a specific language you essentially distort the paradigm to 
>its expression and realisation in the language?  Only by providing 
>an environment that allows the understanding of the difference 
>between the paradigm and the technique(s) of modeling in the 
>paradigm can you fully appreciate the difference and thus benefit 
>the most from the experience? 
>
>One can then, if desired, go on to play in many different languages 
>- and to some extent discover the realities of how some communities 
>view 'objects'!
>
>Mike


--