Dan Ingalls wrote:
> Yes, still so organized -- I haven't touched it since 2006.
> [snip]

Thanks for the great overview and the technical hints; I'll muse on them for
a while. And once the code gets formally released, I'm sure you'll announce
it and I'll see what I can do with parts of it. If I release anything before
or after in a similar direction, I'll probably put it here:
  http://sourceforge.net/projects/patapata

>The only C tool I've ever used is the C translator

Good for you. I wasted too much of my youth chasing pointer errors or
resolving deallocation issues -- or teaching others to do the same. :-(
Still, I can't say some of it wasn't fun, in a puzzle-solving kind of way --
except there are generally more important puzzles to solve than off by one
pointer errors or duplicate "free" statements. :-)

>> [Sun's effort to make the JVM have better support for dynamic languages]
> I've left this up to their own technical and marketing decisions.

I'd beg you to at least have lunch or a teleconference with the JRuby guys
now at Sun if you get a chance, but that might seem too groveling to be
persuasive. :-)

Sun's technical leadership seems really serious about dynamic language
support though (if for no other reason than dotnet is doing it?), which is
one reason I think a Squeak-like system on the JVM make some sense, since
the JVM will only get better and better for it (I hope).

You probably know all this, but just in case, see:
  http://www.tbray.org/ongoing/When/200x/2006/09/07/JRuby-guys
"[September 2006] Charles Nutter and Thomas Enebo, better known as “The
JRuby Guys”, are joining Sun this month. Yes, I helped make this happen, and
for once, you’re going to be getting the Sun PR party line, because I wrote
most of it. [Update: It strikes me that thank-yous are in order. Given that
Sun is in the process of (appropriately) slashing some of its engineering
groups, new hires are a little tricky. A lot of people helped, but I think
the biggest contributions were from our Software CTO Bob Brewin and
especially Rich Green, who approved the reqs about fifteen seconds after Bob
and I raised the issue.] ... What will Sun be doing with JRuby? Perhaps most
important, we hope to learn from this experience. Dynamically-typed
languages like Ruby are only beginning to be accepted in the software
mainstream [My note: HAH! :-)], and many of the best practices and tools
remain to be invented. [Also my note: Double HAH! (Not to say there isn't
room for improvement with anything, of course. :-)] Second, we'd like to
ensure that the Ruby programming language, in its JRuby form, is available
to the community of Java developers. Finally, there is a possibility that
the Java platform may prove to be an attractive deployment option for
existing Ruby applications in certain scenarios."

Or, Philippe Marschall supplied this link earlier in this thread to an item
on John Roe's blog (at Sun):
  http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for
"In a previous post I enumerated the various parts that go into a call site
in the JVM. In order to support the program structure of other languages,
especially dynamic languages, the JVM must extend the present schemes of
method definition, invocation, and linkage. We don’t want to create
completely new mechanisms, since we want to reuse the highly developed
infrastructure of mature JVM implementations. The JSR 292 Expert Group,
which I chair, is working on a specification to address this problem in
detail, via carefully chosen changes to the bytecode architecture. The first
EDR (early draft review) will be available in a few weeks. Meanwhile, I
would like to point out some design requirements for method calling in a
multi-language world. The key new requirements are dynamic relinking,
programmable linkage, programmable guards, descriptor polymorphism, and
method handles. ... "

As I see it, you could look at the ubiquitousness of the JVM one of two ways
(or both at the same time :-). Either Smalltalk failed, because most people
are not using a pure Smalltalk VM. Or, on the other hand, Smalltalk
succeeded enormously because just about everyone now programs with most of
the ideas you and Alan (and others) got going in a big way in the
1960s/1970s -- objects, garbage collection, a cross-platform virtual
machine, fancy IDEs like Eclipse, and so on, even to the point where a major
technology company changes its stock ticker symbol to be the name of an
object-oriented virtual machine (JAVA). Maybe the the JVM and the world is
still not Smalltalk-ish 100%, and maybe there has been a lot of needless
suffering along the way, but as I've heard, "first they ignore you, then
they laugh at you, then they fight you, and then you win." :-) The way the
JVM is evolving to dynamic languages support, and with new
functional/OO-hybrid languages like Scala/JVM or Clojure being written for
it, or ports of almost-pure OO ones like Jython or JRuby, I'd say Smalltalk
ideas were doing pretty good. :-) I've been a long time Java and JVM hater
(compared to VisualWorks or Squeak), but at some point, with so many
options, now that Java and the JVM are "Free as in freedom" I'm pretty much
orienting the future of my work around the JVM (and related languages) as it
being "good enough". I still want to avoid Java as much a possible though.
:-) The only question for me (as a free software developer) at this point
is, will I be using Smalltalk syntax (and related tools and semantics) more
on the JVM or will I be using other languages more (Jython, Scala, JRuby,
JavaScript, Clojure, whatever)? By the way, a place to send you announcement
when you release:
  "Programming Languages for the Java Virtual Machine"
  http://www.robert-tolksdorf.de/vmlanguages.html

I hesitate to post this link lest you take the title the wrong way :-) but
here goes:
  "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own
Incompetence Lead to Inflated Self-Assessments"
  http://www.apa.org/journals/features/psp7761121.pdf
In your case (despite the title :-) the important thing is that the paper
also suggests *very competent* people tend to *underestimate* their own
relative competence, because they typically overestimate the competence of
their peers. :-)

So, don't be *too* modest at Sun. :-) Maybe before we know it, the JVM could
be 80% optimized for Smalltalk-style "doesNotUnderstand:" method dispatching
and restartable exceptions with just a couple extra JVM bytecodes(?) while
still supporting statically typed languages like Java or Scala/JVM in a
cross-platform way -- for the best of both worlds.

But in any case, no pressure. In the end, it doesn't matter a whole lot if
Squeak goes, say, 3X faster on the JVM if it is too stressful
bureaucratically to change the JVM to suit Smalltalk better; that much would
only about a three year lag following Moore's law style exponential
computing increases anyway. :-)  And I could also hope that using Java
objects directly within a Squeak/JVM might get another 3X-10X performance
boost compared to the link you posted (assuming other desirable features
could be maintained). And at that point, the 80/20 law takes over, where
bottlenecks can probably be translated to cross-platform Java or Scala/JVM
more easily than optimizing the JVM further or making Squeak faster somehow.
In the end the value is more in how well overall a Squeak+JVM+JavaEcosystem
system supports individual or group creativity, and speed is only one part
of that (and probably not even the most important by far these days).

I wish you continued fun with your new projects (like Lively -- amazing stuff).

Thanks again for all the technical hints.

All the best.

--Paul Fernhout