Posted by
Marcus Denker on
Feb 23, 2009; 7:29am
URL: https://forum.world.st/What-about-ifNotNil-and-ifNotNilDo-tp1309537p1309544.html
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?byCategoryEnabeling 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 --
[hidden email]
http://www.marcusdenker.de_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project