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