D versionning

[Patrick Stewart]

SomeDude 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.
> 

CentOS 6.x (latest) is shiping with 2 year old python version. Most production servers I maintain are 4.x - 5.x with Python 2.4+ that are around 5 year old releases. Upgrading is not an option for most situations. And we are talking here about linux distro that targets stability above all.

> 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 

It goes other way around. Stability is achieved by branching development from trunk on certain milestones. Whole D development is one constant trunk with added bugs and broken backward compatibility with each release.

> 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.

Web projects? Speed? PyPy? You are so far up premature optimization story that you miss what we are talking here about.

Second biggest flaw with D development is premature optimization opsession by large number of devs. "We haven't make it work quite yet as specs define, but lets us optimize it, so it can work incorrectly even faster!"