[squeak-dev] Re: Packages, Packages, Packages

Miguel Cobá miguel.coba at gmail.com
Sun Dec 13 06:51:33 UTC 2009


On Sat, Dec 12, 2009 at 9:55 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sat, Dec 12, 2009 at 06:01:55PM -0600, Miguel Cob? wrote:
>>
>> Why would you want to do that. 3.8 is dead, must be dead and should be kill.
>> Let the past behind. Let your childs live their lives and go on. You
>> can't oversee them *your* entire life. Squeak can't remain trying to
>> get backwards compatibility forever. That way squeak will never make the
>> foundation changes that needs.
>
> <rant>
>  This is complete utter bullshit. Failing to make a reasonable attempt
>  at backward compatibility is lazy and sloppy, nothing more.
>
>  Norton's third law of innovation:
>    Change is good, stupid is bad. Don't confuse the two.
> </rant>
>
> Ok I feel better now. There are some rather significant forks based on
> Squeak 3.8, and any package management system that fails to accomodate
> this level of variation is in trouble.

I think that that is the real problem with the solution provided by Keith.
He tries to solve the problem for every fork. As if the forks care
about its changes
being compatible with the project they forked from.
Keith mail after mail tried to convince people that a change must be/should be
loaded in every fork existing and future. Utopia. That don't happens.
If I choose Pharo and the software fix that I made works in pharo, my problem is
solved. I couldn't care less if croquet, etoys, olpc or whatever can use it.
The same they don't give a dime if their changes works on squeak.
As an old discussion in this list pointed, the etoys project long ago
forget squeak.
Nevertheless, squeak is worried if their changes could somehow
break/work/load/compile
in squeak. :(

SqueakMap fell apart when Squeak
> 3.9 came along for this very reason, and we can reasonably expect that
> future variations on Squeak will introduce similar incompatibilities.
> This is a good thing, and our tools do need to be flexible enough to
> support it.

The only real example of code that works unmodified in newer hosting
environment is
in the zSeries Operating systems from IBM.
They say (I don't know and maybe will never could verify because I
don't have the millions
to buy a mainframe from them) is that you can run software from the
60s in the 2010 machines
without a single line modified. That is impressive but they charge
accordingly also.
We aren't so well funded nor have a real practical motivation to
verify that every new version
of squeak or pharo can run _every_ old version of _every_ package that
some time ran on
squeak. If someone want to keep using that old software they have two options:

- remain part of the every day smaller group of users (and what that
implies for bug fixing, etc)
- load the old software in the new images and correct the errors found

I choose number 2 because is what happend in the nature. The groups
are stronger than the
individuals.

>
> Dave
>
>
>



More information about the Squeak-dev mailing list