Introducing Huemul

[sig]

> 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.