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