May 2011 - Pharo-users - lists.pharo.org

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

by TedvG TedvG

Yes, but a bit simplified: As a "typical application programmer" I consider myself as a "pharo-user" (that is why I am here.) Pharo/Smalltalk I really like as an application development tool. made by people like you (grateful, thanks), who dive deeper in Pharo "itself", so to speak So that is why I come with typical "user" questions and long term thoughts about usability and so on. Simply said: I wont' touch much of the "deeper world" in the image, but put my own application object layer on it. That is so nice about Smalltalk. (not making any money with it, I am outta work at the moment :o| - On Mon, May 2, 2011 at 11:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 May 2011 22:59, Ted F.A. van Gaalen <tedvga(a)gmail.com> wrote: >> Hi Igor >> ?? Shouldn't I be writing >> Pharo/Seaside apps with it? >> I am definitely a *user* Â Of Pharo/Seaside if I do.. > > hmm.. i don't know.. i were always thinking that those who writing > applications are developers, > and those who using applications, who don't understand what program > is, what is the code, and how it works are users.. > but maybe times had changed and now writing an application no longer > means that you are developer, > but just some kind of power-user? :) > >> Regards >> Ted >> >> On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: >>>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribiÃ³: >>>>> >>>>> Pharo is end-user application for developers, not for users :) >>> >>> +1, that's why I prefer Pharo over Squeak. >>> >>> -- >>> Ramon Leon >>> http://onsmalltalk.com >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 2, 2011

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

by James Ashley

On Mon, May 2, 2011 at 4:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 May 2011 22:59, Ted F.A. van Gaalen <tedvga(a)gmail.com> wrote: >> Hi Igor >> ?? Shouldn't I be writing >> Pharo/Seaside apps with it? >> I am definitely a *user* Â Of Pharo/Seaside if I do.. > > hmm.. i don't know.. i were always thinking that those who writing > applications are developers, > and those who using applications, who don't understand what program > is, what is the code, and how it works are users.. > but maybe times had changed and now writing an application no longer > means that you are developer, > but just some kind of power-user? :) That seems to fit pretty well with Alan's original ideas about where he wanted smalltalk and the dynabook to go. -- James >> Regards >> Ted

May 2, 2011

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

by Igor Stasenko

On 2 May 2011 22:59, Ted F.A. van Gaalen <tedvga(a)gmail.com> wrote: > Hi Igor > ?? Shouldn't I be writing > Pharo/Seaside apps with it? > I am definitely a *user* Â Of Pharo/Seaside if I do.. hmm.. i don't know.. i were always thinking that those who writing applications are developers, and those who using applications, who don't understand what program is, what is the code, and how it works are users.. but maybe times had changed and now writing an application no longer means that you are developer, but just some kind of power-user? :) > Regards > Ted > > On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: >>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribiÃ³: >>>> >>>> Pharo is end-user application for developers, not for users :) >> >> +1, that's why I prefer Pharo over Squeak. >> >> -- >> Ramon Leon >> http://onsmalltalk.com >> >> > > -- Best regards, Igor Stasenko AKA sig.

May 2, 2011

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

by Ted F.A. van Gaalen

Hi Igor ?? Shouldn't I be writing Pharo/Seaside apps with it? I am definitely a *user* Of Pharo/Seaside if I do.. Regards Ted On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: >> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribiÃ³: >>> >>> Pharo is end-user application for developers, not for users :) > > +1, that's why I prefer Pharo over Squeak. > > -- > Ramon Leon > http://onsmalltalk.com > >

May 2, 2011

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

by Ramon Leon

> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribiÃ³: >> Pharo is end-user application for developers, not for users :) +1, that's why I prefer Pharo over Squeak. -- Ramon Leon http://onsmalltalk.com

May 2, 2011

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

by Miguel CobÃ¡

El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribiÃ³: > Pharo is end-user application for developers, not for users :) He he, other quote for twitter! -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 2, 2011

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

by Igor Stasenko

On 2 May 2011 18:49, Ted F.A. van Gaalen <tedvga(a)gmail.com> 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.

May 2, 2011

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

by Ted F.A. van Gaalen

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 <marcus.denker(a)inria.fr> 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. > > >

May 2, 2011

Re: [Pharo-users] become:

by Mariano Martinez Peck

On Mon, May 2, 2011 at 8:20 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > On 05/02/2011 05:41 AM, Markus Fritsche wrote: > >> Hello, >> >> become replaces all pointers to the object to point to some other >> object. >> > > Actually, that's what #becomeForward: does, #become: swaps two objects > replacing all pointers to the object to point to some other object and vice > versa, which can cause serious issues if you aren't expecting it. > #becomeForward: is quite often the behavior you'd want when you think you > need #become:. > > You know, I always thoguht that #become: is a bad name. For me, #becomeForward: should be called #become and, #become should be called #replace: or #swaps: or something like that, but to make clear that it is both sides :) > -- > Ramon Leon > http://onsmalltalk.com > > > -- Mariano http://marianopeck.wordpress.com

May 2, 2011

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

by Marcus Denker

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.

May 2, 2011