About (backwards) Compatibility
Locked
123
123
About (backwards) Compatibility
 
|
Hi, i wanted to share an "old" quote which i find relevant to our community. Just replace FORTRAN's with loads of stuff we had in the bloated images in the past, most of them useful to get were we are right now.
Dijkstra, The Humble Programmer, 1972
|
|
|
I have to say I am on of those people who love backward compatibility. I actually come from a programming language that did exactly what the quote says. It was not a fun experience. Python 3 broke compatibility with python 2. Most of the libraries did ignore python 3 for quite some time and some still do. Actually if you google for "python 3" the second search result of it is the "python wall of shame" where you will find many of python libraries still stuck to python 2. The reason is that is a lot of work to rewrite parts of library to make it compatible with python 3. And note that python 3 has been around for 5 years. And is most likely it will be another 5 till most major python libraries are finally ported to python 3. http://python3wos.appspot.com/ Usually when I see "tragic fate" , "dead" , "declined" etc mentioned in the same sentence with a programming language I am certain that it will mention some "big flaw" of the language and I am going to facepalm myself. In 99% of all case of "dead" languages it has nothing to do with the language itself and has everything to do with hype and lack of good marketing.
I can tell you one thing, AFAIK the decision to brake compatibility with python is still a big reason why one should not use python and is considered one of the big flaw of python. I know that some people are in denial, and I agree that python has been improved but not without paying a big price as the "wall of shame" clearly shows. I can bring you another example, blenderpython, its the well known Blender python api of the well known open source 3d app. Well if you take a look at it you will find two things. a) blender 2.5 has been a rewrite which is a very good thing but that ment sacrificing many useful addons because not only the library changed but also they moved from python 2 to 3 and b) API keeps braking compatibility in almost every single version. The result is an army of addons that are left unmaintained because the author makes something but he is not able to maintain every second month because the developer decided to brake compatibility. Users ask for updates to the addons and usually developers search for another developer to maintain but most of those addons are left for dead. And that is thousands of lines of code gone to waste. Actually very few developers stick to blenderpython for this very reason. So no I have to disagree there, between choosing a better language or a useful library and code that works in long term, I choose the second. I am full on progress but I do find braking compatibility is just the easy , convinient solution that does not quite work well in practice . From: Fernando Olivero <[hidden email]> To: "[hidden email]" <[hidden email]> Sent: Tuesday, 11 December 2012, 10:36 Subject: [Pharo-project] About (backwards) Compatibility Hi, i wanted to share an "old" quote which i find relevant to our community. Just replace FORTRAN's with loads of stuff we had in the bloated images in the past, most of them useful to get were we are right now.
Dijkstra, The Humble Programmer, 1972
|
|
|
yeah, but that's a direct path to stagnation, and that's what happened with fortran, java and all the languages that have put backward compatibility as top priority.
in other side, .net is not backward compatible and it has success anyway so, is not so clear for me. I still prefer to drop backward compatibility time to time to drop a full language each 10 years :) Esteban
On Dec 11, 2012, at 10:23 AM, dimitris chloupis <[hidden email]> wrote:
|
Re: About (backwards) Compatibility
|
|
The inventor of Ruby on Rails gave a talk about this topic: On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <[hidden email]> wrote:
|
Re: About (backwards) Compatibility
|
|
what is interesting that people don't realize that they can have 2
versions of same software installed, and use one or another, depending on need. -- Best regards, Igor Stasenko. |
Re: About (backwards) Compatibility
|
|
In reply to this post by Marcus Denker-4
Marcus, thank you for the link.
May I ask somebody who has watched the video to post a few words of a summary here....(keywords are fine) --Hannes On 12/11/12, Marcus Denker <[hidden email]> wrote: > > The inventor of Ruby on Rails gave a talk about this topic: > > https://www.youtube.com/watch?v=VOFTop3AMZ8 > > > On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <[hidden email]> > wrote: > >> yeah, but that's a direct path to stagnation, and that's what happened >> with fortran, java and all the languages that have put backward >> compatibility as top priority. >> in other side, .net is not backward compatible and it has success anyway >> so, is not so clear for me. >> >> I still prefer to drop backward compatibility time to time to drop a full >> language each 10 years :) >> >> Esteban >> >> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <[hidden email]> >> wrote: >> >>> I have to say I am on of those people who love backward compatibility. I >>> actually come from a programming language that did exactly what the quote >>> says. It was not a fun experience. Python 3 broke compatibility with >>> python 2. Most of the libraries did ignore python 3 for quite some time >>> and some still do. Actually if you google for "python 3" the second >>> search result of it is the "python wall of shame" where you will find >>> many of python libraries still stuck to python 2. The reason is that is a >>> lot of work to rewrite parts of library to make it compatible with python >>> 3. And note that python 3 has been around for 5 years. And is most likely >>> it will be another 5 till most major python libraries are finally ported >>> to python 3. >>> >>> http://python3wos.appspot.com/ >>> >>> Usually when I see "tragic fate" , "dead" , "declined" etc mentioned in >>> the same sentence with a programming language I am certain that it will >>> mention some "big flaw" of the language and I am going to facepalm >>> myself. In 99% of all case of "dead" languages it has nothing to do with >>> the language itself and has everything to do with hype and lack of good >>> marketing. >>> >>> I can tell you one thing, AFAIK the decision to brake compatibility with >>> python is still a big reason why one should not use python and is >>> considered one of the big flaw of python. I know that some people are in >>> denial, and I agree that python has been improved but not without paying >>> a big price as the "wall of shame" clearly shows. >>> >>> I can bring you another example, blenderpython, its the well known >>> Blender python api of the well known open source 3d app. Well if you take >>> a look at it you will find two things. a) blender 2.5 has been a rewrite >>> which is a very good thing but that ment sacrificing many useful addons >>> because not only the library changed but also they moved from python 2 to >>> 3 and b) API keeps braking compatibility in almost every single version. >>> The result is an army of addons that are left unmaintained because the >>> author makes something but he is not able to maintain every second month >>> because the developer decided to brake compatibility. Users ask for >>> updates to the addons and usually developers search for another developer >>> to maintain but most of those addons are left for dead. And that is >>> thousands of lines of code gone to waste. Actually very few developers >>> stick to blenderpython for this very reason. >>> >>> So no I have to disagree there, between choosing a better language or a >>> useful library and code that works in long term, I choose the second. I >>> am full on progress but I do find braking compatibility is just the easy >>> , convinient solution that does not quite work well in practice . >>> >>> From: Fernando Olivero <[hidden email]> >>> To: "[hidden email]" >>> <[hidden email]> >>> Sent: Tuesday, 11 December 2012, 10:36 >>> Subject: [Pharo-project] About (backwards) Compatibility >>> >>> Hi, i wanted to share an "old" quote which i find relevant to our >>> community. Just replace FORTRAN's with loads of stuff we had in the >>> bloated images in the past, most of them useful to get were we are right >>> now. >>> >>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining >>> thousands and thousands of programmers to our past mistakes. I pray daily >>> that more of my fellow-programmers may find the means of freeing >>> themselves from the curse of compatibility." >>> >>> Dijkstra, The Humble Programmer, 1972 >>> >>> >>> >>> >> > > |
|
|
Well in summary he says "get out of your comfort zone and deal with it" , bare in mind that the video *is not* about backward compatibility but about implementing new features in general. He also speak in purely a library and not a language perspective. He makes some valid points. I am not totally against braking backward compatibility , but overall I have to agree with the first youtube comment that overall the presentation is boring and could be easily summarized in a 3 minute
talk. And of course I do disagree strongly with his point that "learning the hard way of doing things will make you a better coder" because the success of python and ruby clearly show quite the opposite. I do agree however that "we do not need to babysit new coders" and that "beginner coders should be diving neck deep to coding as fast as possible because they are far more capable than they think they are" . So he definitely makes some valid points . From: H. Hirzel <[hidden email]> To: [hidden email] Sent: Tuesday, 11 December 2012, 17:05 Subject: Re: [Pharo-project] About (backwards) Compatibility Marcus, thank you for the link. May I ask somebody who has watched the video to post a few words of a summary here....(keywords are fine) --Hannes On 12/11/12, Marcus Denker <[hidden email]> wrote: > > The inventor of Ruby on Rails gave a talk about this topic: > > https://www.youtube.com/watch?v=VOFTop3AMZ8 > > > On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <[hidden email]> > wrote: > >> yeah, but that's a direct path to stagnation, and that's what happened >> with fortran, java and all the languages that have put backward >> compatibility as top priority. >> in other side, .net is not backward compatible and it has success anyway >> so, is not so clear for me. >> >> I still prefer to drop backward compatibility time to time to drop a full >> language each 10 years :) >> >> Esteban >> >> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <[hidden email]> >> wrote: >> >>> I have to say I am on of those people who love backward compatibility. I >>> actually come from a programming language that did exactly what the quote >>> says. It was not a fun experience. Python 3 broke compatibility with >>> python 2. Most of the libraries did ignore python 3 for quite some time >>> and some still do. Actually if you google for "python 3" the second >>> search result of it is the "python wall of shame" where you will find >>> many of python libraries still stuck to python 2. The reason is that is a >>> lot of work to rewrite parts of library to make it compatible with python >>> 3. And note that python 3 has been around for 5 years. And is most likely >>> it will be another 5 till most major python libraries are finally ported >>> to python 3. >>> >>> http://python3wos.appspot.com/ >>> >>> Usually when I see "tragic fate" , "dead" , "declined" etc mentioned in >>> the same sentence with a programming language I am certain that it will >>> mention some "big flaw" of the language and I am going to facepalm >>> myself. In 99% of all case of "dead" languages it has nothing to do with >>> the language itself and has everything to do with hype and lack of good >>> marketing. >>> >>> I can tell you one thing, AFAIK the decision to brake compatibility with >>> python is still a big reason why one should not use python and is >>> considered one of the big flaw of python. I know that some people are in >>> denial, and I agree that python has been improved but not without paying >>> a big price as the "wall of shame" clearly shows. >>> >>> I can bring you another example, blenderpython, its the well known >>> Blender python api of the well known open source 3d app. Well if you take >>> a look at it you will find two things. a) blender 2.5 has been a rewrite >>> which is a very good thing but that ment sacrificing many useful addons >>> because not only the library changed but also they moved from python 2 to >>> 3 and b) API keeps braking compatibility in almost every single version. >>> The result is an army of addons that are left unmaintained because the >>> author makes something but he is not able to maintain every second month >>> because the developer decided to brake compatibility. Users ask for >>> updates to the addons and usually developers search for another developer >>> to maintain but most of those addons are left for dead. And that is >>> thousands of lines of code gone to waste. Actually very few developers >>> stick to blenderpython for this very reason. >>> >>> So no I have to disagree there, between choosing a better language or a >>> useful library and code that works in long term, I choose the second. I >>> am full on progress but I do find braking compatibility is just the easy >>> , convinient solution that does not quite work well in practice . >>> >>> From: Fernando Olivero <[hidden email]> >>> To: "[hidden email]" >>> <[hidden email]> >>> Sent: Tuesday, 11 December 2012, 10:36 >>> Subject: [Pharo-project] About (backwards) Compatibility >>> >>> Hi, i wanted to share an "old" quote which i find relevant to our >>> community. Just replace FORTRAN's with loads of stuff we had in the >>> bloated images in the past, most of them useful to get were we are right >>> now. >>> >>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining >>> thousands and thousands of programmers to our past mistakes. I pray daily >>> that more of my fellow-programmers may find the means of freeing >>> themselves from the curse of compatibility." >>> >>> Dijkstra, The Humble Programmer, 1972 >>> >>> >>> >>> >> > > |
|
|
In reply to this post by Igor Stasenko
Oh I can assure you they do, but even more they realize the "joy" of your libraries split over two different incompatible versions. Like I am torn between squeak and pharo for many of the great libraries both packages do have. I can say its "so fun" not be able to use them all at the same time :D not to even start talking about the rest of fragmentation of the smalltalk land between different implementations.
But then I never expected smalltalk to be a smooth ride so its ok. From: Igor Stasenko <[hidden email]> To: [hidden email] Sent: Tuesday, 11 December 2012, 16:21 Subject: Re: [Pharo-project] About (backwards) Compatibility what is interesting that people don't realize that they can have 2 versions of same software installed, and use one or another, depending on need. -- Best regards, Igor Stasenko. |
|
|
In reply to this post by kilon
problem is that in Pharo, the difference between "the language" and "the library" is subtle :)
On Dec 11, 2012, at 4:34 PM, dimitris chloupis <[hidden email]> wrote:
|
|
|
Good point. From: Esteban Lorenzano <[hidden email]> To: [hidden email]; dimitris chloupis <[hidden email]> Sent: Tuesday, 11 December 2012, 17:57 Subject: Re: [Pharo-project] About (backwards) Compatibility problem is that in Pharo, the difference between "the language" and "the library" is
subtle :) On Dec 11, 2012, at 4:34 PM, dimitris chloupis <[hidden email]> wrote:
|
Re: About (backwards) Compatibility
|
|
Dimitris, thank you for the summary of the RoR video. Base line is to
deal with it. Interesting to note that with computer languages the same thing happens as with natural languages. Language use changes. Most people would have a hard time understanding Middle English these days. http://en.wikipedia.org/wiki/Middle_English, see sample texts. However the rate at where understanding starts dropping is "digital" with computer languages. A single changed method call breaks compatibility... The process is not robust. Of course that is pretty easy to fix. A call for the construction of various compatibility patches/layers/facades. For example in August this year I loaded PetitParser into Squeak. I had to add a 'Pharo compatibility' package which just contained 1 (one) method! (for the minimal version, not the GUI version and the Smalltalk parser) After some discussion that method was added to Squeak trunk and PetitParser did not need that anymore. http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165790.html Constant input in maintenance effort is needed. So any efforts in maintaining libraries and maybe compatibility layers are very welcome. --Hannes On 12/11/12, dimitris chloupis <[hidden email]> wrote: > Good point. > > > > ________________________________ > From: Esteban Lorenzano <[hidden email]> > To: [hidden email]; dimitris chloupis > <[hidden email]> > Sent: Tuesday, 11 December 2012, 17:57 > Subject: Re: [Pharo-project] About (backwards) Compatibility > > > problem is that in Pharo, the difference between "the language" and "the > library" is subtle :) > > > On Dec 11, 2012, at 4:34 PM, dimitris chloupis <[hidden email]> wrote: > > Well in summary he says "get out of your comfort zone and deal with it" , > bare in mind that the video *is not* about backward compatibility but about > implementing new features in general. He also speak in purely a library and > not a language perspective. >> >> >>He makes some valid points. I am not totally against braking backward >> compatibility , but overall I have to agree with the first youtube comment >> that overall the presentation is boring and could be easily summarized in >> a 3 minute talk. >> >> >>And of course I do disagree strongly with his point that "learning the hard >> way of doing things will make you a better coder" because the success of >> python and ruby clearly show quite the opposite. I do agree however that >> "we do not need to babysit new coders" and that "beginner coders should be >> diving neck deep to coding as fast as possible because they are far more >> capable than they think they are" . So he definitely makes some valid >> points . >> >> >> >> >>________________________________ >> From: H. Hirzel <[hidden email]> >>To: [hidden email] >>Sent: Tuesday, 11 December 2012, 17:05 >>Subject: Re: [Pharo-project] About (backwards) Compatibility >> >>Marcus, thank you for the link. >>May I ask somebody who has watched the video to post a few words of a >>summary here....(keywords are fine) >> >>--Hannes >> >>On 12/11/12, Marcus Denker <[hidden email]> wrote: >>> >>> The inventor of Ruby on Rails gave a talk about this topic: >>> >>> https://www.youtube.com/watch?v=VOFTop3AMZ8 >>> >>> >>> On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <[hidden email]> >>> wrote: >>> >>>> yeah, but that's a direct path to stagnation, and that's what happened >>>> with fortran, java and all the languages that have put backward >>>> compatibility as top priority. >>>> in other side, .net is not backward compatible and it has success anyway >>>> so, is not so clear for me. >>>> >>>> I still prefer to drop backward compatibility time to time to drop a >>>> full >>>> language each 10 years :) >>>> >>>> Esteban >>>> >>>> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <[hidden email]> >>>> wrote: >>>> >>>>> I have to say I am on of those people who love backward compatibility. >>>>> I >>>>> actually come from a programming language that did exactly what the >>>>> quote >>>>> says. It was not a fun experience. Python 3 broke compatibility with >>>>> python 2. Most of the libraries did ignore python 3 for quite some time >>>>> and some still do. Actually if you google for "python 3" the second >>>>> search result of it is the "python wall of shame" where you will find >>>>> many of python libraries still stuck to python 2. The reason is that is >>>>> a >>>>> lot of work to rewrite parts of library to make it compatible with >>>>> python >>>>> 3. And note that python 3 has been around for 5 years. And is most >>>>> likely >>>>> it will be another 5 till most major python libraries are > finally ported >>>>> to python 3. >>>>> >>>>> http://python3wos.appspot.com/ >>>>> >>>>> Usually when I see "tragic fate" , "dead" , "declined" etc mentioned >>>>> in >>>>> the same sentence with a programming language I am certain that it will >>>>> mention some "big flaw" of the language and I am going to facepalm >>>>> myself. In 99% of all case of "dead" languages it has nothing to do >>>>> with >>>>> the language itself and has everything to do with hype and lack of good >>>>> marketing. >>>>> >>>>> I can tell you one thing, AFAIK the decision to brake compatibility >>>>> with >>>>> python is still a big reason why one should not use python and is >>>>> considered one of the big flaw of python. I know that some people are >>>>> in >>>>> denial, and I agree > that python has been improved but not without paying >>>>> a big price as the "wall of shame" clearly shows. >>>>> >>>>> I can bring you another example, blenderpython, its the well known >>>>> Blender python api of the well known open source 3d app. Well if you >>>>> take >>>>> a look at it you will find two things. a) blender 2.5 has been a >>>>> rewrite >>>>> which is a very good thing but that ment sacrificing many useful addons >>>>> because not only the library changed but also they moved from python 2 >>>>> to >>>>> 3 and b) API keeps braking compatibility in almost every single >>>>> version. >>>>> The result is an army of addons that are left unmaintained because the >>>>> author makes something but he is not able to maintain every second >>>>> month >>>>> because the developer decided to brake compatibility. Users ask for >>>>> updates to the addons and > usually developers search for another developer >>>>> to maintain but most of those addons are left for dead. And that is >>>>> thousands of lines of code gone to waste. Actually very few developers >>>>> stick to blenderpython for this very reason. >>>>> >>>>> So no I have to disagree there, between choosing a better language or a >>>>> useful library and code that works in long term, I choose the second. I >>>>> am full on progress but I do find braking compatibility is just the >>>>> easy >>>>> , convinient solution that does not quite work well in practice . >>>>> >>>>> From: Fernando Olivero <[hidden email]> >>>>> To: "[hidden email]" >>>>> <[hidden email]> >>>>> Sent: Tuesday, 11 December 2012, 10:36 >>>>> Subject: [Pharo-project] About (backwards) Compatibility >>>>> >>>>> Hi, i wanted to share an "old" quote which i find relevant to our >>>>> community. Just replace FORTRAN's with loads of stuff we had in the >>>>> bloated images in the past, most of them useful to get were we are >>>>> right >>>>> now. >>>>> >>>>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining >>>>> thousands and thousands of programmers to our past mistakes. I pray >>>>> daily >>>>> that more of my fellow-programmers may find the means of > freeing >>>>> themselves from the curse of compatibility." >>>>> >>>>> Dijkstra, The Humble Programmer, 1972 >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> >> |
Re: About (backwards) Compatibility
|
|
On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <[hidden email]> wrote: > > > Constant input in maintenance effort is needed. So any efforts in > maintaining libraries and maybe compatibility layers are very welcome. > Yes, and how did we ever thought we could invent the future with Squeak when in reality, we could not even change a typo in a comment? Marcus |
Re: About (backwards) Compatibility
|
|
Marcus, maybe you could you elaborate your comment. I do not
understand it. Changing a typo in a comment is not changing the 'computer language'. I assume you speak about the development process. However both Pharo and Squeak now have a good process. --Hannes On 12/11/12, Marcus Denker <[hidden email]> wrote: > > On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <[hidden email]> wrote: >> >> >> Constant input in maintenance effort is needed. So any efforts in >> maintaining libraries and maybe compatibility layers are very welcome. >> > Yes, and how did we ever thought we could invent the future with Squeak > when in reality, we could not even change a typo in a comment? > > Marcus > > > > > |
Re: About (backwards) Compatibility
|
|
In reply to this post by Marcus Denker-4
On 11 December 2012 18:15, Marcus Denker <[hidden email]> wrote:
> > On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <[hidden email]> wrote: >> >> >> Constant input in maintenance effort is needed. So any efforts in >> maintaining libraries and maybe compatibility layers are very welcome. >> > Yes, and how did we ever thought we could invent the future with Squeak > when in reality, we could not even change a typo in a comment? > but i think you're stretching a bit :) > Marcus > > > > -- Best regards, Igor Stasenko. |
Re: About (backwards) Compatibility
|
|
In reply to this post by Marcus Denker-4
If my goal is to make my computer work for ME, then I want my
development system to maximize my leverage and minimize my effort. Breaking compatibility for cleaner code subverts this, as Hannes said, >> Constant input in maintenance effort is needed. I want to use my time applying Smalltalk to real-world problems, not API changes. A blue-plane innovation is worth breaking backward compatibility, reinventing the past isn't. >> maintaining libraries and maybe compatibility layers are very welcome. >> > Yes, and how did we ever thought we could invent the future with Squeak > when in reality, we could not even change a typo in a comment? > > Marcus > > > > |
Re: About (backwards) Compatibility
|
|
2012/12/11 Chris Muller <[hidden email]>:
> If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > One thing is clear, forking is not anything near minimizing the effort, quite the opposite. It's the way to build one's own jail - some will say to be free ;). Clearly, Marcus and Stephane have other goals and it's a good thing to have both Squeak and Pharo. >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > Ah, if future is the past, then I wonder whether it's not yet another damned Smalltalk circularity trick ;) > >>> maintaining libraries and maybe compatibility layers are very welcome. >>> >> Yes, and how did we ever thought we could invent the future with Squeak >> when in reality, we could not even change a typo in a comment? >> >> Marcus >> >> >> >> > |
|
|
There is definitely the other side of things, that side that says you cant have an omelet if you don't brake some eggs. I always admire people that go against the flow , people who are willing to sacrifice convenience for progress. I do believe in the direction pharo is going , I do believe that keeping code clean and reliable should be main priority. And even though people love to call attempts dead and futile , ideas are near impossible to kill because they always find brains to flourish on. And
even a bad idea in time can turn into something great. Because as one Greek philosopher once said "everything is changing" , everything has a life of its own, and as far as software is concern as long as there are coders for it , it aint dead yet. And there definitely benefits to be gained from braking compatibility. But progress is definitely a tricky things full of pitfalls and new is not always better. Its ironic how software seems to going back through time nowdays and rediscovering old relics like smalltalk and lisp. And "old" becomes the new "new". Definitely keeping an open mind is the wise thing to do any direction one
may chooses to go. And I am certainly going to follow pharo and squeak progress closely because both have still a lot to say. From: Nicolas Cellier <[hidden email]> To: [hidden email]; [hidden email] Sent: Tuesday, 11 December 2012, 22:50 Subject: Re: [Pharo-project] About (backwards) Compatibility 2012/12/11 Chris Muller <[hidden email]>: > If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > One thing is clear, forking is not anything near minimizing the effort, quite the opposite. It's the way to build one's own jail - some will say to be free ;). Clearly, Marcus and Stephane have other goals and it's a good thing to have both Squeak and Pharo. >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > Ah, if future is the past, then I wonder whether it's not yet another damned Smalltalk circularity trick ;) > >>> maintaining libraries and maybe compatibility layers are very welcome. >>> >> Yes, and how did we ever thought we could invent the future with Squeak >> when in reality, we could not even change a typo in a comment? >> >> Marcus >> >> >> >> > |
Re: About (backwards) Compatibility
|
|
In reply to this post by Chris Muller-3
Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :).
We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel and a lot more….:) May be you did not read my FAST Pharo presentation or the ESUG one but we want to get more business around Pharo and we are doing it. In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. You know Moose is probably one of the most complex Pharo application around. Now we do not want to live in a place where each time we open a browser on something we cry. Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better code in Java or Javascript. This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifier…. Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. We have pier running in 2.0. Now just out of curiosity do you use Pharo ;D Stef > If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > > >>> maintaining libraries and maybe compatibility layers are very welcome. >>> >> Yes, and how did we ever thought we could invent the future with Squeak >> when in reality, we could not even change a typo in a comment? >> >> Marcus >> >> >> >> > |
Re: About (backwards) Compatibility
|
|
Hi Stef, I think Pharo is really neat. I have nothing against it
except for the "we are cool, you are not" attitude which I perceive at times. I have no interest in chopping on the great work being done by you and my other friends in Pharo, but that doesn't mean it is feasible for me to use it in my business. While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change, and close to being a matter of preference. > Now just out of curiosity do you use Pharo ;D I do not use Pharo anymore. I tried for a while but the IDE was difficult for me to work in and there was no reward for constant patching of my packages just to stay working. I saw how decisions which can have significant repercussions on low-level parts of the code-base are made with such little debate. I have business to run myself, this approach is untenable for me. Squeak's philosophy fits me just right. I will be watching Pharo with great interest. If it settles down someday, and I need to start up a brand new Smalltalk project which has no need for Magma or Maui, I will give Pharo another look. This thread is about the old debate about backward-compatibility, my position should not be surprising. On Wed, Dec 12, 2012 at 12:22 PM, Stéphane Ducasse <[hidden email]> wrote: > Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :). > We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel > and a lot more….:) > > May be you did not read my FAST Pharo presentation or the ESUG one but we want to get > more business around Pharo and we are doing it. > > In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. > You know Moose is probably one of the most complex Pharo application around. > Now we do not want to live in a place where each time we open a browser on something we cry. > Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better > code in Java or Javascript. > > This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifier…. > > Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. > We have pier running in 2.0. > > Now just out of curiosity do you use Pharo ;D > > Stef > > > >> If my goal is to make my computer work for ME, then I want my >> development system to maximize my leverage and minimize my effort. >> Breaking compatibility for cleaner code subverts this, as Hannes said, >> >>>> Constant input in maintenance effort is needed. >> >> I want to use my time applying Smalltalk to real-world problems, not >> API changes. >> >> A blue-plane innovation is worth breaking backward compatibility, >> reinventing the past isn't. >> >> >>>> maintaining libraries and maybe compatibility layers are very welcome. >>>> >>> Yes, and how did we ever thought we could invent the future with Squeak >>> when in reality, we could not even change a typo in a comment? >>> >>> Marcus >>> >>> >>> >>> >> > |
Re: About (backwards) Compatibility
|
|
On 12 December 2012 22:45, Chris Muller <[hidden email]> wrote:
> Hi Stef, I think Pharo is really neat. I have nothing against it > except for the "we are cool, you are not" attitude which I perceive at > times. hehe.. it is natural for people to contrast on something what everyone else knows. and taking in mind the bias .. > I have no interest in chopping on the great work being done by > you and my other friends in Pharo, but that doesn't mean it is > feasible for me to use it in my business. While someone in the Pharo > community said FileSystem over FileDirectory is "huge", I see it as an > incremental API change, and close to being a matter of preference. > incremental? do you think you can implement a memory-based and/or git-based filesystem or 'remotely connected database-based file system' by just doing incremental changes to FileDirectory? good luck with such 'increments' :) >> Now just out of curiosity do you use Pharo ;D > > I do not use Pharo anymore. I tried for a while but the IDE was > difficult for me to work in and there was no reward for constant > patching of my packages just to stay working. I saw how decisions > which can have significant repercussions on low-level parts of the > code-base are made with such little debate. I have business to run > myself, this approach is untenable for me. Squeak's philosophy fits > me just right. > their impact before introducing them, or at least advocate the changes properly with all details and 'why-s'. (personally, i doing that way it all the time) > I will be watching Pharo with great interest. If it settles down > someday, and I need to start up a brand new Smalltalk project which > has no need for Magma or Maui, I will give Pharo another look. > > This thread is about the old debate about backward-compatibility, my > position should not be surprising. > > On Wed, Dec 12, 2012 at 12:22 PM, Stéphane Ducasse > <[hidden email]> wrote: >> Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :). >> We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel >> and a lot more….:) >> >> May be you did not read my FAST Pharo presentation or the ESUG one but we want to get >> more business around Pharo and we are doing it. >> >> In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. >> You know Moose is probably one of the most complex Pharo application around. >> Now we do not want to live in a place where each time we open a browser on something we cry. >> Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better >> code in Java or Javascript. >> >> This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifier…. >> >> Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. >> We have pier running in 2.0. >> >> Now just out of curiosity do you use Pharo ;D >> >> Stef >> >> >> >>> If my goal is to make my computer work for ME, then I want my >>> development system to maximize my leverage and minimize my effort. >>> Breaking compatibility for cleaner code subverts this, as Hannes said, >>> >>>>> Constant input in maintenance effort is needed. >>> >>> I want to use my time applying Smalltalk to real-world problems, not >>> API changes. >>> >>> A blue-plane innovation is worth breaking backward compatibility, >>> reinventing the past isn't. >>> >>> >>>>> maintaining libraries and maybe compatibility layers are very welcome. >>>>> >>>> Yes, and how did we ever thought we could invent the future with Squeak >>>> when in reality, we could not even change a typo in a comment? >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>> >> > -- Best regards, Igor Stasenko. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |