Thanks Marcus (sorry for the c <> k swap at times.) I like squeak also, but am intuitively more drawn to the Pharo/Seaside combination. I must then accept the altering/evolution of it. I understand you arguments. On Mon, May 2, 2011 at 9:47 PM, Marcus Denker <marcus.denker@inria.fr> wrote:

On May 2, 2011, at 6:49 PM, Ted F.A. van Gaalen wrote:

...

I might suggest. for instance:   - leave deprecated classes in. when ever possible!     if you can't, then rewrite them as a sort of emulation      encapsulation, thus a kind of shell, invoking your new     replacement class.

We want a system that is understandable. Look at Squeak with Etoys. How can you do *anything* with that code base if you keep it 100% compatible? Look at Pharo. How do you think you can do anything of relevance in 2019 if you keep the system source level compatible to 100%? This is a running Museum! And a crappy one, even.

Why do you select Pharo of 2011, why aren't we compatible to Smaltalk 80, the orginal one. Or Smallalk 76? 72?

Why invent Smalltalk at all? Why not just be compatible to what was before?

I would even argue that etoys got into the state that it is *exactly* because it was never refactored and cleaned up and pushed forward.

The Projects that are parts-of-images kind of force etoys to be exactly what you want: binary compatible forever... that is why people didn't improve the one Button, but made their own Button, because "some project might use this class, I can not touch it".

So maybe Squeak is the solution to your problem... I am 100% sure that Squeak in 2019 will be the same as it is now.

But it will be 100% irrelevant, *because* it will be the same as it is now.

(Or it will do what Pharo does, there is a reason for the light-house logo ;-)

       Marcus

-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.