Good point.
________________________________ From: Esteban Lorenzano <[email protected]> To: [email protected]; dimitris chloupis <[email protected]> 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 <[email protected]> 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 <[email protected]> >To: [email protected] >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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> To: "[email protected]" >>>> <[email protected]> >>>> 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 >>>> >>>> >>>> >>>> >>> >> >> > > > >
