Hello Ron,

RJ> There's an issue that I think is more significant, which is that Smalltalk's
RJ> model is that all the classes and objects are there, all the time, in the image.
RJ> Ruby's model is that the classes are NOT there, but are brought in (via require)
RJ> only when the need is explicitly expressed in the source code.

Yes this is a problem, but it is more a coding style problem.
At the moment nobody has such an IDE and therefore people do pretty
ugly stuff during load time. Again the worst example is the tk toolkit
wrapper.

But there is no need for it, most of it is just programmer lazyiness.

RJ> As such, a Smalltalk-style experience is very difficult to produce. Chet
RJ> Hendrickson and I tried, and while we're not the best in the world, we're good
RJ> enough to be sure it's difficult.

RJ> I'd love to see someone do it, but it's not going to be easy, in my opinion.

I thought about this too (well, i get paid for doing this :-).

And i don't think it's so difficult to implement something that is
getting closer to Smalltalk. But i'm not really sure if this will
increase productivity very much, because i believe it is wasting a lot
of time playing with things instead organized programming with writting
test cases. It's just a different way to do things - but this is
left for each one/project to decide what style to choose.

The only problem that you can't solve is that there is no image.
But i believe this is not really important. It's much more about
interactivity (inspector) and the good code browsing of a Smalltalk
System.

I did a little bit lisp programming in the past and the
image was nothing that i would add to the killer features.

Sadly too many people are black-and-white minded. They want this
and exactly this behaviour and having trying to do it exactly
like Smalltalk is impossible.


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's