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