Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Mariano Martinez Peck


On Wed, Apr 27, 2011 at 11:25 AM, Ted F.A. van Gaalen <[hidden email]> wrote:
Hi Marcus
As I wrote, I am thinking from the perspective
of an application developer, a typical pharo-user ?
imagine that I/we have  hundreds of
apps written, will they run unchanged
say 5 years from now?


Probably not. We would like to improve the system and clean it. Unfortunately, sometimes there is no other way than loosing backward compatibility.
What do you prefer?  Pharo choose a better system.

If you/companies do not even collaborate with updating your code (don't say even fixing bugs or submitting code) ...then don't expect anything from Pharo. Pharo is open-source, free and it is build in the free time.

And I think Pharo is not the only one....out there most of the languages change a lot between versions, Python, blah.

Cheers

Mariano


 

Regards
Ted

On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <[hidden email]> wrote:
>
> On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote:
>
>> Good morning Mariano
>>
>> This is something I wrote to Adrian Lienhard,
>> when an image did not run, straight out of the box
>> so to speak, because of VM differences
>> Some thoughts about reliability, and, very important
>> IMHO, upward compatibility.
>>
>> Thanks & Regards
>> Ted
>>
>>>>>
>> ?
>> I did expect that, nota bene working with
>> the Seaside supplied one-click image and
>> the virtual machine supplied with it,
>> provided on the Seaside.st site itself,
>> that everything is (and remains)
>> 100% upward compatible,
>> no matter what VM is or will be used in the future.
>
> This is impossible and, in the end, not a good idea.
>
> We can not be compatible forever, was this would mean
> that we can not improve anything.
>
> e.g. imagine someone would fix the VM to be better.
> (e.g. a modern object format).
>
> Do you really request to then *not* do this change because
> this VM could not run old images? (and new images would
> not run on old VMs?).
>
> Do you want to have a Future or be compatible to the Past?
>
>        Marcus
>
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
>




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

TedVanGaalen
Thanks,
(I have mixed feelings about this, it's a sort of trade-off).
I hope that on the source level (particularly system classes) at
least upward compatibility remains.
Greetings :o)
Ted

On Wed, Apr 27, 2011 at 11:31 AM, Mariano Martinez Peck
<[hidden email]> wrote:

>
>
> On Wed, Apr 27, 2011 at 11:25 AM, Ted F.A. van Gaalen <[hidden email]>
> wrote:
>>
>> Hi Marcus
>> As I wrote, I am thinking from the perspective
>> of an application developer, a typical pharo-user ?
>> imagine that I/we have  hundreds of
>> apps written, will they run unchanged
>> say 5 years from now?
>
>
> Probably not. We would like to improve the system and clean it.
> Unfortunately, sometimes there is no other way than loosing backward
> compatibility.
> What do you prefer?  Pharo choose a better system.
>
> If you/companies do not even collaborate with updating your code (don't say
> even fixing bugs or submitting code) ...then don't expect anything from
> Pharo. Pharo is open-source, free and it is build in the free time.
>
> And I think Pharo is not the only one....out there most of the languages
> change a lot between versions, Python, blah.
>
> Cheers
>
> Mariano
>
>
>
>>
>> Regards
>> Ted
>>
>> On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <[hidden email]>
>> wrote:
>> >
>> > On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote:
>> >
>> >> Good morning Mariano
>> >>
>> >> This is something I wrote to Adrian Lienhard,
>> >> when an image did not run, straight out of the box
>> >> so to speak, because of VM differences
>> >> Some thoughts about reliability, and, very important
>> >> IMHO, upward compatibility.
>> >>
>> >> Thanks & Regards
>> >> Ted
>> >>
>> >>>>>
>> >> ?
>> >> I did expect that, nota bene working with
>> >> the Seaside supplied one-click image and
>> >> the virtual machine supplied with it,
>> >> provided on the Seaside.st site itself,
>> >> that everything is (and remains)
>> >> 100% upward compatible,
>> >> no matter what VM is or will be used in the future.
>> >
>> > This is impossible and, in the end, not a good idea.
>> >
>> > We can not be compatible forever, was this would mean
>> > that we can not improve anything.
>> >
>> > e.g. imagine someone would fix the VM to be better.
>> > (e.g. a modern object format).
>> >
>> > Do you really request to then *not* do this change because
>> > this VM could not run old images? (and new images would
>> > not run on old VMs?).
>> >
>> > Do you want to have a Future or be compatible to the Past?
>> >
>> >        Marcus
>> >
>> >
>> > --
>> > Marcus Denker  -- http://www.marcusdenker.de
>> > INRIA Lille -- Nord Europe. Team RMoD.
>> >
>> >
>> >
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
In reply to this post by Mariano Martinez Peck

On Apr 27, 2011, at 11:47 AM, Ted F.A. van Gaalen wrote:

> Thanks,
> (I have mixed feelings about this, it's a sort of trade-off).

It's the trade-off between *having a future* or *having the past*.
Is the past of Smalltalk valuable enough to be able to not invest
in the Future? Lot's of people think it is, but Pharo was started
to *exactly* not do that.

10 years of "doing nothing" with Squeak is for me enough for
the rest of my life... the reason there was not backward-compatibility,
but "wanting too much". ("not do the next step because Squeak is so
imortant that we can not settle for less then perfection").

But *how* you rationalize standing still is not really important...

> I hope that on the source level (particularly system classes) at
> least upward compatibility remains.

We deprecate important APIs and keep them for one Release.

"Doing nothing is not an option".

        Marcus



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


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Mariano Martinez Peck
In reply to this post by TedVanGaalen


On Wed, Apr 27, 2011 at 11:47 AM, Ted F.A. van Gaalen <[hidden email]> wrote:
Thanks,
(I have mixed feelings about this, it's a sort of trade-off).

Exactly. So do I. And so do us. That's a trade-off. And notice that we do not break backward compatibility just because. There are usually reasons behind that which justify such decisions.
And as Marcus said, most of the times (sometimes we had some problems) we have a deprecation process where we (usually) say which should be used instead.
If large projects like Seaside, Moose, etc, could move from Pharo 1.0 up to Pharo 1.3, I think most applications can. The applications I have developed so far, has been ported from 1.0 to 1.3 almost without changes.
 
I hope that on the source level (particularly system classes) at
least upward compatibility remains.
Greetings :o)
Ted

On Wed, Apr 27, 2011 at 11:31 AM, Mariano Martinez Peck
<[hidden email]> wrote:
>
>
> On Wed, Apr 27, 2011 at 11:25 AM, Ted F.A. van Gaalen <[hidden email]>
> wrote:
>>
>> Hi Marcus
>> As I wrote, I am thinking from the perspective
>> of an application developer, a typical pharo-user ?
>> imagine that I/we have  hundreds of
>> apps written, will they run unchanged
>> say 5 years from now?
>
>
> Probably not. We would like to improve the system and clean it.
> Unfortunately, sometimes there is no other way than loosing backward
> compatibility.
> What do you prefer?  Pharo choose a better system.
>
> If you/companies do not even collaborate with updating your code (don't say
> even fixing bugs or submitting code) ...then don't expect anything from
> Pharo. Pharo is open-source, free and it is build in the free time.
>
> And I think Pharo is not the only one....out there most of the languages
> change a lot between versions, Python, blah.
>
> Cheers
>
> Mariano
>
>
>
>>
>> Regards
>> Ted
>>
>> On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <[hidden email]>
>> wrote:
>> >
>> > On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote:
>> >
>> >> Good morning Mariano
>> >>
>> >> This is something I wrote to Adrian Lienhard,
>> >> when an image did not run, straight out of the box
>> >> so to speak, because of VM differences
>> >> Some thoughts about reliability, and, very important
>> >> IMHO, upward compatibility.
>> >>
>> >> Thanks & Regards
>> >> Ted
>> >>
>> >>>>>
>> >> ?
>> >> I did expect that, nota bene working with
>> >> the Seaside supplied one-click image and
>> >> the virtual machine supplied with it,
>> >> provided on the Seaside.st site itself,
>> >> that everything is (and remains)
>> >> 100% upward compatible,
>> >> no matter what VM is or will be used in the future.
>> >
>> > This is impossible and, in the end, not a good idea.
>> >
>> > We can not be compatible forever, was this would mean
>> > that we can not improve anything.
>> >
>> > e.g. imagine someone would fix the VM to be better.
>> > (e.g. a modern object format).
>> >
>> > Do you really request to then *not* do this change because
>> > this VM could not run old images? (and new images would
>> > not run on old VMs?).
>> >
>> > Do you want to have a Future or be compatible to the Past?
>> >
>> >        Marcus
>> >
>> >
>> > --
>> > Marcus Denker  -- http://www.marcusdenker.de
>> > INRIA Lille -- Nord Europe. Team RMoD.
>> >
>> >
>> >
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Stéphane Ducasse
In reply to this post by Marcus Denker-4
> It's the trade-off between *having a future* or *having the past*.

***excellent** we should twitter this one!!!


> Is the past of Smalltalk valuable enough to be able to not invest
> in the Future? Lot's of people think it is, but Pharo was started
> to *exactly* not do that.
>
> 10 years of "doing nothing" with Squeak is for me enough for
> the rest of my life... the reason there was not backward-compatibility,
> but "wanting too much". ("not do the next step because Squeak is so
> imortant that we can not settle for less then perfection").
>
> But *how* you rationalize standing still is not really important...
>
>> I hope that on the source level (particularly system classes) at
>> least upward compatibility remains.
>
> We deprecate important APIs and keep them for one Release.
>
> "Doing nothing is not an option".

Another excellent quote to twitter. You are in good form today.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
In reply to this post by Marcus Denker-4

On Apr 27, 2011, at 10:00 PM, Stéphane Ducasse wrote:

>> It's the trade-off between *having a future* or *having the past*.
>
> ***excellent** we should twitter this one!!!
>
>
>>
>> "Doing nothing is not an option".
>
> Another excellent quote to twitter. You are in good form today.
>

I am on holidays ;-)


        Marcus


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


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Sven Van Caekenberghe
In reply to this post by Stéphane Ducasse

On 27 Apr 2011, at 19:19, Stéphane Ducasse wrote:

>> It's the trade-off between *having a future* or *having the past*.
>
> ***excellent** we should twitter this one!!!


>> "Doing nothing is not an option".
>
> Another excellent quote to twitter. You are in good form today.
>
> Stef

Indeed, very cool quotes! Put them on the home page or at least somewhere on the website.

Sven



Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Markus Fritsche-3
In reply to this post by Mariano Martinez Peck
Hi,

2011/4/27 Mariano Martinez Peck <[hidden email]>:
> And as Marcus said, most of the times (sometimes we had some problems) we
> have a deprecation process where we (usually) say which should be used
> instead.

From a a-little-bit-more-than-user perspective I am looking at

SmalltalkImage>>#hasBindingThatBeginsWith: aString
       self deprecated: 'Use Smalltalk globals'.
       ^globals hasBindingThatBeginsWith: aString

Well, with a bit of analysis, I would be able to figure out, that the
author might have intended that I should search the SystemDictionary
myself. I feel like an additional comment would have been helpful.

Same with the other problem I had with ServiceRegistry - it is gone
and it is not easy to find out what that was supposed to do. Next step
is to compare squeak and the Pharo releases to find out what happened
to it (the issue tracker does not easily yield results for this, but
maybe I searched in the wrong way).

I know there is no easy fix for this, as "fast deprecation" was what
made Pharo manageable compared to other image-based smalltalk dialects
(not to mention anything specific ;)) but there is a lot of
interesting code on squeaksource that naturally breaks - for those
interested in that code, it would be helpful to give a bit more advice
on "porting" and "the path of deprecation".

Enough trolling for tonight :)

Regards, Markus

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Igor Stasenko
On 2 May 2011 00:48, Markus Fritsche <[hidden email]> wrote:

> Hi,
>
> 2011/4/27 Mariano Martinez Peck <[hidden email]>:
>> And as Marcus said, most of the times (sometimes we had some problems) we
>> have a deprecation process where we (usually) say which should be used
>> instead.
>
> From a a-little-bit-more-than-user perspective I am looking at
>
> SmalltalkImage>>#hasBindingThatBeginsWith: aString
>       self deprecated: 'Use Smalltalk globals'.
>       ^globals hasBindingThatBeginsWith: aString
>
> Well, with a bit of analysis, I would be able to figure out, that the
> author might have intended that I should search the SystemDictionary
> myself. I feel like an additional comment would have been helpful.
>
> Same with the other problem I had with ServiceRegistry - it is gone
> and it is not easy to find out what that was supposed to do. Next step
> is to compare squeak and the Pharo releases to find out what happened
> to it (the issue tracker does not easily yield results for this, but
> maybe I searched in the wrong way).
>
> I know there is no easy fix for this, as "fast deprecation" was what
> made Pharo manageable compared to other image-based smalltalk dialects
> (not to mention anything specific ;)) but there is a lot of
> interesting code on squeaksource that naturally breaks - for those
> interested in that code, it would be helpful to give a bit more advice
> on "porting" and "the path of deprecation".
>

An advice is simple:
1. try loading the code using most recent image, try running it.
2. fix errors & bugs you found
3. Repeat from 1.

This is what package maintainers should usually do all the time.
And there is no magic: you have to get your hands dirty and make
things work (again).

Now, if nobody doing it for years, its not a Pharo failure that some
code turned to be broken.
I like that pharoers are not afraid to break things (of course if they
breaking them for good ;).

And besides.. you can always use years old image and happily load all
code in it and it will work there.

So, you are free to choose either:
 - stay with old image version where all dusty code working
 - running your code on most recent Pharo version and using its new features
:)


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

TedVanGaalen
Hi All instances of HumanBeing

Then, another question remains:

Will my image of 2011 still work correctly
on the VM of AD 2019 (the ones that than probably
run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
or the VM created for a newly emerged computer system?

"All"  I wish for is:
  -= Backward Source Compatibilty =-
whenever possible because:
-in five years the one could have written a huge amount of coding,
for instance, a large ERP system, or an large internet trading
system. Often these  consists of (10)thousands of lines
of coding, even in Smalltalk. Many years of development and
effort, blood sweat and tears have gone in to it.
Finally everything is debugged and tested. And may happy
users depend on it

Assume that throughout this all coding are countless
references to classes that are perfectly normal at the
time of writing. This no exception.

Then one or tow releases later:

If these classes are removed, because The Respectful
Tool Developers (e.g. (not only) Pharo) in their wisdom find it
necessary to render these obsolete, then this has enormous
consequences:
One would have to edit and test, and in some cases rewrite (!)
very large amounts of coding costing considerable amounts
of time=money.
Now, imagine yourself as an application programmer maintaining
this huge amount of coding, which is not working anymore,
not because you did it wrong, but because of chances in the
Developmen Tool? How would feel? Like shit. Tons of work
gone down the drain. Besides, are you going to ask your
customer to pay for this?  You can't of course. He/she will
say things like: "Why? It works perfectly!"etc.

Naturally one wishes to migrate to new images releases and
happily utilize the new features that come with it, no question
about it. But as it seems now, this is out of the question,
because with every release, things are taken out, changed
without any respect to backward compatibility.


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.

Why not have the best of both worlds? What's the problem?
Things can live next to each other, if you do it well.

If you don't I can only resort to the most basic of
system core classes. Ergo: limit myself to what I am
(reasonable certain of)


I see lines on this forum like:
"Seems to be unused. I vote for removing.."
Assuming is a bad thing in software development.
How can you be certain that:
No one really uses the component anymore?
You can't.

The essence of it all is:

I saw Pharo fit to write production software,
especially with Seaside!
but how can I use it for this, seen the above
described arguments? If all the things
I write become useless with a next release?



(Sorry, we don't sell tires for your
car anymore, because we chanced
the diameter of them, we recommend
you to change/modify your car.. )

A perfect example:
(most) internet browsers
are backward compatible.

I rest my case, enough said..

Kind regards
Ted





On Mon, May 2, 2011 at 4:03 PM, Igor Stasenko <[hidden email]> wrote:

> On 2 May 2011 00:48, Markus Fritsche <[hidden email]> wrote:
>> Hi,
>>
>> 2011/4/27 Mariano Martinez Peck <[hidden email]>:
>>> And as Marcus said, most of the times (sometimes we had some problems) we
>>> have a deprecation process where we (usually) say which should be used
>>> instead.
>>
>> From a a-little-bit-more-than-user perspective I am looking at
>>
>> SmalltalkImage>>#hasBindingThatBeginsWith: aString
>>       self deprecated: 'Use Smalltalk globals'.
>>       ^globals hasBindingThatBeginsWith: aString
>>
>> Well, with a bit of analysis, I would be able to figure out, that the
>> author might have intended that I should search the SystemDictionary
>> myself. I feel like an additional comment would have been helpful.
>>
>> Same with the other problem I had with ServiceRegistry - it is gone
>> and it is not easy to find out what that was supposed to do. Next step
>> is to compare squeak and the Pharo releases to find out what happened
>> to it (the issue tracker does not easily yield results for this, but
>> maybe I searched in the wrong way).
>>
>> I know there is no easy fix for this, as "fast deprecation" was what
>> made Pharo manageable compared to other image-based smalltalk dialects
>> (not to mention anything specific ;)) but there is a lot of
>> interesting code on squeaksource that naturally breaks - for those
>> interested in that code, it would be helpful to give a bit more advice
>> on "porting" and "the path of deprecation".
>>
>
> An advice is simple:
> 1. try loading the code using most recent image, try running it.
> 2. fix errors & bugs you found
> 3. Repeat from 1.
>
> This is what package maintainers should usually do all the time.
> And there is no magic: you have to get your hands dirty and make
> things work (again).
>
> Now, if nobody doing it for years, its not a Pharo failure that some
> code turned to be broken.
> I like that pharoers are not afraid to break things (of course if they
> breaking them for good ;).
>
> And besides.. you can always use years old image and happily load all
> code in it and it will work there.
>
> So, you are free to choose either:
>  - stay with old image version where all dusty code working
>  - running your code on most recent Pharo version and using its new features
> :)
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

NorbertHartl

Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen:

> Hi All instances of HumanBeing
>
> Then, another question remains:
>
> Will my image of 2011 still work correctly
> on the VM of AD 2019 (the ones that than probably
> run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
> or the VM created for a newly emerged computer system?
>
Well, forecasts are always hard to do. Basically I would say if you can get the current vm running on these releases than your image should run as well. If it doesn't run you need to think why you need such a new system. And you need to think whom to blame: intel, amd, arm, canonical, microsoft, apple, the linux community or the squeak/pharo community.

> "All"  I wish for is:
>  -= Backward Source Compatibilty =-
> whenever possible because:
> -in five years the one could have written a huge amount of coding,
> for instance, a large ERP system, or an large internet trading
> system. Often these  consists of (10)thousands of lines
> of coding, even in Smalltalk. Many years of development and
> effort, blood sweat and tears have gone in to it.
> Finally everything is debugged and tested. And may happy
> users depend on it
>
If it ran for 5 years without the need for a change where does this need come from out of a sudden?

> Assume that throughout this all coding are countless
> references to classes that are perfectly normal at the
> time of writing. This no exception.
>
Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine.

> Then one or tow releases later:
>
> If these classes are removed, because The Respectful
> Tool Developers (e.g. (not only) Pharo) in their wisdom find it
> necessary to render these obsolete, then this has enormous
> consequences:
> One would have to edit and test, and in some cases rewrite (!)
> very large amounts of coding costing considerable amounts
> of time=money.
> Now, imagine yourself as an application programmer maintaining
> this huge amount of coding, which is not working anymore,
> not because you did it wrong, but because of chances in the
> Developmen Tool? How would feel? Like shit. Tons of work
> gone down the drain. Besides, are you going to ask your
> customer to pay for this?  You can't of course. He/she will
> say things like: "Why? It works perfectly!"etc.
>
And they are right. Why do you want to change it if it runs perfectly? Why do you want to change it if even your customers don't want to? Thanks to smalltalk as long as you stay in the same image your development tool will stay the same.

> Naturally one wishes to migrate to new images releases and
> happily utilize the new features that come with it, no question
> about it. But as it seems now, this is out of the question,
> because with every release, things are taken out, changed
> without any respect to backward compatibility.
>
What is it "naturally" to migrate? Just for the sake of it? Asking for trouble? I think you need a good reasons to migrate.

>
> 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.
>
> Why not have the best of both worlds? What's the problem?
> Things can live next to each other, if you do it well.
>
Well, it wouldn't be the best of both worlds. Leaving every cruft in the image will turn it into a mess. There is a legacy problem _and_ a newcomer problem. With collecting cruft you are making it hard for newcomers to be able to work with the image. You as part of the legacy problem are a more experienced developer than a newcomer. Can you imaging how hard it is for a newbie to digest a big pile of code?

> If you don't I can only resort to the most basic of
> system core classes. Ergo: limit myself to what I am
> (reasonable certain of)
>
>
> I see lines on this forum like:
> "Seems to be unused. I vote for removing.."
> Assuming is a bad thing in software development.
> How can you be certain that:
> No one really uses the component anymore?
> You can't.
>
> The essence of it all is:
>
> I saw Pharo fit to write production software,
> especially with Seaside!
> but how can I use it for this, seen the above
> described arguments? If all the things
> I write become useless with a next release?
>
To be honest I cannot share your view. You are willing to benefit from all the new features a new release brings along. At the same time you are reluctant to migrate your software for the changes that came together with this new features. To me it sounds that you are making your life too easy.
You have a lot of options in software development. If you have an old system that works just don't change it. There is a whole industry for legacy main frame applications that are kept alive _because_ they just work and there is only risk in changing it. As soon as you change the software you potentially destabilizing it. So upgrading software only for a handful of new features is a high risk if your application is that critical.
On the other hand you shouldn't wait for too long to adopt changes in the frameworks you use. Only if you keep for too long the step is huge. You could continously migrate at an easy level.
There are intermediate levels between those two extremes and you need to chose one.
>
>
> (Sorry, we don't sell tires for your
> car anymore, because we chanced
> the diameter of them, we recommend
> you to change/modify your car.. )
>
Did you every try to get a tire for a 60s car? You don't get these in the usual places!

> A perfect example:
> (most) internet browsers
> are backward compatible.
>
Yep, and the internet suffered a lot because too many people have tried for too long to be compatible to a shitty browser like IE6.

Norbert

> I rest my case, enough said..
>
> Kind regards
> Ted
>
>
>
>
>
> On Mon, May 2, 2011 at 4:03 PM, Igor Stasenko <[hidden email]> wrote:
>> On 2 May 2011 00:48, Markus Fritsche <[hidden email]> wrote:
>>> Hi,
>>>
>>> 2011/4/27 Mariano Martinez Peck <[hidden email]>:
>>>> And as Marcus said, most of the times (sometimes we had some problems) we
>>>> have a deprecation process where we (usually) say which should be used
>>>> instead.
>>>
>>> From a a-little-bit-more-than-user perspective I am looking at
>>>
>>> SmalltalkImage>>#hasBindingThatBeginsWith: aString
>>>       self deprecated: 'Use Smalltalk globals'.
>>>       ^globals hasBindingThatBeginsWith: aString
>>>
>>> Well, with a bit of analysis, I would be able to figure out, that the
>>> author might have intended that I should search the SystemDictionary
>>> myself. I feel like an additional comment would have been helpful.
>>>
>>> Same with the other problem I had with ServiceRegistry - it is gone
>>> and it is not easy to find out what that was supposed to do. Next step
>>> is to compare squeak and the Pharo releases to find out what happened
>>> to it (the issue tracker does not easily yield results for this, but
>>> maybe I searched in the wrong way).
>>>
>>> I know there is no easy fix for this, as "fast deprecation" was what
>>> made Pharo manageable compared to other image-based smalltalk dialects
>>> (not to mention anything specific ;)) but there is a lot of
>>> interesting code on squeaksource that naturally breaks - for those
>>> interested in that code, it would be helpful to give a bit more advice
>>> on "porting" and "the path of deprecation".
>>>
>>
>> An advice is simple:
>> 1. try loading the code using most recent image, try running it.
>> 2. fix errors & bugs you found
>> 3. Repeat from 1.
>>
>> This is what package maintainers should usually do all the time.
>> And there is no magic: you have to get your hands dirty and make
>> things work (again).
>>
>> Now, if nobody doing it for years, its not a Pharo failure that some
>> code turned to be broken.
>> I like that pharoers are not afraid to break things (of course if they
>> breaking them for good ;).
>>
>> And besides.. you can always use years old image and happily load all
>> code in it and it will work there.
>>
>> So, you are free to choose either:
>>  - stay with old image version where all dusty code working
>>  - running your code on most recent Pharo version and using its new features
>> :)
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Ramon Leon-5
In reply to this post by TedVanGaalen
On 05/02/2011 09:49 AM, Ted F.A. van Gaalen wrote:
> But as it seems now, this is out of the question,
> because with every release, things are taken out, changed
> without any respect to backward compatibility.

I don't think that's actually true.  If you step through each release I
think you'll find things deprecated first, to warn people something will
be delete next version.  You should be able to upgrade stepwise through
each version and fix your code to not use deprecated code, then move on
to the next version.  Deprecation is respecting backwards compatibility,
it lets you know change is coming.

--
Ramon Leon
http://onsmalltalk.com

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

TedVanGaalen
In reply to this post by NorbertHartl
On Mon, May 2, 2011 at 7:44 PM, Norbert Hartl <[hidden email]> wrote:

>
> Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen:
>
>> Hi All instances of HumanBeing
>>
>> Then, another question remains:
>>
>> Will my image of 2011 still work correctly
>> on the VM of AD 2019 (the ones that than probably
>> run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
>> or the VM created for a newly emerged computer system?
>>
> Well, forecasts are always hard to do. Basically I would say if you can get the current vm running on these releases than your image should run as well. If it doesn't run you need to think why you need such a new system. And you need to think whom to blame: intel, amd, arm, canonical, microsoft, apple, the linux community or the squeak/pharo community.
Blaming no one.  Anyway, coming to think of it, it could then probably
run in a softBox

>
>> "All"  I wish for is:
>>  -= Backward Source Compatibilty =-
>> whenever possible because:
>> -in five years the one could have written a huge amount of coding,
>> for instance, a large ERP system, or an large internet trading
>> system. Often these  consists of (10)thousands of lines
>> of coding, even in Smalltalk. Many years of development and
>> effort, blood sweat and tears have gone in to it.
>> Finally everything is debugged and tested. And may happy
>> users depend on it
>>
> If it ran for 5 years without the need for a change where does this need come from out of a sudden?
My text is not quite clear, sorry. I meant: Code accumulated over a
longer period.
>
>> Assume that throughout this all coding are countless
>> references to classes that are perfectly normal at the
>> time of writing. This no exception.
>>
> Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine.

(A) I would always want to move my packages to newer releases because
they [might] have better performance due to more optimized core
classes ?(in addition to  the VM performance)
and because of adding additional logic to the existing app that could
deploy new features..


>
>> Then one or tow releases later:
>>
>> If these classes are removed, because The Respectful
>> Tool Developers (e.g. (not only) Pharo) in their wisdom find it
>> necessary to render these obsolete, then this has enormous
>> consequences:
>> One would have to edit and test, and in some cases rewrite (!)
>> very large amounts of coding costing considerable amounts
>> of time=money.
>> Now, imagine yourself as an application programmer maintaining
>> this huge amount of coding, which is not working anymore,
>> not because you did it wrong, but because of chances in the
>> Developmen Tool? How would feel? Like shit. Tons of work
>> gone down the drain. Besides, are you going to ask your
>> customer to pay for this?  You can't of course. He/she will
>> say things like: "Why? It works perfectly!"etc.
>>
> And they are right. Why do you want to change it if it runs perfectly? Why do you want to change it if even your customers don't want to? Thanks to smalltalk as long as you stay in the same image your development tool will stay the same.
>
>> Naturally one wishes to migrate to new images releases and
>> happily utilize the new features that come with it, no question
>> about it. But as it seems now, this is out of the question,
>> because with every release, things are taken out, changed
>> without any respect to backward compatibility.
>>
> What is it "naturally" to migrate? Just for the sake of it? Asking for trouble? I think you need a good reasons to migrate.
>
Please see (A)bove

>>
>> 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.
>>
>> Why not have the best of both worlds? What's the problem?
>> Things can live next to each other, if you do it well.
>>
> Well, it wouldn't be the best of both worlds. Leaving every cruft in the image will turn it into a mess. There is a legacy problem _and_ a newcomer problem. With collecting cruft you are making it hard for newcomers to be able to work with the image. You as part of the legacy problem are a more experienced developer than a newcomer. Can you imaging how hard it is for a newbie to digest a big pile of code?
>
Actually, I am still a bit of a newbie in Smalltalk and yes it takes a lot of
time to get familiar with all objects.. One could mark "cruft" classes
as being only there for compatibility reasons, and drop the from
tutorials etc.

>> If you don't I can only resort to the most basic of
>> system core classes. Ergo: limit myself to what I am
>> (reasonable certain of)
>>
>>
>> I see lines on this forum like:
>> "Seems to be unused. I vote for removing.."
>> Assuming is a bad thing in software development.
>> How can you be certain that:
>> No one really uses the component anymore?
>> You can't.
>>
>> The essence of it all is:
>>
>> I saw Pharo fit to write production software,
>> especially with Seaside!
>> but how can I use it for this, seen the above
>> described arguments? If all the things
>> I write become useless with a next release?
>>
> To be honest I cannot share your view. You are willing to benefit from all the new features a new release brings along. At the same time you are reluctant to migrate your software for the changes that came together with this new features. To me it sounds that you are making your life too easy.
The reluctance comes with having to migrate huge amounts of work
.
> You have a lot of options in software development. If you have an old system that works just don't change it.
That's true.
>There is a whole industry for legacy main frame applications that are kept alive _because_ they just work and there is only risk in changing it. As soon as you change the software you potentially destabilizing it. So upgrading software only for a handful of new features is a high risk if your application is that critical.
I am aware of that due to hard experience.
> On the other hand you shouldn't wait for too long to adopt changes in the frameworks you use. Only if you keep for too long the step is huge. You could continously migrate at an easy level.
> There are intermediate levels between those two extremes and you need to chose one.
I agree, but what, If a customer comes to me after 5 years and asked to modify
this long forgotten application?
>>
>>
>> (Sorry, we don't sell tires for your
>> car anymore, because we chanced
>> the diameter of them, we recommend
>> you to change/modify your car.. )
>>
> Did you every try to get a tire for a 60s car? You don't get these in the usual places!
What about a car from 2010 :o)
>
>> A perfect example:
>> (most) internet browsers
>> are backward compatible.
>>
> Yep, and the internet suffered a lot because too many people have tried for too long to be compatible to a shitty browser like IE6.
Very true True. loaded IE9 not really an improvement.
using Chrome here.
>
> Norbert

Thanks for your serious comment, Norbert.

A lot of my (far from perfect) thinking is in
this almost utopian perspective:

I strive to keep everything in one and only
image, without exception.

Almost science fiction and at the moment
at least for large sites technically still nearly impossible,
but think for a moment of a system with all of its data
completely integrated into the image..
without the use of external files, and databases.

-with highly optimized and advanced collection classes.

-advanced agent objects "alive" in the image for
  security, integrity and maintenance.

-backup is merely "pushing down" the complete image,
 which is therefore integral and even
 maintains the complete status quo.

-systems communicate with other systems through
 protected very high speed links.

-interfacing with humans through
  virtual reality browser systems.

It would require very large images (> Terabytes)
I am thinking of light-logic based systems with
holographic memory and a very large number
of processors with hard wired Smalltalk primitives.
no VM but an absolute machine.

Think of the HAL9000 computer in the movies
"A space Odyssey 2001" and ... 2010

2011  (many years too late :o)
I want to work this out further. If you know of
people/docs/sites also thinking in that direction
(there must be) please let me know.
Reality grows in fantasy, doesn't it?

As a consequence ALL applications should
be integrated in a single image. that is:
all logic and data for e.g. a whole company.
it's brain..


Regards
Ted





>>
>>
>>
>>
>>
>> On Mon, May 2, 2011 at 4:03 PM, Igor Stasenko <[hidden email]> wrote:
>>> On 2 May 2011 00:48, Markus Fritsche <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> 2011/4/27 Mariano Martinez Peck <[hidden email]>:
>>>>> And as Marcus said, most of the times (sometimes we had some problems) we
>>>>> have a deprecation process where we (usually) say which should be used
>>>>> instead.
>>>>
>>>> From a a-little-bit-more-than-user perspective I am looking at
>>>>
>>>> SmalltalkImage>>#hasBindingThatBeginsWith: aString
>>>>       self deprecated: 'Use Smalltalk globals'.
>>>>       ^globals hasBindingThatBeginsWith: aString
>>>>
>>>> Well, with a bit of analysis, I would be able to figure out, that the
>>>> author might have intended that I should search the SystemDictionary
>>>> myself. I feel like an additional comment would have been helpful.
>>>>
>>>> Same with the other problem I had with ServiceRegistry - it is gone
>>>> and it is not easy to find out what that was supposed to do. Next step
>>>> is to compare squeak and the Pharo releases to find out what happened
>>>> to it (the issue tracker does not easily yield results for this, but
>>>> maybe I searched in the wrong way).
>>>>
>>>> I know there is no easy fix for this, as "fast deprecation" was what
>>>> made Pharo manageable compared to other image-based smalltalk dialects
>>>> (not to mention anything specific ;)) but there is a lot of
>>>> interesting code on squeaksource that naturally breaks - for those
>>>> interested in that code, it would be helpful to give a bit more advice
>>>> on "porting" and "the path of deprecation".
>>>>
>>>
>>> An advice is simple:
>>> 1. try loading the code using most recent image, try running it.
>>> 2. fix errors & bugs you found
>>> 3. Repeat from 1.
>>>
>>> This is what package maintainers should usually do all the time.
>>> And there is no magic: you have to get your hands dirty and make
>>> things work (again).
>>>
>>> Now, if nobody doing it for years, its not a Pharo failure that some
>>> code turned to be broken.
>>> I like that pharoers are not afraid to break things (of course if they
>>> breaking them for good ;).
>>>
>>> And besides.. you can always use years old image and happily load all
>>> code in it and it will work there.
>>>
>>> So, you are free to choose either:
>>>  - stay with old image version where all dusty code working
>>>  - running your code on most recent Pharo version and using its new features
>>> :)
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
In reply to this post by Igor Stasenko

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

> Hi All instances of HumanBeing
>
> Then, another question remains:
>
> Will my image of 2011 still work correctly
> on the VM of AD 2019 (the ones that than probably
> run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
> or the VM created for a newly emerged computer system?
>
If I can guarantee one thing, than it is this: the VM of 2019
(that I will use) will *not* be compatible to todays images.

Because, this would mean this:

        1) No 64bit. *Ever*. We would be 32 bit forever, even on your
             iPhone of 2019 with 128GB if RAM.
        2) No better GC. *EVER*.
        3) No support for good hashes.
        4) No nothing. (multiple tag bits, immutatble objects...)
        5) No support for more than one CPU, ever.
... this list is very long.

And it would mean that we could never clean up the VM and simplify
it. We would need to stay compatible to BitBlt from 1978 in 2018.
Does that make sense? Do *you* want to maintain a backward compatible
Balloon Pluging in 2015?

Pharo is not relevant today. (I actually think it's not.). Now
if we *require* to *never* change the VM, then this guarantees
complete uselessness very soon.

Do you really want to make any progress on the VM side impossible?

        Marcus


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


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

TedVanGaalen
Hi Marcus
Ok, that makes it certain that I really have
to move my packages to newer images
if I want to sustain through the years,
doesn't it?
Regards
Ted

On Mon, May 2, 2011 at 8:48 PM, Marcus Denker <[hidden email]> wrote:

>
> On May 2, 2011, at 6:49 PM, Ted F.A. van Gaalen wrote:
>
>> Hi All instances of HumanBeing
>>
>> Then, another question remains:
>>
>> Will my image of 2011 still work correctly
>> on the VM of AD 2019 (the ones that than probably
>> run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
>> or the VM created for a newly emerged computer system?
>>
> If I can guarantee one thing, than it is this: the VM of 2019
> (that I will use) will *not* be compatible to todays images.
>
> Because, this would mean this:
>
>        1) No 64bit. *Ever*. We would be 32 bit forever, even on your
>             iPhone of 2019 with 128GB if RAM.
>        2) No better GC. *EVER*.
>        3) No support for good hashes.
>        4) No nothing. (multiple tag bits, immutatble objects...)
>        5) No support for more than one CPU, ever.
> ... this list is very long.
>
> And it would mean that we could never clean up the VM and simplify
> it. We would need to stay compatible to BitBlt from 1978 in 2018.
> Does that make sense? Do *you* want to maintain a backward compatible
> Balloon Pluging in 2015?
>
> Pharo is not relevant today. (I actually think it's not.). Now
> if we *require* to *never* change the VM, then this guarantees
> complete uselessness very soon.
>
> Do you really want to make any progress on the VM side impossible?
>
>        Marcus
>
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
In reply to this post by Marcus Denker-4

On May 2, 2011, at 8:53 PM, Ted F.A. van Gaalen wrote:

> Hi Marcus
> Ok, that makes it certain that I really have
> to move my packages to newer images
> if I want to sustain through the years,
> doesn't it?

Or it would mean to change the meaning (or on some level: the implementation)
of the concept of the Image... you could have something that is more a declarative
specification of a frozen object graph. But without the low-level details, and then
reconstruct the object graph of the image at startup.

But, the VM that would allow that would *not* be able to run existing images
of today.

So I am actually not against what you want... I think that in 2019 we will actually
have a system that can do exactly what you want.

But the nirvana of a system that supports sofware evolution in a deep way can not
be achieved with being compatible with what we have now.

We need to change (and destructively improve) our system if we want to go there.

        Marcus

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


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

TedVanGaalen
On Mon, May 2, 2011 at 9:15 PM, Marcus Denker <[hidden email]> wrote:

>
> On May 2, 2011, at 8:53 PM, Ted F.A. van Gaalen wrote:
>
>> Hi Marcus
>> Ok, that makes it certain that I really have
>> to move my packages to newer images
>> if I want to sustain through the years,
>> doesn't it?
>
> Or it would mean to change the meaning (or on some level: the implementation)
> of the concept of the Image... you could have something that is more a declarative
> specification of a frozen object graph.
>But without the low-level details, and then
> reconstruct the object graph of the image at startup.
Arrghh! I have to look this up, this
goes beyond my current knowledge
(possibly also my intelligence..)

Could we learn from DNA structure?

>
> But, the VM that would allow that would *not* be able to run existing images
> of today.
>
> So I am actually not against what you want... I think that in 2019 we will actually
> have a system that can do exactly what you want.
You are an optimist, Markus :o)
besides I don't yet know what I want in =>2019 :o)
>
> But the nirvana
nirvana inspect.

> of a system that supports sofware evolution in a deep way can not
> be achieved with being compatible with what we have now.
>
> We need to change (and destructively improve) our system if we want to go there.
I will certainly not associate the above line of yours with the French
Revolution,
oh I just did :o)
Leave out the guillotine part, thanks.
It's a Model though: If France c'est ok today, then Pharo will be also. :o)
Regards
Ted

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
In reply to this post by Igor Stasenko

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.


Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Igor Stasenko
In reply to this post by TedVanGaalen
On 2 May 2011 18:49, Ted F.A. van Gaalen <[hidden email]> wrote:

> Hi All instances of HumanBeing
>
> Then, another question remains:
>
> Will my image of 2011 still work correctly
> on the VM of AD 2019 (the ones that than probably
> run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)?
> or the VM created for a newly emerged computer system?
>
> "All"  I wish for is:
>  -= Backward Source Compatibilty =-
> whenever possible because:
> -in five years the one could have written a huge amount of coding,
> for instance, a large ERP system, or an large internet trading
> system. Often these  consists of (10)thousands of lines
> of coding, even in Smalltalk. Many years of development and
> effort, blood sweat and tears have gone in to it.
> Finally everything is debugged and tested. And may happy
> users depend on it
>
> Assume that throughout this all coding are countless
> references to classes that are perfectly normal at the
> time of writing. This no exception.
>
> Then one or tow releases later:
>
> If these classes are removed, because The Respectful
> Tool Developers (e.g. (not only) Pharo) in their wisdom find it
> necessary to render these obsolete, then this has enormous
> consequences:
> One would have to edit and test, and in some cases rewrite (!)
> very large amounts of coding costing considerable amounts
> of time=money.
> Now, imagine yourself as an application programmer maintaining
> this huge amount of coding, which is not working anymore,
> not because you did it wrong, but because of chances in the
> Developmen Tool? How would feel? Like shit. Tons of work
> gone down the drain. Besides, are you going to ask your
> customer to pay for this?  You can't of course. He/she will
> say things like: "Why? It works perfectly!"etc.
>
> Naturally one wishes to migrate to new images releases and
> happily utilize the new features that come with it, no question
> about it. But as it seems now, this is out of the question,
> because with every release, things are taken out, changed
> without any respect to backward compatibility.
>
>
> 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.
>

A first phrase you can read when opening Pharo home page is:
Pharo is a clean, innovative, open-source Smalltalk-inspired environment.

And the things you proposing is going in conflict with the above.
You cannot make things clean and lean if we follow path you proposing.

Anyone is free write a separate package which could "maintain" a
compatibility layer(s) for whatever functionality
they missing, but just don't force these practices to others.

There is two different kinds of people:
one people putting garbage in trash bin, while others putting it into
garage room, because they thinking that
some of stuff still would be useful later.

A few years later a garage is full of various "useful" stuff which in
reality just rots there, because its owner already
forgot what he puts there , or even if he remembers, he can't find it
because it buried under the tons of other 'useful' stuff.


> Why not have the best of both worlds? What's the problem?

There is no any problem. You can download and run any Squeak and Pharo images
starting from 1.0.


> Things can live next to each other, if you do it well.
>

But i find a little sense of keeping stuff which were already obsolete
10 years ago, but still polluting a
modern image just because we can make things to live next to other.
You know, there is a plenty of space on hard disk. Squeak 1.0 image
can live next to Pharo 1.3. Not a big deal :)

> If you don't I can only resort to the most basic of
> system core classes. Ergo: limit myself to what I am
> (reasonable certain of)
>
>
> I see lines on this forum like:
> "Seems to be unused. I vote for removing.."
> Assuming is a bad thing in software development.
> How can you be certain that:
> No one really uses the component anymore?
> You can't.
>

You can. Because pharoers are the users of their own system. We're not
targeting system for
potential customer(s) who living in parallel universe. And so, if
there is no voice which says 'oh wait,
i using it' , then it is deem necessary to remove it to make system
cleaner and smaller and therefore easier
to learn, comprehend and use.


> The essence of it all is:
>
> I saw Pharo fit to write production software,
> especially with Seaside!
> but how can I use it for this, seen the above
> described arguments? If all the things
> I write become useless with a next release?
>

The reason why it could happen is:
- your code is not good enough
- someone wrote better code (and so your code become not good enough)
;)

for the rest of the cases, if you maintaining a 3rd party library or
application - it is up to you
whether you want to keep on par with pharo bleeding edge development,
or just take a concrete pharo release version and from then on, froze
it forever and stick with it.

>
>
> (Sorry, we don't sell tires for your
> car anymore, because we chanced
> the diameter of them, we recommend
> you to change/modify your car.. )
>
> A perfect example:
> (most) internet browsers
> are backward compatible.
>

A perfect example of what?
Don't mix an end-user application with development tool.
I could write an application which are backward compatible with its
most initial version, while under the hood
i could radically change everything.

Pharo is end-user application for developers, not for users :)


> I rest my case, enough said..
>
> Kind regards
> Ted
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

12