Adam Wilson Wrote:

> On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude <lovelydear@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/

On 7/15/2012 3:52 PM, Adam Wilson wrote:
> So the problem is semantics then? Because I dredge up another word to describe
> what we are asking for if that's all it takes. But I don't think that anyone
> else is going to read "stable" as "unchanging". Software is by definition
> changing, or it's dead. It appears to my parsing of your sentence that you are
> asserting that stable == static. By that definition of stable, Windows ME is
> "stable" and ... ehrm, not a soul in the tech world would agree with that
> summation of WinME.
>
> As I said earlier, no one else in FOSS or Commercial equates stable with "has no
> bugs", it means no new features and no regressions. Not a single solitary person
> I've talked too expects their software to be bug free.
>
> THIS is what we mean when we say "stable":
> http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
> It's also how pretty much everyone else will read "stable".

D does have a test suite, and it is a (almost always achieved) goal to keep it always passing, even on the dev branch. In fact, most of my work is running the test suite and making sure each change doesn't regress. (Regressions that do slip through were not in the test suite.)

Frankly, I don't know how to do what you're asking for. D users, every single day, clamor for:

1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!

And, to reiterate, we did release D1. Since its release, it has only received bug fixes. No breaking changes, no regressions. This, inevitably, has made many D1 users unhappy - they wanted new features folded in.

So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all these mutually contradictory requests.

On 7/15/2012 3:43 PM, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
>> On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
>>> The problem is that we're still ironing out too much, and most of the
>>> breakage relates to bug fixes, not new features.
>>
>> There's been a lot of non-bug-fixing breakage, for example, renaming library
>> functions.
>
> Yeah, but those are always done through a deprecation path, so there's no
> immediate breakage. And we've done most of that already, so that should be
> happening less and less.

It needs to stop completely.

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!"

On 7/12/2012 11:52 PM, Adam Wilson wrote:
> I hope Walter isn't against this, because I'm not seeing much community
> disagreement with this...


Note this: http://d.puremagic.com/test-results/

I don't see how what we're doing is so broken.

Patrick Stewart:

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

Python C interpreter is also far simpler than designing a new system language, and writing its compiler and standard library. And behind Python there are far more developers and users.

Bye,
bearophile

On 15/07/2012 23:36, SomeDude wrote:
> On Sunday, 15 July 2012 at 20:50:47 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.
>>
>> Also, check Python website: they recommend python v2 for all new users
>> that don't know what to choose. They are both stable, but v2 has more
>> libraries, and they do reassure them by saying v2 will be supported
>> for time to come.
>>
>> On the other hand, on D website, D1 is pushed to the dark corners as
>> ugly half child nobody should know about, and D2 is titled as thing to
>> chose without thinking. And there is no mentioning D1 is relatively
>> stable, while D2 is still unstable, non conforming to D documentation
>> and that some things just don't work, while in constant beta flux that
>> breaks things on regular basis with each release.
>>
>> So tell me again, which language treats its users with more respect ?
>> Which one encourages users more to use them?
>
> The problem I raised is not a problem of respect. It's a problem of
> community. The D community is a tiny fraction of the Python community.
> It has been steadily growing this last year and a half or so, but it's
> still fragile. The D1/D2 split basically set it back to near zero for
> several years, with many people leaving, only a few staying, and a
> number recently coming back.
>
> The project certainly can't afford yet another split, or many key people
> will simply throw the towel. I for one would rather see part of the
> users quitting than active members.
>
> As for the stability of D2, upir opinion may be different, but it has
> largely improved recently due to increased forces, as several people
> have noted (David Simcha in a recent thread said something about the
> stability of the compiler being good enough that he only rarely
> encountered a problem). And considering the rate of bugs correction, it
> will continue to improve. You only need to have a look at the changelog
> to see that it's growing with each release, and I'm pretty confident
> that the 2.060 will contain more bug fixes than any past release.

Well bug will be fixed for sure.

But, as explained, as new feature are also introduced, bug will also be introduced.

This is why stable release is never reached.

bearophile Wrote:

> Patrick Stewart:
> 
> > 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".
> 
> Python C interpreter is also far simpler than designing a new system language, and writing its compiler and standard library. And behind Python there are far more developers and users.
> 
> Bye,
> bearophile

We are coming back to dsource & Tango graveyard story. D had equally capable and large community to. Its resources got wasted. People left. Huge amount of work just wasted for nothing. On the other hand, Python has one of the largest *operational* standard library and tons of 3rd party ones. Why? Because with stable language, all those libraries stayed in the game.

On 7/15/2012 4:15 PM, Patrick Stewart wrote:
> We are coming back to dsource & Tango graveyard story. D had equally capable
> and large community to. Its resources got wasted. People left. Huge amount of
> work just wasted for nothing. On the other hand, Python has one of the
> largest *operational* standard library and tons of 3rd party ones. Why?
> Because with stable language, all those libraries stayed in the game.


Quite a bit of Tango has moved into D2, the parts whose authors had the rights to change the license and so move it.

On 7/15/2012 4:08 PM, Patrick Stewart wrote:
> 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!"

All versions pass the D test suite 100%. Any regressions that appeared were not in the test suite, but do get added as they are fixed.