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 <[email protected]> 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. > > >
