Yes, and, as I told you before I agree. But this does not give us more certainty of a way to do it in practice sustainably. The 'running car' metaphore was meant to be read also meaning that one are producting with a smalltalk besides developing with it. So, one should stop the car only if the costs of stopping are not too high. If one will have to stop several short (cheap) times probably will be no big deal. But what happen when you have a year of a non producting system? That could easily become inaceptable and you should provide alternatives. This is why people other than enthusiasts are still using Squeak with no optimizations at all but producing real value while others invest it's time in exploring new and experimental ways meant to be better ones of making Squeak to run, the future of Squeak.
VM is a program, which runs/interprets smalltalk. The innatural thing is (as for me), that VM itself laying outside smalltalk universe and considered as low-level external entity to smalltalk image. I want to overthrow this concept, and move almost all VM functionality into smalltalk without losing speed, and by gaining a flexibility and scalability at same time. Without this, we doomed to be bound to C, and doomed having a static and rigid VM, hardly maintainable and even more hard to improve/experiment with. Just think about, if VM development speed can be compared to smalltalk dev speed. We can achieve a great progress in many areas in no time. For instance: while i studiyng different approaches for making GC, i saw that there at least two concepts which are never changes: Allocator and Mutator. Allocator is an entity, which keeps eye on system memory and interacts with one or more Mutators by giving them new memory chunks and recycling those which no longer in use. Now think about, if we have these concepts implemented in smalltalk as classes. Then a Process class is no longer something static and preset, its a Mutator and must follow only protocol rules, not anything else. As well as Allocator must follow own protocol rules, so we can have tons of allocators and tons of mutators living in same image and specialized for different tasks. All those 'multi-xxxx' problems which hard to even conceptualize in current system, in new system will be a toy to play with, so any dedicated 'hacker' can experiment very easily comparing to hacking C code for achieving some visible results. And concerning preserving an old standarts i'm totally agree with you. First what is needed is to make new system be 100% compatible for running anything which uses old ways. The trick is, that in old system you don't have any control on VM. You just have it and you can't change it behaviour. So, adding an ability to change and improve VM will not lead to change working smalltalk code, because currently they are perpendicular. Everything will be fine, except places where smalltalk code relies on some fixed things in VM.
Anyway.. I really like to see a piece of software like you described to be materialized,
Thanks. I'm not first, who invents such approach, there already many talks and ideas in this area nowadays - create a self programming system. One of them are COLA/Pepsi project. I thinks this is a future of programming. And what is funny, that old smalltalk having a much stronger positions for achieving these goals comparing to current mainstream languages. _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
