"Aarti_pl" <aarti@interia.pl> wrote in message news:fqrsbq$186c$1@digitalmars.com...
> Saaa pisze:
>> If all the changes are non breaking ones and if it doesn't take any significant time to port them, why then are people still against it?
>>
>> Why does everybody keep pointing out that other things need fixing. That is irrelevant, if porting the extra feature to D1 won't take any time.
>>
>> I would applaud any feature coming to the stable D1 branch.
>> Everybody should be warned that D2 might break at any release, but D1 can
>> safely be used and when lucky it will even be improved without breaking
>> older D1 code (its like giving away presents).
>
>
> I see two important problems with backporting new features from D 2.0 into D 1.0 branch:
>
> 1. Porting bigger chunks of code can introduce new bugs into 1.0 branch. Please note that 2.0 is not tested as well as 1.0, so it is more than probable that it will happen. Also it is possible that some of new features can interact with other features (old or new ones) so it will make porting a headache: you will always have to think what should be ported to make the whole thing working in 1.0.

A few new bugs would not bug me that much, as long as the older code won't
be effected.
About the headache: If it is a headache, Walter leave it as it is.
I'm only pro giving D1 new features if it won't effect the current release
speed, which was the assumtion in the first post.

>
> 2. Semantics of new features in D 2.0 branch can change until 3.0 branch will be crated. It basically means that, when new features will be continuously ported to D 1.0, then 1.0 branch will no more be stable. You will not be able to create any program in D 1.0 (using new features) and be sure that it won't break in future, because this features can be changed later.

This does not apply. No unstable feature must be allowed to be ported to D1 as it is given that D1 is stable, meaning no new feature may break older code.

>
> In my opinion there is not much sense in porting 2.0 compiler features into 1.0 branch. Also creating branch 1.5 does not make much sense for me. If I would like to use all new features of D, I would just use 2.0 branch. That said, I really appreciate effort of porting Phobos 2.0 into 1.0 (std2 project in dsource). Some of new features of Phobos 2.0 are really useful, and Phobos 1.0 badly lacks them.

Making yet another branch is crazy yes. What you say about phobos applies to D as well and if the two points you made were invalid you would agree that extra features are nice presents to get ;)

>
> Best Regards
> Marcin Kuszczak
> (aarti_pl)

Bill Baxter, el  7 de marzo a las 14:29 me escribiste:
> Jesse Phillips wrote:
> 
> >I'm with Jason and Gregor on this one. Would it be nice to have these changes, yes, but I don't think that is the way to look at it. Even if D3 is completely compatibly with all D2 code, I wouldn't want it be in the D2 tree. Think about it, you don't get all the Java 7 stuff in Java 6, just because you don't see it to want it. D2 is going to introduce a lot of breaking in old code, and headaches with const that many don't want. And I believe this is really where you're coming from? You like the lack of const, but want the other stuff? (not saying there is anything wrong with it. I'm kinda frightened to switch, eager, but frightened)
> 
> Maybe a better analogy is with Python 3K.  It's a major release with some new breaking additions, and I seem to recall they're planning on having Python 2.x releases that incorporate backported features from Python 3K.  Probably someone here is more up to date on that situation than me.

Python has a well mature and proved development model. It has major
versions, where huge (a la D2.0) changes are possible, minor versions,
where new non-breaking (or small breaking changes[*]) are included (what
is lacking in D), and patchlevel version, where only bugfixes are included
(D1).

[*] This breaking changes are done in a progressive way, and it (usually)
    takes 3 minor Python versions to complete the changes:
    * First, the change is included *optionally*, the user can test it
      using import __future__[1] (this could be a compiler flag for D).
    * In the next minor version, the new feature is included by default,
      and if appropriate, "old" stuff is marked deprecated (issue a
      deprecation warning when used).
    * In the next minor version, the deprecated features are removed.

I think this gives to the language a great compromise between evolution and stability. Of course there are several development releases for new minor versions, they are not tagged as "stable" as soon as they get the new features, so people can test it until they are considered stable.

I think D could implement this model without problems, and I don't see any problems in the Python world with this, old minor version are not maintained then they get old, so is not that much work.

[1] http://www.python.org/dev/peps/pep-0236/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
In 1995 a Japanese trawler sank, because a Russian
cargo plane dropped a living cow from 30,000 feet

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fqr25f$2d82$1@digitalmars.com...
> Kris wrote:
>> It is simpler and generally more effective to design an API which avoids the .dup issue.
>
> But you shouldn't *need* to be doing .dup for invariant arrays. If you are duping them, there's a problem somewhere else in the code.


Indeed. This is the very argument used to refute your earlier claims about COW being the true-path <g>. The result of that was to design around the issue altogether. You certainly won't find me invoking the wrath of redundant .dup (and surely the mere existence of .idup should ring alarm-bells).


>> Usage of dup (and idup) is not a good poster-child to hold aloft, when they can be avoided in the vast majority of cases. For example, in all of Tango there's only one instance where a const return would be nice to have, due mostly to an avoidance of the situation. The usage of  D1 'in' can suffice for all read-only parameters. Tango is a large body of code, as you know, with attention given to efficiency. One might hope the highly narrow scope therein for D2 const/invariant might indicate something of value for you --  perhaps that const/invariant might slip into a "special consideration" usage instead? If it simplified the syntax and/or usage, a lot of people would be jumping into D2 instead of remaining with D1
>
> You can write bug-free and perfectly correct programs without const or invariant at all. But once a code base exceeds a certain level of size and complexity (and I don't know what that level is), const/invariant will become increasingly valuable. People who do work in large corporations managing extremely large codebases with legions of programmers working on them have made this abundantly clear to me.


Yes, I agree, and put this argument to you several years ago while COW was king for D.

My whole point is that D2 has made const/invariant into something that complicates the usage and comprehension of the language as a whole:

- Yes, read-only attributes can be /very/ useful in specific scenarios.
- Yes, D already supported various (non-const) ways to enable read-only
aggregates
- Yes, D1 already had read-only parameters
- Yes, most people can happily get by without const/invariant
- Yes, there are other valuable uses for invariant that have yet to ripen
(parallelization, for example)
- Yes, the further revised design of const/invariant in D2 still complicate
language usage & comprehension past the level where the tradeoffs make sense
(IMO). I've tried to say this already, and will keep repeating it <g>


>> What I'm saying is effectively this: you don't have to solve all the const cases to still have a stupidly-effective language. The tradeoffs to get there so far are, imo, too costly in areas of comprehension and usability - two huge factors in the attraction of D in the first place. Some folks might disagree, and that's cool.
>
> Part of the problem with const/invariant in D is we burned a lot of goodwill with the two previous designs that fell short of the mark. But I believe the design now is a sound one (despite the bugs in implementing some of the details, many of which were fixed in the latest update).


There's no question here of whether it may or may not be 'sound' ... instead, it's a question of usability. There's not much value in being the world's most wonderful companion when one's body-odor is sufficient to keep everyone at bay - like most things, there's a question of balance. You seem to think D2 has finally got it right. I disagree, as do many other large-scale users of the language (the very people who you'd expect to be in the D2 camp without question).

I'm not here to argue about black or white. Instead I'm attempting to help you understand the reasons why so few people have adopted D2 .... to leverage the earlier analogy, D1 ain't a perfect companion but it has very little body-odor

Hope this helps;

2c

On 07/03/2008, Kris <foo@bar.com> wrote:
>  ... why so few people have adopted D2

I have no idea how many people have adopted D1
I have no idea how many people have adopted D2

But you apparently do, so please do share those numbers. Thanks.

== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> Is it really true?  Is there a group of folks who really want D1 to be
> frozen?
> I myself would like to see D1 get all new features that won't break
> existing source code.

I think there is some use in having a D1 release in terms of having a predictable feature set for code
releases, but at the moment I'm barred from D2 by the const features, while I'd like to use everything else.
Another issue at the moment is GDC support however, and that's a more substantial one in my mind.  Is
there a D2 version of GDC yet?


Sean

Janice Caron wrote:
> On 07/03/2008, Kris <foo@bar.com> wrote:
>>  ... why so few people have adopted D2
> 
> I have no idea how many people have adopted D1
> I have no idea how many people have adopted D2
> 
> But you apparently do, so please do share those numbers.
> Thanks.

There was a poll not so long ago.  Maybe you missed it.
http://baxissimo.freepolls.com/cgi-bin/pollresults/001
It came out about 3:1  D1 users:D2 users.  More D2 users than I was expecting.  But of course it was a self-selecting poll, only announced here on the NG, so you have to take it with a heavy grain of salt.

--bb

Sean Kelly wrote:
> == Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
>> Is it really true?  Is there a group of folks who really want D1 to be
>> frozen?
>> I myself would like to see D1 get all new features that won't break
>> existing source code.
> 
> I think there is some use in having a D1 release in terms of having a predictable feature set for code
> releases, but at the moment I'm barred from D2 by the const features, while I'd like to use everything else.
> Another issue at the moment is GDC support however, and that's a more substantial one in my mind.  Is
> there a D2 version of GDC yet?
> 
> 
> Sean

There is code for D2 checked into the GDC repo.
I don't know how well it works.
But there has not been a release of a 2.x GDC compiler, no.

Post from Dave announcing it was 9/24/2007: digitalmars.com D.gnu:2904


--bb

On 07/03/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> There was a poll not so long ago.  Maybe you missed it.
>  http://baxissimo.freepolls.com/cgi-bin/pollresults/001

I did indeed miss that. Thanks for the link.

>  It came out about 3:1  D1 users:D2 users.  More D2 users than I was
>  expecting.

And (proportionately) more D1 users than I was expecting. Hey ho.

>  But of course it was a self-selecting poll, only announced
>  here on the NG, so you have to take it with a heavy grain of salt.

Indeed. If that poll is accurate then only 119 people use D. :-)

Janice Caron wrote:
> On 07/03/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> There was a poll not so long ago.  Maybe you missed it.
>>  http://baxissimo.freepolls.com/cgi-bin/pollresults/001
> 
> I did indeed miss that. Thanks for the link.
> 
>>  It came out about 3:1  D1 users:D2 users.  More D2 users than I was
>>  expecting.
> 
> And (proportionately) more D1 users than I was expecting. Hey ho.
> 
>>  But of course it was a self-selecting poll, only announced
>>  here on the NG, so you have to take it with a heavy grain of salt.
> 
> Indeed. If that poll is accurate then only 119 people use D. :-)

Some people responded directly to the NG.  I'll repaste the summary here:
Here's a summary of the poll results:

-------------------------------
From the web poll:
Yes: 28  No: 87

From replies here:
Yes: ~6  No: ~13

Totals:
Yes:  34/134 = 25%
No:  100/134 = 75%

--------------------------------
Original post: digitalmars.com digitalmars.D:61017

But anyway, how many people do you think do use D overall?
My guess would be about 10x that number.  That's discounting people who just tried hello world once to see if it worked.

But I guess Walter should have a better idea of the actual figure based on # of DMD downloads from DigitalMars.

--bb

Bill Baxter wrote:
> Walter Bright wrote:
>> You can write bug-free and perfectly correct programs without const or invariant at all. But once a code base exceeds a certain level of size and complexity (and I don't know what that level is), const/invariant will become increasingly valuable. People who do work in large corporations managing extremely large codebases with legions of programmers working on them have made this abundantly clear to me.
> 
> Yes, they believe they need it.  Sure.  But I doubt many of them have done any sort of analysis of how much it actually helps vs. how much it complicates their code base.  I say this as someone who was totally sold on C++ const for the first 10 years I used it.

C++ const is not too useful anyway, as it is not transitive and not invariant. It's more of a convention.

> Now I'm kind of used to not having it.  And, well, the sky hasn't fallen.  But lots of my code has lost superfluous redundancy.
> 
> But I'm going to start trying to compile my code with D2 this weekend and see how it goes.  Hopefully const will mostly stay out of my way.
> 
> --bb