Luís Marques wrote:
> When D1 was declared finished I thought it meant it would progress to a stable state, with nearly all non-minor problems fixed and a large set of companion libraries. I'm afraid I don't see that happening at an animating rate.

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.

dsimcha wrote:
> == Quote from Georg Wrede (georg.wrede@iki.fi)'s article
>> Luís Marques wrote:
>>> I guess that's the point. Who currently thinks that D1 is
>>> production-ready, or is consistently getting there, and how long till it
>>> gets there?
>> Already *before* D1 I wrote a non-trivial application, that is still
>> used in the industry even as we speak.  I wrote it in straight, honest,
>> clean code, and had no problems. It runs two simultaneous tasks,
>> controls industry processing hardware through the parallell port, has a
>> command line language of its own, and it shows parameters of the process
>> on the screen in real time, using graphs and colors. And it writes logs
>> and output files as needed, at the same time.
>> D1 is production ready, IMHO, now. But for such a question, you should
>> define what production-ready means to you.
>> If it means having all GUI programming environments, comprehensive
>> libraries, etc., then even D2 won't get you there.
>> Why? That's because the day D2 is "released", this newsgroup will start
>> developing D3, and from that day on everyone will whine about all
>> attention going to D3. And all kids writing libraries and porting stuff,
>> obviously have to use the lastest version of D, or else their friends
>> will call them wussies.
> 
> One thing that would help is a roadmap of non-trivial breaking changes for D3
> if/when it is started.  By non-trivial, I mean breaking changes that require
> design changes rather than just mechanical things like search/replace.  That way,
> D2 code could be designed with the possibility of eventually porting to D3 in the
> back of the developer's mind rather than being caught completely off guard.

That day, there will not be a single person on Earth who knows such changes. Just like when we started on D2, nobody could have had any notion of how D2 looks today. And we still have an unpredictable amount of changes ahead of us in D2. For example, who can predict if Andrei or somebody else writes a post here that turns half of D2 on its head, and then we postpone everything to get that done. It's happened before, you know.

Georg Wrede wrote:
> That day, there will not be a single person on Earth who knows such changes. Just like when we started on D2, nobody could have had any notion of how D2 looks today. And we still have an unpredictable amount of changes ahead of us in D2. For example, who can predict if Andrei or somebody else writes a post here that turns half of D2 on its head, and then we postpone everything to get that done. It's happened before, you know.

I don't know of any language revision project that wound up where they said they were going at the outset.

On Mon, 11 May 2009 14:43:58 -0700, Walter Bright wrote:

> Georg Wrede wrote:
>> That day, there will not be a single person on Earth who knows such changes. Just like when we started on D2, nobody could have had any notion of how D2 looks today. And we still have an unpredictable amount of changes ahead of us in D2. For example, who can predict if Andrei or somebody else writes a post here that turns half of D2 on its head, and then we postpone everything to get that done. It's happened before, you know.
> 
> I don't know of any language revision project that wound up where they said they were going at the outset.

LOL,  I can attest to that!

The road trip that has been the next version of Euphoria has taken a few sudden and unexpected turns, plus a couple of dead-ends. Even now as we are about to release the first beta edition, we are finding that certain aspects might need a total redesign - yuck. Thankfully, releasing a series of alpha editions has enabled the user community to generate great feedback that has guided the road trip (including telling us that we went the wrong way occasionally).

D1 is not complete. That has nothing to do with the bugs it still contains. It is not complete because there is documented functionality for which no implementation has yet been attempted. This assumes that the documentation is complete and accurate.

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.

Getting D1 stable can be a focus once D1 is complete.

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

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Derek Parnell wrote:
> D1 is not complete. That has nothing to do with the bugs it still contains.
> It is not complete because there is documented functionality for which no
> implementation has yet been attempted. This assumes that the documentation
> is complete and accurate.
> 
> 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.


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

Derek Parnell wrote:
> 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.

Well thank you General :o).

Derek, I have all respect for you and your contributions to D. The
response below does not have the slightest intent to pick on you but to
rein in an unhelpful pattern in this group.

I invite you to see the paragraph quoted above through a different pair of eyes - the eyes of someone with a different vision of what should be done for D, and also (most importantly) who believes in it strongly enough to invest their own non-existing free time  in effecting that vision.

I confess that this couch quarterbacking is mightily frustrating for both Walter and myself. All the pieces are there for anyone with a vision to make it happen. I understand you wanted to share your opinion on what would be best for the future of D, and that's laudable in and by itself, but such opinions have lately become a choir of whines fulfilling a "if I want something from D, and I expect Walter to do it" pattern. We need the exact opposite - if you care, what can *you* do to make D better? D needs action and leadership.

And why is D1 not finished? Most "finished" languages have implementation insufficiencies. I've read a couple of days ago that D1 is unfinished (and unusable by implication) because contracts aren't inherited. If I were Walter, that would be the exact kind of claim that causes high blood pressure. This is ridiculous! Is *that* the feature that the building of a system hinges on? Is that really what's stopping you? Then go back and use contracts in C++, Java, or C#. My guess is, if anyone is whining that D1 is unusable because it doesn't have contract inheritance, tomorrow (should contract inheritance be fixed) they'll whine that it doesn't have named arguments, template virtuals, or a gorram cherry on top. Sheesh.

And finally - now that I got on to ranting - I won't out the innocent, but I find it tragicomic that one poster found out fit to rant at length about the need for stability, to then - within the space of 48 hours - to post requests for borderline uninteresting but mightily breaking changes to D1.

I guess I'm done with my Spring rant :o).


Andrei

Walter Bright wrote:
> 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.

Because this news group's name is not D2. Folks come here, and see no mention of D1 for weeks. (Other than people whining about "no support, D1 abandoned", etc.) All they see is (to a D newcomer, anyway) incomprehensible ruminations on esoterics. But they believe this is /the thing/, since nobody warned them that this is (in reality) a future versions newsgroup.

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.

This change looks too trivial to make a difference, but that's exactly why I have to bring it up. (Why do you think M$ pays mega$ for some consultancy to invent a name for the next Windows version? It's the subconscious things in customers' brains they f**k with. And they're doing a good job at it.) Old D guys are too used to the current naming to appreciate the difference.

> 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 as it should be (given our limited resources).

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.

On Mon, 11 May 2009 12:11:53 -0700, Walter Bright wrote:

> Luís Marques wrote:
>> When D1 was declared finished I thought it meant it would progress to a stable state, with nearly all non-minor problems fixed and a large set of companion libraries. I'm afraid I don't see that happening at an animating rate.
> 
> 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 agree that D1 is getting its fair share of attention, and I support the earlier post that suggested getting in there and making contributions yourself if you don't like the rate of progress in your personal area of interest.

D (especially D2 ;-) ) is far and away the best language I have ever worked with already, and I think the team needs to be congratulated for its efforts. I'm embarrassed that I can't contribute more because of other commitments, but when I do, it is done as constructively as possible.

Walter Bright wrote:
> Derek Parnell wrote:
>> D1 is not complete. That has nothing to do with the bugs it still contains.
>> It is not complete because there is documented functionality for which no
>> implementation has yet been attempted. This assumes that the documentation
>> is complete and accurate.
>>
>> 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.

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.

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.

But I don't really know what to do with breaking changes, that are just too big. Like const or the new threading model. Everyone, you just wasted your time reading this posting.