Jecel Assumpcao Jr wrote:
> Paul D. Fernhout wrote:
> 
>>Jecel Assumpcao Jr wrote:
>>
>>>[Us paper]
>>>http://citeseer.ist.psu.edu/5049.html
>>
>>Thanks for the link. I'm not sure how this differs from regular Self? And 
>>the paper is not online that I could find.
> 
> 
> Clicking on the "PDF" link in the upper right corner of that page worked
> for me just now. Self is an objective language, which means that the
> code to be executed depends on the type of the receiver and on the
> message selector. Us is a subjective language where the code to be
> executed also depends on the context from which the message was sent.
> This is an extension of the work on "layers" done in Smalltalk in the
> PIE project.
> 
> An idea closely related to the "viewpoints" introduced in Us is "roles"
> where the code also depends on the context. The difference is that when
> you change viewpoints all objects change at the same time (like moving
> your head in a 3D environment) while when you change a role only a
> single object is affected (like rotating an object in a 3D environment).
> Both of these features address some of your complaints about using
> objects exclusively for everything.

Thanks for the link and the explanation (Joshua also pointed me to the 
right link).

I just read the paper (well, my mind glazed over about half way through 
but I kept at it, skipping a few implementation details). I definitely 
liked the history review bit, including where is mentions "the notion of 
an object being a 'figment of its viewer's beliefs' is a feature in Alan 
Kay’s sketch of a language he called Rainbow" -- detailed apparently an 
unpublished Xerox Parc report of the 1980s (I would love to learn more 
about that). I repeatedly see why Alan Kay is surprised Squeakers are so 
satisfied with Smalltalk-80 and how he wants to go further. Clearly there 
are a lot of good ideas to explore, even if we limit ourselves to the 
1980s. :-)

I kind of lost faith in their proposal when their model had a common 
object ID across all layers; since part of my suggestion would be that 
what are the relevant objects would differ by perspective. Also, I am not 
sure they built a compelling case for adding complexity by not having 
enough worked out examples of how perspectives as they outlined them were 
a really big win. But in any case it is a clever set of ideas and shows 
that a lot of thinking can go point this which is moving *beyond* the 
original "Design Principles Behind Smalltalk", which was the main point I 
was making. And they make clear in their literature review how the notion 
of adding "context" is one many people have explored.

There are also solutions to some of the issues they raised in other 
directions, for example the classical one of the debugger not working when 
you mess up how any window in the system opens. In the PataPata 
(prototypes for Python) case, every prototype has a "world" it belongs to, 
and I have the debugger in a different "world", which has its own copies 
of core classes, so you can break the Window class in one world, but the 
debugger can still debug it. Prior to the ParcPlace-Digital merger they 
were working on something similar at PP using a "firewall" or something 
(just heard of it in passing). I did not bring PataPata to the point where 
worlds were in completely separate processes though, so you can still hang 
the system in other ways; ideally I wanted worlds to each be in their own 
VM process and to communicate using sockets or other means of sharing 
state across images.

>>[patapata and documenting intent]
> 
> 
> I think the issue is unrelated to class vs prototypes and is actually
> about having a global catalog vs allowing loose objects. Even in
> Smalltalk-80 you have loose objects (like "Set class"), of course, by
> they are so closely coupled with cataloged objects that they don't
> matter. As always, there are tradeoffs. Doing things one way will make
> some stuff easier and others worse (without loose objects there is a
> strong temptation to use block where you should really be defining new
> objects, for example). We have a lot to learn about how to best organize
> systems, specially when they are modular.
> 

Good points. I'll need to think about them. One of the PataPata decisions 
was to reference parents by *name* rather than *pointer*. In self, key 
objects can have names, but they are still referenced by pointer. The 
PataPata choice gave me a little more flexibility in some ways I think -- 
by adding yet another layer of "late binding" to the system. (And 
accompanying overhead, of course).

>>[Squeak-on-JVM and licenses]
> 
> 
> I think the extra step of getting Squeak 1.1 relicensed as Apache after
> Apple had already agreed to relicense it as APSL 2 was more than we
> could have hoped for. All code written after that is in the process of
> being relicensed using the old X11 (often called "MIT") license. The
> latter is GPL compatible, so as long as you are willing to do your own
> replacement for Squeak 1.1 your legal needs would be met.
> 

That's one strategy I guess. I would expect it probably fairly difficult 
to extract useful parts from a combined system built on 1.1 without 
running into various problems though. I'll be more curious how the Apache 
license is interpreted in a Squeak context -- whether it is considered to 
flows through to applications built on it as "derived works" (and so they 
cannot be GPL) or whether the license just applies to Squeak itself and 
not things you put on it.

In thinking more deeply about Dan's accomplishment (Squeak on the JVM, 
which I had not been aware of) and looking at discussions on it from April 
and comparing it in my mind to other Smalltalk on the JVM Bistro, A Little 
Smalltalk, Talks2 (another Squeak derivative), etc.) a big issue is 
whether you use Java objects as the base Object (like Jython) or if you 
try to build your own objects from bits (as I imagine Dan's port does?). 
It would seem more efficient to use Java objects -- because then you could 
just use the Java garbage collection system and so on -- maybe even the 
byte codes, or maybe not. However, that would not be Squeak-as-it-is 
obviously, but it could potentially be a good Smalltalk (or Self or Us) 
anyway. :-) In the past, I have looked at the thoughts of porting GNU 
Smalltalk on the JVM (total VM rewrite plus other core changes), improving 
A little Smalltalk (much work), or using Sharp Smalltalk (the best match 
in some ways, as it was written for a similar system, dot net, but also 
missing a GUI and so on). Squeak would be my first choice of what to work 
from based on completeness and community, except for licensing issues.

Perhaps the biggest single issue is, how do we have a community around new 
things inspired by Squeak? I brought this issue up many years ago, but was 
basically shot down in flames of people pushing "Squeak the artifact" not 
"Squeak the community". Still, it seems like it is community which makes 
the value in the free and open source world. Yet the Squeak community 
seems closely tied to Smalltalk-80 and Squeak-as-it-is, in part as a 
self-selecting process -- yet ironically as Alan Kay himself keeps saying 
he wants something better.

>>>Note that some people were interested in getting Squeak to run on top of
>>>Strongtalk's VM and that would match your request for a non Smalltalk
>>>syntax (it is written in C++).
>>
>>Again, I don't care if the VM is written in Smalltalk. I think it is 
>>clever to make a VM in an abstract way, especially as it is already done 
>>(even though there are some disadvantages). I'd much rather work in 
>>Smalltalk syntax than other syntaxes (even Python). I was using it more as 
>>an example of Squeak applying a design principle which may be obsolete in 
>>the internet and free software age.
> 
> The whole point of the Slang trick was to be able to debug using all the
> nice Squeak tools instead of gdb. Some people don't want that while for
> others it makes all the difference in the world.

True, you can use all the nice tools when developing the VM under Squeak, 
but you can't use them when you actually test your code after it has been 
translated. So, an unexpected "barrier". Which was my point again -- there 
are always barriers (even just conceptual ones) -- at best we can pick 
where they will be (which is similar to what you said above on 
prototypes). "Design Principles Behind Smalltalk" implicitly says some 
barriers are more worthy of lowering then others; it's perhaps worthwhile 
25 years later to revisit which those should be.

Increasing complexity is easy; moving it around in tradeoffs is harder; 
reducing it is hardest and generally require a leap of the imagination.
Sorry to say it, but Squeak still seems pretty complex to me, and moreso 
than ten years ago. :-)

--Paul Fernhout