December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Protecting against stack overflow ?

by Sven Van Caekenberghe

On 11 Dec 2012, at 16:54, Chris Muller <asqueaker(a)gmail.com> wrote: > I don't understand how setting a fixed-size stack could ever be > useful. No one would risk blowing up a production app only because > they guessed wrong about the stackDepthLimit, so for production it > would always be set to 0. I kind of disagree: any system has limits, and most server software is set up to enforce limits earlier (maximum connections, file descriptors per process, â¦) and deal as gracefully as possible with them, to protect itself from external abuse or internal errors. Yes this might involve some guessing, so what. I would rather be able to deal with an infinite recursion and return an internal server error, than have the whole server crash. > So that leaves the development use-case. During development the > system is already under heavy scrutiny, the real requirement is just > the ability to _get back control_ when the system doesn't seem to be > doing anything so that infinite recursions can be debugged. So if > simply Command+. interrupt could be made to just work then there's no > need to fiddle with the "guess the stack-limit" game. With a reasonable stack or low memory limit, you won't even have to press cmd-. when something goes wrong ;-) But of course, cmd-. should just work. > I like Eliots idea of paying attention to how long the > LowSpaceSemaphore fires, except not trying to analyze the stack. > Instead, check how much space was _freed_ by the handlers of low-space > (#freeSomeSpace I think) and, if it is Zero or very low, THEN open a > debugger. > > > > On Tue, Dec 11, 2012 at 8:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> i would be happy to have something, which can be expressed as >> following 'unit test': >> >> Smalltalk vm setStackDepthLimit: 100. >> >> self should: [ self recurseTimes: 101 ] throw: Exception. >> >> Smalltalk vm setStackDepthLimit: 0. "no limit" >> >> self shouldNot: [ self recurseTimes: 101 ] throw: Exception. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Esteban Lorenzano

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(a)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(a)gmail.com> > To: Pharo-project(a)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(a)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(a)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(a)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(a)usi.ch> > >>> To: "Pharo-project(a)lists.gforge.inria.fr" > >>> <pharo-project(a)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 > >>> > >>> > >>> > >>> > >> > > > > > > >

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by adrians

Hi Marcus, I figured it must be the complexity of fixing the debugger that's keeping it in the broken state that it is for this long. Mainly I wanted to get a sense of how important is fixing this relative to the other things that need fixing. It would seem to me that fixing the tool that you use to fix things in general would be right up there, but maybe, possibly because the people capable of fixing this aren't significantly handicapped by the issues, this is not as much a priority as it could be. Would you know if there is any chance some of these problems will be fixed for 2.0? Regards, Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Marcus Denker

On Dec 11, 2012, at 4:38 PM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > Just out of curiosity.. How does the cutting edge of LISP compare to > what we have in Pharo at the moment? I've read somewhere that > smalltalk has the best refactoring/debugging tools. Would you agree > with that? Are there object centric lisp debuggers? If someone asked > you 'why are you working on a smalltalk implementation and not some > lisp?', what would your answer be? I suppose nicer syntax might be the > first thing that comes to mind, but I don't see that as being super > important. Of course, I realise lispers might use a more functional > style, but you could be writing smalltalk style code in CLOS or > something, right? > > Feel free to ignore these questions if you're not interested. I'm just musing. > my problem is timeâ¦ > On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> Yes, we should improve the debuggerâ¦ >> >> There are some nice things happening around the debugger >> -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. >> In the current Debugger, Model and View >> are completely mixed (and the implementation is kind of old style, that is, very >> low level and complex) >> Last week He and Ben did an experiment to get a second UI working (Spec). >> >> -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating >> if this can not replace the context step simulator based partsâ¦ >> >> -> For later, we would like to integrate the idea of object centric debugging >> (halt on next ivar change, halt on next messageâ¦) >> >> -> â¦ >> >> The problem right now is that the debugger infrastructure is far more complicated than >> it should be, making is hard to change, fix and improve it. >> >> Marcus >> >> On Dec 9, 2012, at 11:07 PM, adrians <nmanole(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm a Smalltalk newbie and I would like to help fix some simpler issues. For >>> example, I've recently logged some issues surrounding smart character use. I >>> set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded >>> to debug. >>> >>> Now, I understand that for the old-timers stepping through a selector is >>> straightforward, no matter what help the debugger gives you. For myself, and >>> likely many other Smalltalk noobs who'd like to help, I need all the help I >>> can get. One such support is an accurate indication of where the PC is as >>> you step through a body of code. Currently, in the 2.0 one-click image >>> (build 20431), things seem quite broken wrt getting accurate visual feedback >>> of where you are. >>> >>> First, as you step over message sends, the highlighted selection is shown in >>> a totally incorrect spot. Sometimes, just a bit off from where you expect to >>> be, but sometimes quite a bit off, for example in a block that should not >>> even be entered. In the selector I mentioned above, the highlighted location >>> enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" >>> returns false. >>> >>> Second, the PC location highlight is removed when you click somewhere inside >>> the code. This should never turn off - it's as if you switch the lights off, >>> for people not familiar with some particular code. I know you can use the >>> "Where" button to re-establish the highlight, but other than the fact that >>> you shouldn't have to do this, the highlighted selection is sometimes shown >>> in the wrong place. >>> >>> Third, as you step through code, you would expect that the values of >>> variables as shown in the bottom right panel of the debugger are accurately >>> updated as state changes. I've seen cases, relatively frequent, where this >>> is not so. Current values are shown only after some further advancement >>> through code. >>> >>> There is an old issue tracking debugger selection, >>> http://code.google.com/p/pharo/issues/detail?id=709 >>> <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the >>> problem seems to have stalled. Additionally, I'm not sure that this >>> particular issue addresses the third point I made about stale variable >>> values being shown. >>> >>> Could I ask that making the debugger work be made a priority? Of course one >>> can muddle through some code even with visually broken indicators, but it >>> should not be so, IMO. The old timers can make the case that there are other >>> more pressing issues to be addressed, but IMO it makes sense to make the >>> actual tool used to fix problems as helpful as possible for everyone so that >>> even non-experts can be productive and lend a helping hand. >>> >>> >>> Cheers, >>> Adrian >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

Dec. 11, 2012

Re: [Pharo-project] Protecting against stack overflow ?

by Chris Muller

I don't understand how setting a fixed-size stack could ever be useful. No one would risk blowing up a production app only because they guessed wrong about the stackDepthLimit, so for production it would always be set to 0. So that leaves the development use-case. During development the system is already under heavy scrutiny, the real requirement is just the ability to _get back control_ when the system doesn't seem to be doing anything so that infinite recursions can be debugged. So if simply Command+. interrupt could be made to just work then there's no need to fiddle with the "guess the stack-limit" game. I like Eliots idea of paying attention to how long the LowSpaceSemaphore fires, except not trying to analyze the stack. Instead, check how much space was _freed_ by the handlers of low-space (#freeSomeSpace I think) and, if it is Zero or very low, THEN open a debugger. On Tue, Dec 11, 2012 at 8:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i would be happy to have something, which can be expressed as > following 'unit test': > > Smalltalk vm setStackDepthLimit: 100. > > self should: [ self recurseTimes: 101 ] throw: Exception. > > Smalltalk vm setStackDepthLimit: 0. "no limit" > > self shouldNot: [ self recurseTimes: 101 ] throw: Exception. > > > > > -- > Best regards, > Igor Stasenko. >

Dec. 11, 2012

Re: [Pharo-project] Kind of Spreadsheet component for Seaside?

by Marcus Denker

On Dec 11, 2012, at 4:39 PM, "Peter H. Meadows" <peter.h.meadows(a)googlemail.com> wrote: > Is there any chance it might become open source in the future? Any > idea what it might cost to buy? > No idea, but I think not. Avi mentioned that the implementation would not be really interesting today anyway (how you do things has changed), but that he would like to see people taking the idea and redoing it in a modern way. > On Tue, Dec 11, 2012 at 3:24 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Dec 11, 2012, at 4:22 PM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: >> >>> What happened to Dabble DB? >> >> bought by Twitter in a talent acquisition, killed off. >> >>> Is any of their source code open? >> >> no. >> >>> >>> On Mon, Dec 10, 2012 at 8:44 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>>> FDominicus wrote >>>>> I'm just wondering does anyone have/know about a kind of spreadsheet >>>>> component/application for Seaside? >>>>> >>>>> Any hints are welcome >>>>> >>>>> Friedrich >>>> >>>> >>>> There is a JQGrid (http://www.trirand.com/jqgridwiki/doku.php) widget in >>>> JQueryWidgetBox repo on Squeaksource but that is just handy for displaying >>>> tabular info. Nothing for entering formulas etc. >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Kind-of-Spreadsheet-component-for-Seaside-tp4658697p4… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >> >> >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by dimitris chloupis

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(a)gmail.com> To: Pharo-project(a)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.

Dec. 11, 2012

Re: [Pharo-project] Kind of Spreadsheet component for Seaside?

by Peter H. Meadows

Is there any chance it might become open source in the future? Any idea what it might cost to buy? On Tue, Dec 11, 2012 at 3:24 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 11, 2012, at 4:22 PM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > >> What happened to Dabble DB? > > bought by Twitter in a talent acquisition, killed off. > >> Is any of their source code open? > > no. > >> >> On Mon, Dec 10, 2012 at 8:44 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>> FDominicus wrote >>>> I'm just wondering does anyone have/know about a kind of spreadsheet >>>> component/application for Seaside? >>>> >>>> Any hints are welcome >>>> >>>> Friedrich >>> >>> >>> There is a JQGrid (http://www.trirand.com/jqgridwiki/doku.php) widget in >>> JQueryWidgetBox repo on Squeaksource but that is just handy for displaying >>> tabular info. Nothing for entering formulas etc. >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Kind-of-Spreadsheet-component-for-Seaside-tp4658697p4… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> > >

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Peter H. Meadows

Just out of curiosity.. How does the cutting edge of LISP compare to what we have in Pharo at the moment? I've read somewhere that smalltalk has the best refactoring/debugging tools. Would you agree with that? Are there object centric lisp debuggers? If someone asked you 'why are you working on a smalltalk implementation and not some lisp?', what would your answer be? I suppose nicer syntax might be the first thing that comes to mind, but I don't see that as being super important. Of course, I realise lispers might use a more functional style, but you could be writing smalltalk style code in CLOS or something, right? Feel free to ignore these questions if you're not interested. I'm just musing. On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Yes, we should improve the debuggerâ¦ > > There are some nice things happening around the debugger > -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. > In the current Debugger, Model and View > are completely mixed (and the implementation is kind of old style, that is, very > low level and complex) > Last week He and Ben did an experiment to get a second UI working (Spec). > > -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating > if this can not replace the context step simulator based partsâ¦ > > -> For later, we would like to integrate the idea of object centric debugging > (halt on next ivar change, halt on next messageâ¦) > > -> â¦ > > The problem right now is that the debugger infrastructure is far more complicated than > it should be, making is hard to change, fix and improve it. > > Marcus > > On Dec 9, 2012, at 11:07 PM, adrians <nmanole(a)gmail.com> wrote: > >> Hi, >> >> I'm a Smalltalk newbie and I would like to help fix some simpler issues. For >> example, I've recently logged some issues surrounding smart character use. I >> set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded >> to debug. >> >> Now, I understand that for the old-timers stepping through a selector is >> straightforward, no matter what help the debugger gives you. For myself, and >> likely many other Smalltalk noobs who'd like to help, I need all the help I >> can get. One such support is an accurate indication of where the PC is as >> you step through a body of code. Currently, in the 2.0 one-click image >> (build 20431), things seem quite broken wrt getting accurate visual feedback >> of where you are. >> >> First, as you step over message sends, the highlighted selection is shown in >> a totally incorrect spot. Sometimes, just a bit off from where you expect to >> be, but sometimes quite a bit off, for example in a block that should not >> even be entered. In the selector I mentioned above, the highlighted location >> enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" >> returns false. >> >> Second, the PC location highlight is removed when you click somewhere inside >> the code. This should never turn off - it's as if you switch the lights off, >> for people not familiar with some particular code. I know you can use the >> "Where" button to re-establish the highlight, but other than the fact that >> you shouldn't have to do this, the highlighted selection is sometimes shown >> in the wrong place. >> >> Third, as you step through code, you would expect that the values of >> variables as shown in the bottom right panel of the debugger are accurately >> updated as state changes. I've seen cases, relatively frequent, where this >> is not so. Current values are shown only after some further advancement >> through code. >> >> There is an old issue tracking debugger selection, >> http://code.google.com/p/pharo/issues/detail?id=709 >> <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the >> problem seems to have stalled. Additionally, I'm not sure that this >> particular issue addresses the third point I made about stale variable >> values being shown. >> >> Could I ask that making the debugger work be made a priority? Of course one >> can muddle through some code even with visually broken indicators, but it >> should not be so, IMO. The old timers can make the case that there are other >> more pressing issues to be addressed, but IMO it makes sense to make the >> actual tool used to fix problems as helpful as possible for everyone so that >> even non-experts can be productive and lend a helping hand. >> >> >> Cheers, >> Adrian >> >> >> >> -- >> View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by dimitris chloupis

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(a)gmail.com> To: Pharo-project(a)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(a)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(a)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(a)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(a)usi.ch> >>> To: "Pharo-project(a)lists.gforge.inria.fr" >>> <pharo-project(a)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 >>> >>> >>> >>> >> > >

Dec. 11, 2012