All this D2 work seems to have detracted from the task of finishing off D1.

There are 15 issues nominated as d1.0blocker, of which 7* are still outstanding, including two trackers having 39 dependencies between them.

* Well, 8 if you include 691, fixed only for D2.

http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker

While none of these nominations were ever answered, I think most would agree that being finished means, at the least:

(a) having a spec that the public agrees to be complete and consistent
(b) all language features implemented
(c) all of the most serious known bugs and most of the others fixed

677 and 690 are shortcomings in department (a). (OK, 690 seems to be almost fixed now, but I'm not sure.)  302 is a failure under (b).  While it's otherwise hard to lay hands on anything particular as why (c) is yet to be achieved, that just over 2/3 of 340's dependencies are still open at least says something.

This leaves 317 and 342, which are filed as enhancement requests, but which people felt important enough that they ought to be in the initial D1 distribution.  342 is straightforward and, while 317 is a much bigger task, at least it has progressed (albeit slowly).

But generally, it's about time D1 got a move on....


I'm made to wonder whether, if 1.0 had been held back until it could be a practical rather than just symbolic milestone, it would be at both by now.

I've just thought, given this brief inconclusive discussion
http://tinyurl.com/qayz9w
...when we reach this practical milestone, maybe we could call it D 1.1?

Stewart.

Stewart Gordon wrote:
> All this D2 work seems to have detracted from the task of finishing off D1.
> 
> There are 15 issues nominated as d1.0blocker, of which 7* are still outstanding, including two trackers having 39 dependencies between them.
> 
> * Well, 8 if you include 691, fixed only for D2.
> 
> http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker 
> 
> 
> While none of these nominations were ever answered, I think most would agree that being finished means, at the least:
> 
> (a) having a spec that the public agrees to be complete and consistent
> (b) all language features implemented
> (c) all of the most serious known bugs and most of the others fixed
> 
> 677 and 690 are shortcomings in department (a). (OK, 690 seems to be almost fixed now, but I'm not sure.)  302 is a failure under (b).  While it's otherwise hard to lay hands on anything particular as why (c) is yet to be achieved, that just over 2/3 of 340's dependencies are still open at least says something.
> 
> This leaves 317 and 342, which are filed as enhancement requests, but which people felt important enough that they ought to be in the initial D1 distribution.  342 is straightforward and, while 317 is a much bigger task, at least it has progressed (albeit slowly).
> 
> But generally, it's about time D1 got a move on....
> 
> 
> I'm made to wonder whether, if 1.0 had been held back until it could be a practical rather than just symbolic milestone, it would be at both by now.
> 
> I've just thought, given this brief inconclusive discussion
> http://tinyurl.com/qayz9w
> ...when we reach this practical milestone, maybe we could call it D 1.1?
> 
> Stewart.

I think the major problem with this is that D2 has the same codebase as D1, so D2 will inherit most of it's bug, like forward references.

Anyone wants to start an open source project to make a new front-end for D1? :)

== Quote from Ary Borenszweig (ary@esperanto.org.ar)'s article
> Stewart Gordon wrote:
> > All this D2 work seems to have detracted from the task of finishing off D1.
> >
> > There are 15 issues nominated as d1.0blocker, of which 7* are still outstanding, including two trackers having 39 dependencies between them.
> >
> > * Well, 8 if you include 691, fixed only for D2.
> >
> >
http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker
> >
> >
> > While none of these nominations were ever answered, I think most would agree that being finished means, at the least:
> >
> > (a) having a spec that the public agrees to be complete and consistent
> > (b) all language features implemented
> > (c) all of the most serious known bugs and most of the others fixed
> >
> > 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
> > almost fixed now, but I'm not sure.)  302 is a failure under (b).  While
> > it's otherwise hard to lay hands on anything particular as why (c) is
> > yet to be achieved, that just over 2/3 of 340's dependencies are still
> > open at least says something.
> >
> > This leaves 317 and 342, which are filed as enhancement requests, but which people felt important enough that they ought to be in the initial D1 distribution.  342 is straightforward and, while 317 is a much bigger task, at least it has progressed (albeit slowly).
> >
> > But generally, it's about time D1 got a move on....
> >
> >
> > I'm made to wonder whether, if 1.0 had been held back until it could be a practical rather than just symbolic milestone, it would be at both by now.
> >
> > I've just thought, given this brief inconclusive discussion
> > http://tinyurl.com/qayz9w
> > ...when we reach this practical milestone, maybe we could call it D 1.1?
> >
> > Stewart.
> I think the major problem with this is that D2 has the same codebase as D1, so D2 will inherit most of it's bug, like forward references. Anyone wants to start an open source project to make a new front-end for D1? :)

This one is interesting and looks reasonably active:: http://code.google.com/p/dil/

It's a D1 front end written in D, and looks reasonably active.  It also solves another problem:  Although it's not a particularly urgent thing, eventually D compilers should be written in D.  First, it would be one less things for skeptics to complain about.

Secondly, I'm not sure if anyone else shares this experience, but I hack Phobos all the time, but don't touch DMD.  Part of the reason is that DMD is in C++, which I don't know nearly as well as D and find much less pleasant to work with. If DMD were written in D I'd be more inclined to hack around with it.  Of course, the other reason is because, with DMD you have to be familiar with large portions of the codebase to do simple things, whereas in Phobos, you just need to know about the part you want to mess with.

dsimcha wrote:
> == Quote from Ary Borenszweig (ary@esperanto.org.ar)'s article
>> Stewart Gordon wrote:
>>> All this D2 work seems to have detracted from the task of finishing off D1.
>>>
>>> There are 15 issues nominated as d1.0blocker, of which 7* are still
>>> outstanding, including two trackers having 39 dependencies between them.
>>>
>>> * Well, 8 if you include 691, fixed only for D2.
>>>
>>>
> http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker
>>>
>>> While none of these nominations were ever answered, I think most would
>>> agree that being finished means, at the least:
>>>
>>> (a) having a spec that the public agrees to be complete and consistent
>>> (b) all language features implemented
>>> (c) all of the most serious known bugs and most of the others fixed
>>>
>>> 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
>>> almost fixed now, but I'm not sure.)  302 is a failure under (b).  While
>>> it's otherwise hard to lay hands on anything particular as why (c) is
>>> yet to be achieved, that just over 2/3 of 340's dependencies are still
>>> open at least says something.
>>>
>>> This leaves 317 and 342, which are filed as enhancement requests, but
>>> which people felt important enough that they ought to be in the initial
>>> D1 distribution.  342 is straightforward and, while 317 is a much bigger
>>> task, at least it has progressed (albeit slowly).
>>>
>>> But generally, it's about time D1 got a move on....
>>>
>>>
>>> I'm made to wonder whether, if 1.0 had been held back until it could be
>>> a practical rather than just symbolic milestone, it would be at both by
>>> now.
>>>
>>> I've just thought, given this brief inconclusive discussion
>>> http://tinyurl.com/qayz9w
>>> ...when we reach this practical milestone, maybe we could call it D 1.1?
>>>
>>> Stewart.
>> I think the major problem with this is that D2 has the same codebase as
>> D1, so D2 will inherit most of it's bug, like forward references.
>> Anyone wants to start an open source project to make a new front-end for
>> D1? :)
> 
> This one is interesting and looks reasonably active:: http://code.google.com/p/dil/
> 
> It's a D1 front end written in D, and looks reasonably active.  It also solves
> another problem:  Although it's not a particularly urgent thing, eventually D
> compilers should be written in D.  First, it would be one less things for skeptics
> to complain about.

Cool! I thought all of the D compilers were using DMD's front-end. I'll take a look at it and try to help.

Ary Borenszweig wrote:
<snip excessive quote>
> I think the major problem with this is that D2 has the same codebase as D1, so D2 will inherit most of it's bug, like forward references.
<snip>

Why's that a problem?

AISI it's a benefit - DMD2 inherits DMD1's bug fixes, and to some degree vice versa.

Stewart.

Stewart Gordon wrote:
> All this D2 work seems to have detracted from the task of finishing off D1.

As someone who as tried to use D in non-hobby projects, I want to add that I reasonably agree with the sentiment.

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.

My feeling is that D1 is being finished at a best-effort rate, with D2 taking much of the time. That leaves D1 as still being a somewhat risky, unpractical proposition for many "real-world" project (and D2 as the admittedly moving-target). This will always be true for a non-mainstream language, but it doesn't have to be to this extent. Good strides have been made with Learn to Tango with D, the Mac and BSD port, etc. But, for me, it would be more important to make sure that what currently exists is production-ready.

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?

Best luck for the trip!

Regards,
Luís

Ary Borenszweig wrote:
> dsimcha wrote:
>> == Quote from Ary Borenszweig (ary@esperanto.org.ar)'s article
>>> Stewart Gordon wrote:
>>>> All this D2 work seems to have detracted from the task of finishing off D1.
>>>>
>>>> There are 15 issues nominated as d1.0blocker, of which 7* are still
>>>> outstanding, including two trackers having 39 dependencies between them.
>>>>
>>>> * Well, 8 if you include 691, fixed only for D2.
>>>>
>>>>
>> http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker 
>>
>>>>
>>>> While none of these nominations were ever answered, I think most would
>>>> agree that being finished means, at the least:
>>>>
>>>> (a) having a spec that the public agrees to be complete and consistent
>>>> (b) all language features implemented
>>>> (c) all of the most serious known bugs and most of the others fixed
>>>>
>>>> 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
>>>> almost fixed now, but I'm not sure.)  302 is a failure under (b).  While
>>>> it's otherwise hard to lay hands on anything particular as why (c) is
>>>> yet to be achieved, that just over 2/3 of 340's dependencies are still
>>>> open at least says something.
>>>>
>>>> This leaves 317 and 342, which are filed as enhancement requests, but
>>>> which people felt important enough that they ought to be in the initial
>>>> D1 distribution.  342 is straightforward and, while 317 is a much bigger
>>>> task, at least it has progressed (albeit slowly).
>>>>
>>>> But generally, it's about time D1 got a move on....
>>>>
>>>>
>>>> I'm made to wonder whether, if 1.0 had been held back until it could be
>>>> a practical rather than just symbolic milestone, it would be at both by
>>>> now.
>>>>
>>>> I've just thought, given this brief inconclusive discussion
>>>> http://tinyurl.com/qayz9w
>>>> ...when we reach this practical milestone, maybe we could call it D 1.1?
>>>>
>>>> Stewart.
>>> I think the major problem with this is that D2 has the same codebase as
>>> D1, so D2 will inherit most of it's bug, like forward references.
>>> Anyone wants to start an open source project to make a new front-end for
>>> D1? :)
>>
>> This one is interesting and looks reasonably active:: http://code.google.com/p/dil/
>>
>> It's a D1 front end written in D, and looks reasonably active.  It also solves
>> another problem:  Although it's not a particularly urgent thing, eventually D
>> compilers should be written in D.  First, it would be one less things for skeptics
>> to complain about.
> 
> Cool! I thought all of the D compilers were using DMD's front-end. I'll take a look at it and try to help.

Just a few notes.
1 - DIL is able to lex and parse (partially) D2
2 - DIL is GPL 3
3 - semantic analysis requires some work
4 - DIL has a couple of very useful extensions, likewise D to XML
5 - compared to the C++ frontend DIL sources are readable and quite easy to extend. (save D to XML library information into Berkeley DB XML/ nice to have IDE feature/, just my opinion)

Björn

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.

Stewart Gordon wrote:
> Ary Borenszweig wrote:
> <snip excessive quote>
>> I think the major problem with this is that D2 has the same codebase as D1, so D2 will inherit most of it's bug, like forward references.
> <snip>
> 
> Why's that a problem?
> 
> AISI it's a benefit - DMD2 inherits DMD1's bug fixes, and to some degree vice versa.
> 
> Stewart.

The problem is that some serious bugs never got fixed, so they'll be as well in D2. Of course that's good *if* they get fixed, but...

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