On 22.02.2009, at 22:42, Keith Hodges wrote:
The traditional approach that Pharo is using produces a new image, developed by a new team as a complete break from the past, and everyone is forced to code to a moving target. This is the process that squeak has been using since before the flood, and it is this process that I have identified as the problem. (I accept that I may be wrong)
So nobody is actually *using* 3.11? (would 4.1 the name of it now?) The problem I see here is that this 3.11 will not have been tested at all. Is that correct?
I myself haven't adopted Pharo, not because you aren't making good changes, or making things better, but because your development process guarantees that there will be problems down the line. Not only do you make it difficult for me to port my current deployments to Pharo with anything other than a step change, since that is your avowed intent. But also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due to the process.
Yes. Beeing incompatible with the past is the only way to make progress.
I thank the pharo team for performing lots of useful research on behalf of the squeak community, I expect that we will be able to adopt most of your innovations, but this will take time, and will be carefully considered, with the backward compatabiity issue in mind.
Pharo is not Research. Research you can find here (for example): http://www.iam.unibe.ch/~denker/mdpubs.cgi?byCategory Enabeling Software Evolution one of the themes of that Research, interestingly. The direction this is going might get clearer from a quote from http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Nier08a : Backward compatibility is the enemy of forward-evolvability. Nevertheless, we cannot live in a world were the old is ignored. A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever will be bound to fail. Programming languages for eternal systems should provide backwards compatibility in the same way: we need a first class description of the history of all code of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back in time easily. The system should provide complete, runnable snapshots of the system at any point in the past. Eternal systems need languages that support continuous development and evolution. But there is another aspect to the language: to think that we can envision the perfect language to realize all future systems is to treat language design like a finite game. Thus a language suited for implement- ing ever-evolving, eternal software systems needs to be itself an eternal program. An eternal language must evolve to incorporate new ideas and practices while it is used. It needs to be extensible and growable from within. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de