May 12, 2009
On Mon, 11 May 2009 20:56:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Derek Parnell wrote:
>>  * I'm too busy to invest in something that I will need to rework for D2.
>
> While (without using a text preprocessor) you can't make the source code work for both D1 and D2, the amount of rework necessary is quite minor.

I'll have to step in here and say that's not a true statement.  It quite heavily depends on your project.  For example, Tango still isn't ported to D2, because there are so many designs to re-think.

-Steve
May 12, 2009
Walter Bright wrote:
> D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1.

I think my perception (and I accept it may be a perception which does not reflect reality at large) comes from issues like the following. It's not a particularly important issue, but it's one for which I could find a bug report.

Two years ago, I tried to use a particular construct and DMD incorrectly detected that a statement was not reachable [1]. OK, D1 had been frozen earlier that year, so I thought it would be only a matter of time until the higher priority stuff had been taken care of and someone took care of this issue. That's my experience with stable languages, even if they aren't particularly mainstream (say, Lua).

Two years later I see this issue is still lingering. My perception is that unless I nag someone or send a fix myself no one will take care of it anytime soon. I guess they just have a huge pile of more important stuff, which is fair.

But, 1) how long do you perceive it will take until more pressing matters delay fixing these kinds of bugs? I don't know if 20 bug fixes a month is enough or not to have DMD v1 rock solid in the next 5 years. Are most of the fixes for new bug reports? Is the list of old bugs being cleaned at a good rate? My perception, I said, was that the rate was a bit disapointing (compared with my experience using other language implementations)

2) Even if most bug fixes are common to D1 and D2, isn't it still true that if D2 is being discussed, elaborated, documented and implemented, most of those activities do not fix bugs and take time away from making D1 / DMD v1 stable and with few bugs?

Some say "send a patch". I'll try, when that is possible. But I can't send a patch for every bug I find in my spreadsheet software, browser, programming language, IM client, etc. That means that much of the software I use I have to accept it as is. That applies to everyone which uses a large amount of software and is not a programming demigod.
May 12, 2009
2009/5/12 Luís Marques <luismarques@gmail.com>:
> Walter Bright wrote:
>>
>> D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1.
>
> I think my perception (and I accept it may be a perception which does not reflect reality at large) comes from issues like the following. It's not a particularly important issue, but it's one for which I could find a bug report.
>
> Two years ago, I tried to use a particular construct and DMD incorrectly detected that a statement was not reachable [1]. OK, D1 had been frozen earlier that year, so I thought it would be only a matter of time until the higher priority stuff had been taken care of and someone took care of this issue. That's my experience with stable languages, even if they aren't particularly mainstream (say, Lua).
>
> Two years later I see this issue is still lingering. My perception is that unless I nag someone or send a fix myself no one will take care of it anytime soon. I guess they just have a huge pile of more important stuff, which is fair.
>
> But, 1) how long do you perceive it will take until more pressing matters delay fixing these kinds of bugs? I don't know if 20 bug fixes a month is enough or not to have DMD v1 rock solid in the next 5 years. Are most of the fixes for new bug reports? Is the list of old bugs being cleaned at a good rate? My perception, I said, was that the rate was a bit disapointing (compared with my experience using other language implementations)
>
> 2) Even if most bug fixes are common to D1 and D2, isn't it still true that if D2 is being discussed, elaborated, documented and implemented, most of those activities do not fix bugs and take time away from making D1 / DMD v1 stable and with few bugs?
>
> Some say "send a patch". I'll try, when that is possible. But I can't send a patch for every bug I find in my spreadsheet software, browser, programming language, IM client, etc. That means that much of the software I use I have to accept it as is. That applies to everyone which uses a large amount of software and is not a programming demigod.
>

I think this is pretty spot on. The point is not that D1 isn't getting bugfixes, it's which bugs are actually fixed. I realise I've done my part of the whining now and in the past, something I'm going to try and change (by fixing bugs myself and sending patches), but ...

I don't know anyone who tried out D seriously who haven't found some near-deal-breaking bug (most of the time already reported), which requires them to implement workarounds that often make some otherwise neat (and according to spec, value) design impossible.

It's a huge demotivator.

-Tomas

P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect.
May 12, 2009
Luís Marques wrote:
> Two years ago, I tried to use a particular construct and DMD incorrectly detected that a statement was not reachable [1]. OK, D1 had been frozen earlier that year, so I thought it would be only a matter of time until the higher priority stuff had been taken care of and someone took care of this issue. That's my experience with stable languages, even if they aren't particularly mainstream (say, Lua).

I forgot the reference (even if, as I said, the bug itself is not very important):

[1] http://d.puremagic.com/issues/show_bug.cgi?id=1115

(I later read a previous thread that talked about the compiler being brittle when it comes to the order of defining thing. I guess that might explain an even older bug I had posted? http://d.puremagic.com/issues/show_bug.cgi?id=792 )
May 12, 2009
On Tue, May 12, 2009 at 8:26 AM, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:

> P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect.

I know.  How many months has bug 314* had the most votes?  And 313 while we're at it.  Importing has been broken for years and instead D2 is getting thread-local variables.  It seems like a gross misdirection of effort.

*http://d.puremagic.com/issues/show_bug.cgi?id=314
May 12, 2009
On Tue, May 12, 2009 at 2:52 PM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
> On Tue, May 12, 2009 at 8:26 AM, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:
>
>> P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect.
>
> I know.  How many months has bug 314* had the most votes?  And 313 while we're at it.  Importing has been broken for years and instead D2 is getting thread-local variables.  It seems like a gross misdirection of effort.
>
> *http://d.puremagic.com/issues/show_bug.cgi?id=314
>

Especially since Christian's patch has been in there for over a year - almost as long as it has  been applied to LDC, where it still hasn't caused a false positive, only caught bugs!
May 12, 2009
Andrei Alexandrescu, el 11 de mayo a las 17:27 me escribiste:
> Walter Bright wrote:
> >Georg Wrede wrote:
> >> From a (go ahead, call it "shrewd" and "marketing liar", I won't mind)
> >>perspective, _the_ newsgroup should be called D and it should contain D1 discussions. And then there should be a less conspicuous NG called "future releases discussions", which would be D2.
> >Sounds like a good idea.
> 
> I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell

This is because D1 is frozen. If there would be a D1.1, D1.2, etc. series, my guess is people would be interested in debating about it. But there is not much to debate about D1 right now, unfortunately.

> people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.

A D1 NG will be a bug-reporting NG by definition because right now D1 is not allowed to evolve. But I think it could be of help for people to better understand that D2 is in development. Adding a more visible indication that D2 is in development in the website would be helpful too (right now the only place I see something about it is in the download page, where it says D2 is alpha, but I you go to the homepage and jump into the documentation, you never get a hint that D2 is experimental).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12, 2009
Georg Wrede, el 12 de mayo a las 06:06 me escribiste:
> Andrei Alexandrescu wrote:
> >Walter Bright wrote:
> >>Georg Wrede wrote:
> >>> From a (go ahead, call it "shrewd" and "marketing liar", I won't mind)
> >>>perspective, _the_ newsgroup should be called D and it should contain D1 discussions. And then there should be a less conspicuous NG called "future releases discussions", which would be D2.
> >>
> >>Sounds like a good idea.
> >I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.
> 
> We could rename D.learn to D and D to D.future-issues.
> 
> Then the two newsgroups would be /appropriately seeded/.

Other (mostly open source) projects tend to use -users and -devel. I guess d-users and d-devel could be used in this case too.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12, 2009
grauzone, el 12 de mayo a las 02:24 me escribiste:
> >>The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed.
> >Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.
> 
> That's mainly because the language was designed by a committee, and not by a compiler author and his followers, isn't it? But you have full control about the language specification. If there are D1 features you're not going to implement, they simply should be removed from the language specification.
> 
> >>Unless of course, D1 is just a prototype for D2 and will thus be discarded the instant that D2 is released.
> >>
> >>What are the support plans for D1 after D2 is released? (I consider current D2 releases as beta editions at best).
> >D1 will continue to be supported as long as there is a significant
> >userbase for it. I've said this many times.  I also fail to understand
> >this perception that D1 is abandoned. Every month an update is released
> >for it that fixes a load of problems. D1 has led the way in ports to
> >other platforms.  What isn't being done with D1 is adding a boatload of
> >new features - because that would destroy any pretense of it being
> >a stable release.
> 
> That's because we don't really know what we want. You gave us D1, but it turns out it's not really what we expected it to be.
> 
> On one side, D1 users want a stable language. That means they don't want to update their code with each compiler release. I think D1 reached this goal. Or, at least it's getting better.
> 
> On the other hand, we don't want to rely on a dead end. We don't want to put up with some trivial issues, that were solved in D2, but will stay in D1 forever.  For example, D1 will never be able to support proper serialization, just because it lacks __traits(). That specific thing would (probably) be easy to port back to D1, and it wouldn't break any existing code.
> 
> I know, you're saying introducing new features goes against stability. But it makes D1 frustrating to use. Everyone feels it's a dead end, and that you shouldn't rely on it. In the end, it might be rock-stable, but nobody wants to use it. Because it will still have some problems, which were solved in D2. D1 will simply vanish in some time.
> 
> Now you could say, "If you want new features, use D2. If you want something stable, use D1. But the gap is simply too big: do you stick with the dead end D1, or with the heavily changing D2?
> 
> The worst thing is, you can't really interface between D1 and D2. So you can't use it, if you're using the wrong D version. Or the library tries to work under both D versions, which makes maintenance harder and bloats up the code. This just causes endless pain.

This is exactly my feeling.

> I propose the following:
> 
> Make D1 open for new features again. As soon as backward compatible features get mature and stable enough in D2, add them to D1 too. To prevent regressions, use the test suite. A new version of the compiler will only be released, if the test suite doesn't report any new regressions.

My suggestion is to accumulate some new features in a new "minor" D1 version, like D1.1, release some betas, and release a D1.1 stable. D1.1 should no receive new features by then, but D1.2 should be started receiving new features. Python works this way, and is a very stable *AND* evolving language. Something that apparently Andrei and Walter think it's not possible to have.

> D2 will be bleeding edge. It will not need to care about _any_ breakages new versions might introduce. Right now, this isn't really possible, because there are people using D2 for "useful" stuff (instead of using D1). With the change, D2 would be a truly experimental testbed, and not the pseudo-stable "next generation D" it is today.
> 
> From time to time, allow breaking changes to D1. It isn't really worth to maintain ancient versions of the compiler, like D1 will be if D3 is out. If someone doesn't want to deal with the breakages, he has to use an old compiler version. A steady transition in small increments is probably still better than requiring a user to do a D1 -> D2 sized switch all some years. While the former may require annoying but trivial fixes to the source code, the latter will always be a nightmare.

That's exactly what I've suggested some time ago, I even started a Wiki page for this with a proposed roadmap: http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal

> But I don't really know what to do with breaking changes, that are just too big.  Like const or the new threading model.

I think that should be kept as D2. Because programs needs a major rewrite to be ported to D2, not just some cosmetic name changes (caused by a class rename or a new keyword that you used as a variable name).

> Everyone, you just wasted your time reading this posting.

Not the first time, not the last time... =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12, 2009
Luís Marques wrote:
> (I later read a previous thread that talked about the compiler being brittle when it comes to the order of defining thing. I guess that might explain an even older bug I had posted? http://d.puremagic.com/issues/show_bug.cgi?id=792 )

This one seems OK with dmd 1.042.