[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
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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
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.
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 <siguctua@gmail.com> To: Pharo-project@lists.gforge.inria.fr 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.
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 <marcus.denker@inria.fr> 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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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 <hannes.hirzel@gmail.com> To: Pharo-project@lists.gforge.inria.fr 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 <marcus.denker@inria.fr> 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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
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 <thekilon@yahoo.co.uk> 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 <hannes.hirzel@gmail.com> To: Pharo-project@lists.gforge.inria.fr 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 <marcus.denker@inria.fr> 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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
Good point. ________________________________ From: Esteban Lorenzano <estebanlm@gmail.com> To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis <thekilon@yahoo.co.uk> 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 <thekilon@yahoo.co.uk> 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 <hannes.hirzel@gmail.com> To: Pharo-project@lists.gforge.inria.fr 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 <marcus.denker@inria.fr> 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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
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... 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 <thekilon@yahoo.co.uk> wrote:
Good point.
________________________________ From: Esteban Lorenzano <estebanlm@gmail.com> To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis <thekilon@yahoo.co.uk> 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 <thekilon@yahoo.co.uk> 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 <hannes.hirzel@gmail.com> To: Pharo-project@lists.gforge.inria.fr 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 <marcus.denker@inria.fr> 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 <estebanlm@gmail.com> 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 <thekilon@yahoo.co.uk> 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 <fernando.olivero@usi.ch> To: "Pharo-project@lists.gforge.inria.fr" <pharo-project@lists.gforge.inria.fr> 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
On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel@gmail.com> 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
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 <marcus.denker@inria.fr> wrote:
On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel@gmail.com> 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
On 11 December 2012 18:15, Marcus Denker <marcus.denker@inria.fr> wrote:
On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel@gmail.com> 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?
Simple: you just add a wrapper class/method and put fixed comment there :) but i think you're stretching a bit :)
Marcus
-- Best regards, Igor Stasenko.
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
2012/12/11 Chris Muller <asqueaker@gmail.com>:
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 <nicolas.cellier.aka.nice@gmail.com> To: Pharo-project@lists.gforge.inria.fr; ma.chris.m@gmail.com Sent: Tuesday, 11 December 2012, 22:50 Subject: Re: [Pharo-project] About (backwards) Compatibility 2012/12/11 Chris Muller <asqueaker@gmail.com>:
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
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
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 <Stephane.Ducasse@inria.fr> 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
On 12 December 2012 22:45, Chris Muller <ma.chris.m@gmail.com> 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.
Yes, i agree that people should discuss low-level 'repercussions' and 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 <Stephane.Ducasse@inria.fr> 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.
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art. Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools. I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast Cheers, Sean -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
And we pay attention about change we will not change filesystem every release or announcement. Stef
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk. Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is: "FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime. "FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime. Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!) On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Chris Muller-3 wrote
I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda
Or both! ;) Chris Muller-3 wrote
This example is bunk
Well, you're partly right - the clean version is not due totally to FS. You'd be more right if human beings were rational beings. But we're not, we're driven by emotion. I /feel/ bad when I look at FD, because I find it ugly and confusing. Therefore, I would be reluctant to refactor that code and it probably would still be in the state it is. But I was excited to have well-factored, intuitive FS objects to work with, which boiled into me searching the system for ugly code to clean. That example was a quote from a previous post in my excitement after cleaning and making the system better. Beauty and simplicity reverberates out well beyond the initial objects... that's good enough for me. Sean -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659295.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 12/14/12, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-3 wrote
I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda
Or both! ;)
Chris Muller-3 wrote
This example is bunk
Well, you're partly right - the clean version is not due totally to FS.
The difference is file := FileDirectory directoryEntryFor: aString. "FileDirectory" as opposed to file := aString asFileName. "FileSystem" As Chris points out, the difference is minimal. Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design
You'd be more right if human beings were rational beings. But we're not, we're driven by emotion. I /feel/ bad when I look at FD, because I find it ugly and confusing.
Yes, FileDirectory has it's limitations. Many years ago I wrote a layer to deal with directory navigation for my own projects. As Marcus D. points out it is good that people have an OO abstraction to deal with directories and files. It saves time for beginners and new projects. In Squeak the discussion goes the way that FileDirectory should become a loadable package after FileSystem has been integrated in version 4.5. That way images with packages which require FileDirectory may still be built. --Hannes
Therefore, I would be reluctant to refactor that code and it probably would still be in the state it is. But I was excited to have well-factored, intuitive FS objects to work with, which boiled into me searching the system for ugly code to clean. That example was a quote from a previous post in my excitement after cleaning and making the system better. Beauty and simplicity reverberates out well beyond the initial objects... that's good enough for me.
Sean
H. Hirzel wrote
As Chris points out, the difference is minimal.
Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design
While you ignored the point of my followup post, which is that beauty and simplicity lead to more than the sum of a few keywords, here are a few basic examples... Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name. vs. file2 := '/path/to/file' asFileReference. file2 extension. #2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename' "Most operations routed through one massive FD class" vs. "immediate access to the domain object you want"; not to mention the appreciated absence of parens. No difference?? -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659396.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
FileDirectory was updated in 2009, but since Pharo had already forked off Squeak prior to that you didn't know that FileDirectory was already a lot like FileSystem is today before anyone knew FileSystem even existed. Today these examples are almost identical.
Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name.
vs.
file2 := '/path/to/file' asFileReference. file2 extension.
file := FileDirectory directoryEntryFor: '/path/to/file'. file extension
#2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename'
(FileDirectory entryFor: 'path') / 'filename'. I agree we should add String>>#asDirectoryEntry to avoid the keyword message and parenthesis, so both examples would be just as nice as FileSystem: 'path' asDirectoryEntry / 'filename'. I think we agree about what good design is, we just differ about which path to take there, the more-compatible or the more-beautiful path.
Chris Muller-3 wrote
I think we agree about what good design is, we just differ about which path to take there, the more-compatible or the more-beautiful path.
That sums it up I think :) -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean Just asking that question means that hannes does not need it :) One day I spent 20 min to rename all the file in one directory and got madâ¦. (so I'm probably too dull to understand files) Users of files see the real difference. Stef On Dec 16, 2012, at 12:42 AM, Sean P. DeNigris wrote:
H. Hirzel wrote
As Chris points out, the difference is minimal.
Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design
While you ignored the point of my followup post, which is that beauty and simplicity lead to more than the sum of a few keywords, here are a few basic examples...
Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name.
vs.
file2 := '/path/to/file' asFileReference. file2 extension.
#2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename'
"Most operations routed through one massive FD class" vs. "immediate access to the domain object you want"; not to mention the appreciated absence of parens.
No difference??
-- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659396.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
H. Hirzel wrote
As Chris points out, the difference is minimal.
Sean, it looks like you need better examples to show how you perceive the benefits of the FileSystem design
While you ignored the point of my followup post, which is that beauty and simplicity lead to more than the sum of a few keywords, here are a few basic examples...
Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name.
vs.
file2 := '/path/to/file' asFileReference. file2 extension.
#2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename'
"Most operations routed through one massive FD class" vs. "immediate access to the domain object you want"; not to mention the appreciated absence of parens.
No difference??
But with
String methods for *FileSystem-utilities / aPath ^self asFileReference / aPath you get 'path' / 'filename' and that's *really* nice. Does anyone think that '123' / '45' is good?? This is a compromise: / arg self size = 0 ifTrue: [self error: 'cannot coerce the empty string]. ^('+-01234456789' incudes: self first) ifTrue: [arg adaptToString: self andSend: #/] ifFalse: [self asFileReference / arg] the issue here being whether FileSystem wants '.profile' or '.hg' et al or math wants '.123'. If FileSystem provides path-name checking then the above could include a specific legality check instead of the naive discrimination. Personally I find the prospect of a concise file scripting api much more appealing than lazy numeric conversion. The absence of the former is why so much of my life involves bash scripts. The latter isn't necessary if one starts off with numbers in the first place, and being literals they're as easy, no, easier than denoting numbers using strings (1 + 1 is shorter than '1' + 1). I hope Squeak integrates FileSystem in 4.4 for 4.5. -- best, Eliot
On 14 Dec 2012, at 17:55, Chris Muller <asqueaker@gmail.com> wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Please, this is so silly: - the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ? BTW: it is a done deal. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 12/14/12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Dec 2012, at 17:55, Chris Muller <asqueaker@gmail.com> wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Please, this is so silly:
- the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly
And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ?
BTW: it is a done deal.
The "deal" is done in the sense that Pharo 2.0 only uses FileSystem. This is the platform developer point of view. Sven, please take note that the deal is not done from the 'User land point' of view. Just recently Pharo 2.0 has gone from alpha to beta. Not to mention the porting status of the packages which build on it. So it is good to have alternatives as Igor points out -- Squeak, Cuis and earlier versions of Pharo. --Hannes
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
- the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly
Hence, you echo my original statement from the other thread. I wrote:
... 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.
And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ?
Both. Because, while FileSystem is a cleaner design, the question posed was whether it is _worth_ breaking so many legacy packages and the promise of O.T. for "a nice API". That's when dramatic attempts to intensify the contrast between the two came out but with no concrete examples we arrived full-circle back to the original question. An acceptable compromise for me for putting it Squeak would be a FileDirectory wrapper that can pass its own test suite, which is precisely what Pharo did!
Chris, in discussions about "compatibility" , people always missing to mention one little thing: users can always choose to not upgrade their projects and keep using older releases. Now, don't you think that it would be strange if new release of system will function exactly as old one, so users can run their project(s) without changing even single line of code? This is possible only if new system(s) should be same thing but with extra functionality. And that will mean that development model would be "never change anything, but add things on top".. But as Markus mentioned, this is completely inappropriate for "system development". I think a more appropriate term for such model would be "system add-ons development". And it is clearly not what we want to do. Also, if there's no changes for your project, what is the point to migrate your project to newer version of system? There will be no win for you: your software will not run faster, will consume same amount of resources, and it is not using new features which were added. So, why just not keep using old release? The software has to evolve, and evolution means changes. And so, if you wanna benefit from system improvements, you'll have to make your hands dirty and do some changes in your code to fit with new system. This is a price you pay for having better system. And there's no escape from that. On 14 December 2012 23:42, Chris Muller <ma.chris.m@gmail.com> wrote:
- the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly
Hence, you echo my original statement from the other thread. I wrote:
... 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.
And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ?
Both. Because, while FileSystem is a cleaner design, the question posed was whether it is _worth_ breaking so many legacy packages and the promise of O.T. for "a nice API". That's when dramatic attempts to intensify the contrast between the two came out but with no concrete examples we arrived full-circle back to the original question.
An acceptable compromise for me for putting it Squeak would be a FileDirectory wrapper that can pass its own test suite, which is precisely what Pharo did!
-- Best regards, Igor Stasenko.
I did not want to take this discussion further , because I dont like to annoy people . But some of the points made here are presented as facts and I don't like that.
Chris, in discussions about "compatibility" , people always missing to
mention one little thing: users can always choose to not upgrade their projects and keep using older releases.
I will mention another thing. Freedom is an illusion. In the end you are always bound by limitations and your own personal needs. Especially that nasty little thing that is called "dependecies". When a library depends on an another , not upgrading can be not even option. This is why I separate braking compatibility in the language side and braking compatibility in the library side. I am perfectly ok with libraries that brake compatibility , why ? Because you can ignore a library and just move to something that fit your needs better. But with language is a lot more difficult to do that usually because the libraries that you are going to use are going to depend on a specific language version.
Now, don't you think that it would be strange if new release of system will function exactly as old one, so users can run their project(s) without changing even single line of code? This is possible only if new system(s) should be same thing but with extra functionality.
No I don't find it strange , actually its not even rare, its common practice for most libraries out there not to brake backward compatibility.
And that will mean that development model would be "never change anything, but add things on top"..
Nope thats simple is not true, you are allowed to change everything except the name of the methods and classes. Which is a small part of the code. And you are also allowed to add as much new stuff as you want as long as its optional. This means that there is nothing stopping a backward compatible library new version to be better than a non backward compatible library new version.
The software has to evolve, and evolution means changes. And so, if you wanna benefit from system improvements, you'll have to make your hands dirty and do some changes in your code to fit with new system. This is a price you pay for having better system. And there's no escape from that.
I don't know why you believe that backward compatible means no progress and non backward compatible means progress. This is simply not true from my experience. I have used a lot of backward compatible libraries and they keep getting better and better. The only piece of software that I used that has gone through the biggest rewrite ever, is blender and I have to admit that the rewrite greatly benefit blender. But blender had a lot of issues and it was clear that much of its basic functionality was deeply flawed and desperately needed a refresh in design. Thats not always the case with software. Some designs have stood the test of time so braking compatibility makes no sense. If you want to keep improving that specific library you can keep doing it. I can give you an example if you want, VCL , it's Delphi's own library. We talking here about a massive library nothing like smalltalk libraries. Has been backward compatible since 1996 that I have first used Delphi and its still is probably the best library I have used together with the other Delphi libraries. The guy behind Delphi knew exactly what a good design is and knew how to make real R.A.D tools which is pretty much the goal of smalltalk itself. The result was that his designs were so successful and liked that he was snatched from Mircrosoft to create .NET and C#. Suffice to say .NET clone most of the designs of Delphi. But even till this day Delphi is highly popular (not as popular as it was in the past) and highly regarded piece of software. But as I said , I am not against braking backward compatibility , in many cases its the best thing to do. But if braking backward compatibility is always your first option then I fear you are going to have the exact same problems blender has with addons developers. And certainly users wont love you, I can guarantee you that not in the short run or the long run. Another thing I must state here , is that as a user did not choose pharo over squeak because it brakes compatibility. I am saying that because I fear I am not the only one to have done so. Because its a dangerous conclusion for one to make that just because someone prefers pharo to squeak because for him it has been more stable and because more libraries are actively developed for it, that is implied he is a big fan of braking compatibility. I also respect the fact that you as developers decided to make "braking compatibility" as a central value of pharo. Its your project you have the right to do whatever you want with it. And I am not even saying its a wrong choice. I only hope for me and others that I dont end up hitting my head against the wall as I have done with the blender api. I can bare a bad design and even get used to it, but something that brakes my code in every single version is simply.... a pain in the a@@ And staying with old versions is not a viable solution for me. I will probably end up choosing squeak or whatever can make my life happy and fun again. On 14 December 2012 23:42, Chris Muller <ma.chris.m@gmail.com> wrote:
- the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly
Hence, you echo my original statement from the other thread. I wrote:
... 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.
And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ?
Both. Because, while FileSystem is a cleaner design, the question posed was whether it is _worth_ breaking so many legacy packages and the promise of O.T. for "a nice API". That's when dramatic attempts to intensify the contrast between the two came out but with no concrete examples we arrived full-circle back to the original question.
An acceptable compromise for me for putting it Squeak would be a FileDirectory wrapper that can pass its own test suite, which is precisely what Pharo did!
-- Best regards, Igor Stasenko.
Guys could you help us producing a better system instead of winning? We ported pier to pharo 2.0 and it was fixed in less than one afternoon. Do you want more examples? Breaking compatibility is NOT central to pharo. But we do it when we have to. Pharo is not a Smalltalk in a museum!!!! Stef On Dec 15, 2012, at 9:05 AM, dimitris chloupis wrote:
I did not want to take this discussion further , because I dont like to annoy people . But some of the points made here are presented as facts and I don't like that.
Chris, in discussions about "compatibility" , people always missing to mention one little thing: users can always choose to not upgrade their projects and keep using older releases.
I will mention another thing. Freedom is an illusion. In the end you are always bound by limitations and your own personal needs. Especially that nasty little thing that is called "dependecies". When a library depends on an another , not upgrading can be not even option. This is why I separate braking compatibility in the language side and braking compatibility in the library side. I am perfectly ok with libraries that brake compatibility , why ? Because you can ignore a library and just move to something that fit your needs better. But with language is a lot more difficult to do that usually because the libraries that you are going to use are going to depend on a specific language version.
Now, don't you think that it would be strange if new release of system will function exactly as old one, so users can run their project(s) without changing even single line of code? This is possible only if new system(s) should be same thing but with extra functionality.
No I don't find it strange , actually its not even rare, its common practice for most libraries out there not to brake backward compatibility.
And that will mean that development model would be "never change anything, but add things on top"..
Nope thats simple is not true, you are allowed to change everything except the name of the methods and classes. Which is a small part of the code. And you are also allowed to add as much new stuff as you want as long as its optional. This means that there is nothing stopping a backward compatible library new version to be better than a non backward compatible library new version.
The software has to evolve, and evolution means changes. And so, if you wanna benefit from system improvements, you'll have to make your hands dirty and do some changes in your code to fit with new system. This is a price you pay for having better system. And there's no escape from that.
I don't know why you believe that backward compatible means no progress and non backward compatible means progress. This is simply not true from my experience. I have used a lot of backward compatible libraries and they keep getting better and better. The only piece of software that I used that has gone through the biggest rewrite ever, is blender and I have to admit that the rewrite greatly benefit blender. But blender had a lot of issues and it was clear that much of its basic functionality was deeply flawed and desperately needed a refresh in design. Thats not always the case with software.
Some designs have stood the test of time so braking compatibility makes no sense. If you want to keep improving that specific library you can keep doing it.
I can give you an example if you want, VCL , it's Delphi's own library. We talking here about a massive library nothing like smalltalk libraries. Has been backward compatible since 1996 that I have first used Delphi and its still is probably the best library I have used together with the other Delphi libraries. The guy behind Delphi knew exactly what a good design is and knew how to make real R.A.D tools which is pretty much the goal of smalltalk itself. The result was that his designs were so successful and liked that he was snatched from Mircrosoft to create .NET and C#. Suffice to say .NET clone most of the designs of Delphi. But even till this day Delphi is highly popular (not as popular as it was in the past) and highly regarded piece of software.
But as I said , I am not against braking backward compatibility , in many cases its the best thing to do. But if braking backward compatibility is always your first option then I fear you are going to have the exact same problems blender has with addons developers. And certainly users wont love you, I can guarantee you that not in the short run or the long run.
Another thing I must state here , is that as a user did not choose pharo over squeak because it brakes compatibility. I am saying that because I fear I am not the only one to have done so. Because its a dangerous conclusion for one to make that just because someone prefers pharo to squeak because for him it has been more stable and because more libraries are actively developed for it, that is implied he is a big fan of braking compatibility.
I also respect the fact that you as developers decided to make "braking compatibility" as a central value of pharo. Its your project you have the right to do whatever you want with it. And I am not even saying its a wrong choice. I only hope for me and others that I dont end up hitting my head against the wall as I have done with the blender api. I can bare a bad design and even get used to it, but something that brakes my code in every single version is simply....
a pain in the a@@
And staying with old versions is not a viable solution for me. I will probably end up choosing squeak or whatever can make my life happy and fun again.
On 14 December 2012 23:42, Chris Muller <ma.chris.m@gmail.com> wrote:
- the consensus is that FileSystem is a nice API - the consensus is that FileDirectory is/was ugly
Hence, you echo my original statement from the other thread. I wrote:
... 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.
And you don't want to switch to it ? Or you want to keep the old API and not force the switch on users ?
Both. Because, while FileSystem is a cleaner design, the question posed was whether it is _worth_ breaking so many legacy packages and the promise of O.T. for "a nice API". That's when dramatic attempts to intensify the contrast between the two came out but with no concrete examples we arrived full-circle back to the original question.
An acceptable compromise for me for putting it Squeak would be a FileDirectory wrapper that can pass its own test suite, which is precisely what Pharo did!
-- Best regards, Igor Stasenko.
Chris Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers). I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system. - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. Did you read the Pharo motto? Stef On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi guys, Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem? I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code. In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind. Best regards Janko Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Hi guys,
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- Best regards, Igor Stasenko.
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way. Janko
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Janko, that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS... Esteban On Dec 15, 2012, at 12:31 PM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way.
Janko
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it. but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort. I'm sorry if that annoys some of you time to time, but that's the way to improve: to change. Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone. Esteban On Dec 15, 2012, at 12:40 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Janko, that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS...
Esteban
On Dec 15, 2012, at 12:31 PM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way.
Janko
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hi Esteban, I understand and support the cleanness focus, this is why Pharo actually seems very promising for the future. Just that cleaning should be gradual, in a sense that while introducing new you keep an old but clearly marked as obsolete for a, say, year or two. So that user base have a time to adapt to the new change. I think if you put the old FD in a ObsoleteFileDirectory package and load it by default for a year, then not anymore, this will certainly ease fears of some of us. Don't count me on this group, but I understand the guys, why don't like an approach you are going. Because it is user unfriendly even that a solution seems to be simple. Cleanness won't be hurt by that! Best regards Janko Dne 15. 12. 2012 12:49, piše Esteban Lorenzano:
Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it.
but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort.
I'm sorry if that annoys some of you time to time, but that's the way to improve: to change.
Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone.
Esteban
On Dec 15, 2012, at 12:40 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
Janko, that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS...
Esteban
On Dec 15, 2012, at 12:31 PM, Janko Mivšek <janko.mivsek@eranova.si <mailto:janko.mivsek@eranova.si>> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si <mailto:janko.mivsek@eranova.si>> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way.
Janko
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si <http://www.aidaweb.si/>
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si <http://www.aidaweb.si/>
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
+ 10000000000
Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it.
but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort.
I'm sorry if that annoys some of you time to time, but that's the way to improve: to change.
Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone.
+1
but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort.
I'm sorry if that annoys some of you time to time, but that's the way to improve: to change.
Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone.
so for all those who still want "FileDirectory" semantics available, you can load the FileSystem-Compatibility package from here: http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy I think we should provide a configuration and add it to the MetacelloRepository. And btw, there is your backward-compatiblity. Except for some weird Mac-specific file-type stuff that is currently missing from FileSystem everything works without changing a single line of code. so that invalidates the whole thread IMO.
Some suggestions for naming the tabs in Configuration Browser... Perhaps "Untrusted" can be renamed "Community": * "Untrusted" leaves a bad taste in my mouth and is not good PR. * "Untrusted" a fairly harsh judgment of a lot of good projects. There are certainly projects in there from people I would trust. * Linking to "Untrusted" from within the standard image degrades trust in the whole Pharo experience. * The term "Community" encompasses the essential "not vetted by Inria Pharo Team" warning I feel also the tab named "Configurations" does not convey the sense that "these configurations are vetted and supported by the Inria Pharo Team". It often leaves me with the ironic thought "if one tab is Configurations then what is the other tab? Not Configurations?" Perhaps this one can be renamed "Core" or "Pharo Team" or "Inria" cheers -ben
On Dec 19, 2012, at 5:27 PM, Ben Coman <btc@openInWorld.com> wrote:
Some suggestions for naming the tabs in Configuration Browser...
Perhaps "Untrusted" can be renamed "Community": * "Untrusted" leaves a bad taste in my mouth and is not good PR. * "Untrusted" a fairly harsh judgment of a lot of good projects. There are certainly projects in there from people I would trust. * Linking to "Untrusted" from within the standard image degrades trust in the whole Pharo experience. * The term "Community" encompasses the essential "not vetted by Inria Pharo Team" warning
Yes, good idea.
I feel also the tab named "Configurations" does not convey the sense that "these configurations are vetted and supported by the Inria Pharo Team". It often leaves me with the ironic thought "if one tab is Configurations then what is the other tab? Not Configurations?" Perhaps this one can be renamed "Core" or "Pharo Team" or "Inria"
cheers -ben
On 12/15/12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Janko, that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS...
Excellent, where is this FD wrapper to FS of Camillo available? --Hannes
Esteban
On Dec 15, 2012, at 12:31 PM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way.
Janko
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code.
In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind.
But there is a well-written documentation of FS. I wonder, if there's any documentation for FileDirectory ever existed.
Best regards Janko
Dne 15. 12. 2012 08:55, piše Stéphane Ducasse:
Chris
Could you give us a break pleaseeeeeee? We are spending all our energy to build a better system that other people can use to make a living. May be we should just create a system for having fun in our teams? Because at the end of the day we just need to produce ideas and some prototypes (not even build them as researchers).
I really think that there are still plenty of places where the system is not good. If you disagree then you may want to spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove to the world that you are a cool entrepreneur) ;D
Now nobody force you to: - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or phrase your points with code snippet that can help the system.
- use pharo in fact you are not using it so you are living in an happy world. So this is perfect.
Did you read the Pharo motto?
Stef
On Dec 14, 2012, at 5:55 PM, Chris Muller wrote:
I'm tired of talking about this but I just can't let this go.. I don't know if its just romantic, starry-eyed mountain climbers or intentional false-propaganda but... confusion reigns here! :) This example is bunk.
Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 which, for whatever reason, is admittedly not great code but that's not the point -- Sean is trying to use this example to demonstrate how using FileSystem will let you "scale new heights" over FileDirectory. The real equivalent to what Sean wrote is:
"FileDirectory" localFileName: aString | file | super localFileName: aString. file := FileDirectory directoryEntryFor: aString. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
"FileSystem" localFileName: aString | file | super localFileName: aString. file := aString asFileName. file exists ifFalse: [ ^ self ]. self modifiedAt: file entry modificationTime.
Ahhhh, I've broken all my systems but look how I'm scaling new heights with FileSystem! (not!)
On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Chris Muller-4 wrote
While someone in the Pharo community said FileSystem over FileDirectory is "huge", I see it as an incremental API change
Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art.
Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools.
I hate to keep repeating myself, but the Pharo manifesto is very clear, and makes these types of arguments moot: - Better for the better - Beauty to learn from - Not backward compatible - Clean, lean and fast
Cheers, Sean
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 15 December 2012 12:31, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
Yes, there's one big reason: maintainability. And manpower. Who would like to maintain FD? Any takers?
Gain with a (in this case very small) bit of manpower to ease upgrade to new FS by providing existing FD for a while outweighs the loss by not doing that. As a professional organization providing a professional product Pharo should think rather that way.
Hold on.. Since when Pharo project became professional product? How much money you and others paying for using it? Yes, we position it as a product FOR professionals, but does it automatically makes a professional one? I don't think so. So, why you think that it is correct to put such requirements/expectations it?
Janko
-- Best regards, Igor Stasenko.
Dne 15. 12. 2012 12:46, piše Igor Stasenko:
Hold on.. Since when Pharo project became professional product? How much money you and others paying for using it? Yes, we position it as a product FOR professionals, but does it automatically makes a professional one? I don't think so. So, why you think that it is correct to put such requirements/expectations it?
Let me explain what I meant by 'professional product'. Product for professionals implies the characteristics of professional product. Even if it is an open source one and partially paid by donations. One of the main characteristic is a clear path of upgrading to a new version. Another is a proper 'Customer Relationship Management'. BTW, ask Gemstone guys for help here, they are very good in migration help to the new version and evolution to the new features. Not to mention their amazing attitude to the customers. To conclude, a bit better PR would make wonders here. Sometimes we need just to listen to our users even that we don't agree with them. Again one of the characteristics of professional product behavior, like it or not. Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Well... the "FD affaire" was discussed in this list like 6 months ago, and that was the path we choose: to put the ObsoletePackages into a "graveyard" repository, so people willing to use it can load and be happy with that. The path you suggested was analyzed (and discarded) at the time because it introduces a certain level of work, even if placed on "obsolete", and we choose to use that effort into make the new things work properly. So, yes... we hear "our customers", but we also have an opinion and we try to do what we think is the better option. To hear does not means "to accept" just like that... Also, are you going to tell me than ask for install a package if you want it is "too much effort" I do want a professional product, but that takes time, effort and some level of acceptance than things needs to be changed to drop old/obsolete stuff... Also, about PR... yes, we all need a better level of communication, but in this case, we actually provided a migration path. And ok, is not what you would do, but now I ask you to hear, and to write the Gofer script into your workspace :) Esteban On Dec 15, 2012, at 1:39 PM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:46, piše Igor Stasenko:
Hold on.. Since when Pharo project became professional product? How much money you and others paying for using it? Yes, we position it as a product FOR professionals, but does it automatically makes a professional one? I don't think so. So, why you think that it is correct to put such requirements/expectations it?
Let me explain what I meant by 'professional product'. Product for professionals implies the characteristics of professional product. Even if it is an open source one and partially paid by donations. One of the main characteristic is a clear path of upgrading to a new version. Another is a proper 'Customer Relationship Management'.
BTW, ask Gemstone guys for help here, they are very good in migration help to the new version and evolution to the new features. Not to mention their amazing attitude to the customers.
To conclude, a bit better PR would make wonders here. Sometimes we need just to listen to our users even that we don't agree with them. Again one of the characteristics of professional product behavior, like it or not.
Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 15 December 2012 13:39, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 15. 12. 2012 12:46, piše Igor Stasenko:
Hold on.. Since when Pharo project became professional product? How much money you and others paying for using it? Yes, we position it as a product FOR professionals, but does it automatically makes a professional one? I don't think so. So, why you think that it is correct to put such requirements/expectations it?
Let me explain what I meant by 'professional product'. Product for professionals implies the characteristics of professional product. Even if it is an open source one and partially paid by donations. One of the main characteristic is a clear path of upgrading to a new version. Another is a proper 'Customer Relationship Management'.
BTW, ask Gemstone guys for help here, they are very good in migration help to the new version and evolution to the new features. Not to mention their amazing attitude to the customers.
To conclude, a bit better PR would make wonders here. Sometimes we need just to listen to our users even that we don't agree with them. Again one of the characteristics of professional product behavior, like it or not.
Janko, let me explain what means "legacy code": - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand Why do you think, a Debugger source mapping are still not fixed over couple years in pharo? Just for curiosity, go and look at the source code involved there.. and try to figure out where the bug is and what needs to be fixed. Or try to understand how events are handled by Morphic.. And since you started talking about PR, think about what PR such code makes each time developers (and especially newcomers) facing it... P.S. If you like FileDirectory so much, print it and put it in a glass case. It deserves some resting place after years of servitude :) -- Best regards, Igor Stasenko.
I agree with what most people have said, from "both" sides. Most of the Smalltalkers I know that are making a living out of it are small teams, if not single developer companies (letting aside the fact my company have more than a dozen of smalltalkers). The transition path should be done as painless as possible for the current users of Pharo, given the restricted manpower such teams have. On the other hand going from 1.4 to 2.0 is a major release, and it has its tradeoffs, so to have the improvements you have to sacrifice some things, the Pharo team COULD make everything backward compatible, but it has a limited manpower too. There is certainly a PR issue here, as an outsider to the Pharo community (but watching it close since some time) I've been seeing an increment of "harsh" responses to those requesting features or "wishes" for the project (without considering the fact that some might have good or bad intentions). My POV on this is that Pharo, by means of its "board/committee/team", have a strong decision on where to take the future of it, it will accept improvements and contributions, but in the end they're going to be the curators of the final product, like a vendor would do it. And I think that's a good thing, projects need a "benevolent dictator". It's a matter of time to see the results of the path taken. "If Henry Ford had asked his customers, they would have told him they want a faster horse...'' I certainly do not want a faster horse. Regards, -- Esteban M. -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659411.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thats a very good quote, and you are absolutely correct . No choice is ideal until it has been taken , materialized and proven itself. But if it does its time is limited until its replaced hopefully by a better idea. None knows before hand what the correct path really is. And as I mentioned already there are cases that braking backward compatibility makes perfect sense in some cases that is desperately needed. And unlike what Stephan said , I am definitely not here to whine. I am here to make sure Pharo is right choice for me. I talked and discussed backward compatibility because I want to know the intentions of Pharo developers. I want to know where Pharo is aiming to go and where it really goes. And finding the right choice is definitely a time consuming always on going travel. I am also aware of Pharo wanting more coding hands to make it better , but then which project does not ? There are times to code and times to discuss or sit back and think where you going , both are very important. Good designs never stay inside museums , they stand the test of time, they become the building blocks of the future. I am also excited so see people and teams use languages like smalltalk professionally and not choose other "safe options" or "popular options". It certainly makes me smile a bit more. ________________________________ From: Esteban A. Maringolo <emaringolo@gmail.com> To: pharo-project@lists.gforge.inria.fr Sent: Sunday, 16 December 2012, 6:44 Subject: Re: [Pharo-project] About (backwards) Compatibility I agree with what most people have said, from "both" sides. Most of the Smalltalkers I know that are making a living out of it are small teams, if not single developer companies (letting aside the fact my company have more than a dozen of smalltalkers). The transition path should be done as painless as possible for the current users of Pharo, given the restricted manpower such teams have. On the other hand going from 1.4 to 2.0 is a major release, and it has its tradeoffs, so to have the improvements you have to sacrifice some things, the Pharo team COULD make everything backward compatible, but it has a limited manpower too. There is certainly a PR issue here, as an outsider to the Pharo community (but watching it close since some time) I've been seeing an increment of "harsh" responses to those requesting features or "wishes" for the project (without considering the fact that some might have good or bad intentions). My POV on this is that Pharo, by means of its "board/committee/team", have a strong decision on where to take the future of it, it will accept improvements and contributions, but in the end they're going to be the curators of the final product, like a vendor would do it. And I think that's a good thing, projects need a "benevolent dictator". It's a matter of time to see the results of the path taken. "If Henry Ford had asked his customers, they would have told him they want a faster horse...'' I certainly do not want a faster horse. Regards, -- Esteban M. -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659411.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Dec 16, 2012, at 5:44 AM, Esteban A. Maringolo wrote:
"If Henry Ford had asked his customers, they would have told him they want a faster horse...''
I certainly do not want a faster horse.
Excellent. Thanks this is so true. Now we are really concerned about making the life of other easier. We always pay attention as esteban said it so well: "Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it. " Now we want to build a new generation smalltalk and we cannot travel heavy because it slow us down. As an example looking for senders in a system full of obsolete classes does NOT work. Stef
participants (18)
-
Ben Coman -
Camillo Bruni -
Chris Muller -
Chris Muller -
dimitris chloupis -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Fernando Olivero -
H. Hirzel -
Igor Stasenko -
Janko Mivšek -
Marcus Denker -
Nicolas Cellier -
Sean P. DeNigris -
Stéphane Ducasse -
Stéphane Ducasse
-
Sven Van Caekenberghe