Jecel Assumpcao Jr wrote:
> if you haven't seen it already, you might find the description of the Us
> variation of Self (which makes it a kind of Smalltalk in my view)
> interesting:
> 
> 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.

I spent a few months working on adding prototypes to Python inspired by 
Squeak, Self, and Morphic (most of the effort was GUI related, as the 
internal mechanism was fairly easy to add to Python); I succeeded, to some 
extent, see:
   http://patapata.sourceforge.net/
but I did not like the results, see my postmortem critique here:
   http://patapata.sourceforge.net/critique.html

I would be curious about your opinion, as someone also very interested in 
prototype based systems. :-) Essentially, the part of the critique of most 
interest (or disinterest :-) to you would be this section: """The biggest 
issue is that I learned that the seductive idea of prototypes may not be 
as powerful as its execution (especially as an add-on to an existing 
language). Consider what I wrote to someone else: "I've been repeatedly 
confronted with the fact that prototype languages are powerful and elegant 
but ultimately, like Forth, end up losing something related to documenting 
programmer intent. Documenting intent is one of the most important part of 
programming, and that is something that Smalltalk's formal class structure 
enforces for most code over Self, just like C's named variables document 
intent which gets lost manipulating Forth's data stack. Plus, it is hard 
for any great language feature to offset issues like lack of community or 
lack of comprehensive libraries." And after at person suggested you 
usually need to name things before you can share them, I replied: "And I 
agree on the issue of "naming" something in order to share it. Which gets 
back to the issue I mentioned of "documenting intent". With the PataPata 
system I made for Python, there was a choice point where I decided that 
prototypes used by other prototypes as parents needed to be named (a 
difference from Self). And I liked that choice. But then, what am I really 
gaining over Smalltalk (except not having a class side, which is nice, but 
is it worth the extra trouble and confusion?)" So, this leaves me 
questioning the whole move to prototypes. That person also pointed out 
previous work on "Exemplar based Smalltalk", so that is something I should 
look into further, perhaps as a compromise with Prototypes when I 
understand such previous work better."""

Anyway, while I still like prototypes in the same way I like Forth (or now 
its functional cousin, "Joy");
   http://www.latrobe.edu.au/philosophy/phimvt/joy/forth-joy.html
it's just not clear to me that the cost (of being different from plain 
Smalltalk) is worth it to not have a class side (which just gets 
reinvented in other ways anyway, as one distinguished between the exemplar 
an instance inherits from versus the code used to actually build an 
appropriately configured prototype/instance on demand).

> You might also want to see Dan's Squeak-on-JVM (I don't have Java here,
> so I can't test whether this URL still works):
> 
> http://Weather-Dimensions.com/Dan/ForwardToThePast.jnlp

Thanks for the link; yet it works. It hangs on me when I try to do certain 
things with it (like resize the window) and some other things are broken 
(like when I try to save the image) but I can evaluate "1 + 1" and get 2 
in a Workspace! Launching via Web Start works exactly the way I hoped; one 
click (and a security question) later and I am in Squeak. Terrific! Great 
proof of concept. Redrawing is slower than it seems to me it has to be, 
but just stuff to start improving.

I'd imagine one could take a similar approach and get a similar thing 
working under an Apache license (the same idea perhaps but with an even 
earlier version (1.1? 1.13?) of Squeak?). Although even then it is GPL 
incompatible, and being GPL compatible is very important to me. Especially 
for Java, given Sun is going GPL instead of Apache. Frustrating, once 
again. So close, but so far.

Still, people run GPL applications on top of Apache web servers, so maybe 
an Apache Squeak core would be good enough?  Musing out loud, in order to 
make something like this meet the FSF definition of "free" or OSI "open 
source", I would need to know the details of what Squeak version was in 
the end put under Apache? And what an Apache license implied about 
applications written on top of it?

> 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.

> While I can see how Python might seem like a success to be emulated from
> a Squeaker's viewpoint, I am sure the notion would seem very funny to a
> VisualBasic programmer.
> 
> I think there is still an important role for systems which can be
> understood by a single person (an entirely separate issue from making it
> easy or not to collaborate). There are huge advatanges of being able to
> just pick up black boxes created by other people but there are also
> costs - such systems tend to grow exponentially in size for linear gains
> in functionality.

Good point.

--Paul Fernhout