D versionning

[Patrick Stewart]

Adam Wilson Wrote:

> On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude <lovelydear at mailmetrash.com>  
> wrote:
> 
> > On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
> >>> OTOH, it may break the community yet again, which we certainly don't  
> >>> want, probably even less than breaking code.
> >>> Also, the example of Python with two main stable branches that live in  
> >>> parallel is not very encouraging.
> >>
> >> Are you kidding? Python should be used as example of how software  
> >> should be engineered. They keep release schedules, keep stable versions  
> >> & never break backward compatibility without giving their users ways to  
> >> not be stuck in bad situation. It is well thought and planned. Its  
> >> popularity and widespread is not a coincidence,  and the fact that it  
> >> became de facto part of linuxes (shipping with 5 year old versions  
> >> without a fear of deprecation) just proves people can count on it and  
> >> use it without fear of some random unguided development that is typical  
> >> of D with its half thought our new features that bite it on the ass  
> >> year later.
> >
> > I understand your gripe with breaking changes and bugs, but your  
> > painting of the sate of things is caricatural. First Linuxes are not  
> > shipping with 5 year old versions of Python, they usually ship with 2.7  
> > which is the last version of the 2 branch. Meanwhile, the 3 branch is  
> > having a hard time getting used, several years after its introduction,  
> > and some major packages still haven't been ported.
> > http://wiki.python.org/moin/Python2orPython3
> > That is what I was referring to.
> >
> > I agree the Python roadmap is better paved than the D roadmap, which  
> > hardly exists. It does make a case for a dev and a stable branch, which  
> > makes complete sense. OTOH, Python has suffered from disruptive changes  
> > just as much as D, like the fact that incorporating UTF in the language  
> > has justified a completely new branch. And talking about half assed  
> > features, its reference implementation suffers from *major* issues, like  
> > being slow (about 5 times slower than the Pypy JIT implementation) and  
> > monothreaded. And that is not going to be fixed any time soon. And you  
> > can't use PyPy for most serious web projects as native libraries are not  
> > compatible and haven't been ported.
> 
> To be fair, the majority of the problems you listed with Python have  
> nothing to do with their release process but their design process. The two  
> are unrelated. The fact that it suffers disruptive changes is an argument  
> for dev/stable branches, not against.
> 

Point here is how community is handling problems. It is matter of engineering skill, not programming. Both languages have programming bugs and bad decisions. Python fix them without disrupting schedule and usability. D says "suck it up for next X years while we fix it" or "You have some obscure 4 year old version without that bug".

> -- 
> Adam Wilson
> IRC: LightBender
> Project Coordinator
> The Horizon Project
> http://www.thehorizonproject.org/