www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - stability

reply Denton Cockburn <diboss hotmail.com> writes:
Is there a planned stage where D plans to slowdown and focus on cleaning
up outstanding issues and bugs?

There are compiler bugs, issues, and inconsistencies that are brought up
on here regularly.

Is D just going to proceed to 3.0 as soon as 2.0 is done or maybe the
cleanup stage is planned before the end of the 2.0 cycle.

I would just hate to see us having something similar to what's happened
with 1.0, where people are still complaining about issues and
inconsistencies while 2.0 is the focus.
Feb 23 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denton Cockburn wrote:
 Is there a planned stage where D plans to slowdown and focus on cleaning
 up outstanding issues and bugs?
 
 There are compiler bugs, issues, and inconsistencies that are brought up
 on here regularly.
 
 Is D just going to proceed to 3.0 as soon as 2.0 is done or maybe the
 cleanup stage is planned before the end of the 2.0 cycle.
 
 I would just hate to see us having something similar to what's happened
 with 1.0, where people are still complaining about issues and
 inconsistencies while 2.0 is the focus.
D 1.0 regularly gets bug fixes with the focus on improving its stability.
Feb 23 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:

 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
I understand that, but there are still many outstanding bugs in D 1.0. 2.0 now, which is in development, a lot of the changes affect things elsewhere. Are you going to correct all of those side-effects before releasing 2.0? or are they going to be addressed during the development of 3.0? I was reading a thread on reddit a few days ago about issues people have with their favourite language. One of the issues with D was that people were still running into compiler errors and bugs in what is expected to be a systems programming language.
Feb 23 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Denton Cockburn wrote:
 On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:
 
 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
I understand that, but there are still many outstanding bugs in D 1.0. 2.0 now, which is in development, a lot of the changes affect things elsewhere. Are you going to correct all of those side-effects before releasing 2.0? or are they going to be addressed during the development of 3.0? I was reading a thread on reddit a few days ago about issues people have with their favourite language. One of the issues with D was that people were still running into compiler errors and bugs in what is expected to be a systems programming language.
Seems irrelevant to me what kind of language D is. Bugs are bugs and nobody likes 'em. And compiler bugs are especially annoying. Regardless of the language. Doesn't matter if it's a "systems programming language" or a LOGO interpreter. I think Walter is doing a pretty good job of fixing bugs with D1, but still there are a few instances where he has seemed a little too eager to classify a fix as an enhancement, apparently so as to avoid having to port it to D1. It's a balancing act, though. Time spent fixing D1 bugs is time taken away from making D2 ready for prime-time. --bb
Feb 23 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter wrote:

 Denton Cockburn wrote:
 On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:
 
 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
I understand that, but there are still many outstanding bugs in D 1.0. 2.0 now, which is in development, a lot of the changes affect things elsewhere. Are you going to correct all of those side-effects before releasing 2.0? or are they going to be addressed during the development of 3.0? I was reading a thread on reddit a few days ago about issues people have with their favourite language. One of the issues with D was that people were still running into compiler errors and bugs in what is expected to be a systems programming language.
Seems irrelevant to me what kind of language D is. Bugs are bugs and nobody likes 'em. And compiler bugs are especially annoying. Regardless of the language. Doesn't matter if it's a "systems programming language" or a LOGO interpreter. I think Walter is doing a pretty good job of fixing bugs with D1, but still there are a few instances where he has seemed a little too eager to classify a fix as an enhancement, apparently so as to avoid having to port it to D1. It's a balancing act, though. Time spent fixing D1 bugs is time taken away from making D2 ready for prime-time. --bb
Be that as it may, D is the _only_ language where I've hit bugs in the fundamentals a programmer relies on... ...Ok, there was on exception in VC .NET where I had code that did x >> y. x was 32 bit and y could range between 0 and 32. This translated directly into an assembly call to the right shift operation. The tricky thing is that on that processor, the left shift operation only used 5 bits for the shift amount. Values of y were converted to y modulo 32, resulting in x being preserved (instead of being zeroed) when right shifting 32 bits. I can totally understand that issue and wouldn't be surprised to see it pop up in other compilers... I'm not trying to say anything specific, but the issue that people have is legitamite and relatively unique to D. (I'm sure someone can come up with an example from another language)
Feb 23 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:
 Bill Baxter wrote:
 
 Denton Cockburn wrote:
 On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:

 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
I understand that, but there are still many outstanding bugs in D 1.0. 2.0 now, which is in development, a lot of the changes affect things elsewhere. Are you going to correct all of those side-effects before releasing 2.0? or are they going to be addressed during the development of 3.0? I was reading a thread on reddit a few days ago about issues people have with their favourite language. One of the issues with D was that people were still running into compiler errors and bugs in what is expected to be a systems programming language.
Seems irrelevant to me what kind of language D is. Bugs are bugs and nobody likes 'em. And compiler bugs are especially annoying. Regardless of the language. Doesn't matter if it's a "systems programming language" or a LOGO interpreter. I think Walter is doing a pretty good job of fixing bugs with D1, but still there are a few instances where he has seemed a little too eager to classify a fix as an enhancement, apparently so as to avoid having to port it to D1. It's a balancing act, though. Time spent fixing D1 bugs is time taken away from making D2 ready for prime-time. --bb
Be that as it may, D is the _only_ language where I've hit bugs in the fundamentals a programmer relies on... ...Ok, there was on exception in VC .NET where I had code that did x >> y. x was 32 bit and y could range between 0 and 32. This translated directly into an assembly call to the right shift operation. The tricky thing is that on that processor, the left shift operation only used 5 bits for the shift amount. Values of y were converted to y modulo 32, resulting in x being preserved (instead of being zeroed) when right shifting 32 bits. I can totally understand that issue and wouldn't be surprised to see it pop up in other compilers... I'm not trying to say anything specific, but the issue that people have is legitamite and relatively unique to D. (I'm sure someone can come up with an example from another language)
I ran into plenty of bugs in MSVC back on versions 5 and 6. 7 and 8 at last finally seem to have gotten pretty decent. --bb
Feb 23 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:
 I think Walter is doing a pretty good job of fixing bugs with D1, but 
 still there are a few instances where he has seemed a little too eager 
 to classify a fix as an enhancement, apparently so as to avoid having to 
 port it to D1.  It's a balancing act, though.  Time spent fixing D1 bugs 
 is time taken away from making D2 ready for prime-time.
Time spent on D2 features is time taken away from making D1 ready for prime-time. Walter should probably give D1 to the community for maintenance at this point. He just doesn't have the time for both compilers, I think.
Feb 23 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I think Walter is doing a pretty good job of fixing bugs with D1, but 
 still there are a few instances where he has seemed a little too eager 
 to classify a fix as an enhancement, apparently so as to avoid having to 
 port it to D1.
That isn't true at all. "Porting" changes to D1 is trivial, since the code is about 98% common. The problem is there is often not a clear distinction between a bug and an enhancement, and D1 cannot be a stable language if it keeps getting enhancements.
Feb 23 2008
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 23 Feb 2008 21:49:42 -0800, Walter Bright wrote:

 Bill Baxter wrote:
 I think Walter is doing a pretty good job of fixing bugs with D1, but 
 still there are a few instances where he has seemed a little too eager 
 to classify a fix as an enhancement, apparently so as to avoid having to 
 port it to D1.
That isn't true at all. "Porting" changes to D1 is trivial, since the code is about 98% common. The problem is there is often not a clear distinction between a bug and an enhancement, and D1 cannot be a stable language if it keeps getting enhancements.
A bug is where the current behaviour is contrary to the specification. An enhancement is proposed behaviour that is not documented in the specification. The problem we (including Walter) have is that D does not have a specification and therefore there is no method to determine if a given behaviour is by design or a mistake. All we have is "common sense", "that's So I would imagine that before another D compiler is written, a specification is created that forms the benchmark to measure what is a conforming D compiler. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 24 2008
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 24 Feb 2008 19:58:18 +1100, Derek Parnell wrote:

 ... All we have is ...
I'm sorry. That was a gross generalization that was not called for. We also have the current D documentation. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 24 2008
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  So I would imagine that before another D compiler is written, a
  specification is created that forms the benchmark to measure what is a
  conforming D compiler.
Specifications can have bugs in them too. That's why specifications have continual addenda and/or new versions. Without that, conforming implementations would be forced to implement bugs. The /real/ definition of a bug is probably "doesn't do what the designer intended it to do". That's certainly true when /I/ write code - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it to do is comply with a spec, in which case non-compliance is a bug, but other times I'm creating something new, but in either case, a bug is "it doesn't do what I intended". In the case of D, I'm happy that Walter is not constrained to a possibly buggy spec.
Feb 24 2008
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Feb 2008 09:12:18 +0000, Janice Caron wrote:

 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  So I would imagine that before another D compiler is written, a
  specification is created that forms the benchmark to measure what is a
  conforming D compiler.
Specifications can have bugs in them too.
Really?? I'm shocked beyond sarcasm!
 That's why specifications have continual addenda and/or new versions.
Ohhh, I wondered why that happened.
 Without that, conforming implementations would be forced to implement
 bugs.
Well thankfully we have people in this world who are willing to correct mistakes in specifications.
 The /real/ definition of a bug is probably "doesn't do what the
 designer intended it to do". That's certainly true when /I/ write code
 - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it
 to do is comply with a spec, in which case non-compliance is a bug,
 but other times I'm creating something new, but in either case, a bug
 is "it doesn't do what I intended".
 
 In the case of D, I'm happy that Walter is not constrained to a
 possibly buggy spec.
I think that you and I have different experience about what is a specification. To me, a specification is a description of what will be achieved by some system/application, which is agreed upon by the stakeholders of the system. Yes, it likely that it will contain errors, we are human no? Yes, it is likely to be changed over time; to clarify, to remove functionality no longer required, and to add functionality that is now required. All this happens under the watchful eyes of the stakeholders in order to minimize mistakes in the specification. A good piece of software will implement mistakes in the spec. That same softare will also be modified to keep in synchronization with the spec. In my experience, it often happens that mistakes in the spec are discovered by the implementers. In the case of D, I'm not happy that Walter is not constrained to a possibly buggy spec. A specification, with or without bugs, does not cause bug free software. However, how will we know if an application contains bugs if you can't know "what the designer intended it to do" in the first place? The specification is supposed to tell us what the designer wanted. I refuse to believe that Walter could not create a better D compiler if it was known what a D compiler was supposed to do. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 24 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
Feb 24 2008
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
Too vague.
Feb 24 2008
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 24 Feb 2008 21:29:02 +1100, Janice Caron <caron800 googlemail.com>  
wrote:

 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you can't  
 know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
Too glib. Have you actually thought that through? Is each person really expected to ask Walter ad hoc questions about D's design and expect Walter to reply to each one with the answer? That sounds like a waste of manpower and a cause of misunderstandings. If this really is the approach to use, then at least we can use the Wiki to share the results of queries with the rest of the community. I'm sure Walter will love to spend time on that endevour. Maybe that could be the basis of a specification that Walter can approve of. However, I don't think that this will happen nor do I think it is the better way to proceed. -- Derek
Feb 24 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  Have you actually thought that through? Is each person really expected to
  ask Walter ad hoc questions about D's design and expect Walter to reply to
  each one with the answer?
I don't expect the creator of any project to answer individual emails, but they can, and do, set up newsgroups, forums and mailing lists, of which this is one example, as well as official documentation. That seems more than adequate to me. It seems to me that the whole basis for that question, and indeed, this entire thread, is the underlying assumption that we don't trust Walter with his own creation. I do. I believe that the creative process is the same, whether one is writing a song, a book, or a programming language; whether one is making a movie or a compiler. And these things are /always/ better when designed by a single person with a vision than by a committee. Therefore, I insist that D is better precisely /because/ Walter has his creative freedom. Sorry, but that's just how I look at things.
Feb 24 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Janice Caron wrote:

 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  Have you actually thought that through? Is each person really expected
  to ask Walter ad hoc questions about D's design and expect Walter to
  reply to each one with the answer?
I don't expect the creator of any project to answer individual emails, but they can, and do, set up newsgroups, forums and mailing lists, of which this is one example, as well as official documentation. That seems more than adequate to me. It seems to me that the whole basis for that question, and indeed, this entire thread, is the underlying assumption that we don't trust Walter with his own creation. I do. I believe that the creative process is the same, whether one is writing a song, a book, or a programming language; whether one is making a movie or a compiler. And these things are /always/ better when designed by a single person with a vision than by a committee. Therefore, I insist that D is better precisely /because/ Walter has his creative freedom.
D as a language is quite possibly better due to this, but the compiler situation is definately worse than it could be because of the lack of a proper spec. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Feb 24 2008
prev sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Sun, 24 Feb 2008 12:27:53 +0000, Janice Caron wrote:

 It seems to me that the whole basis for that question, and indeed,
 this entire thread, is the underlying assumption that we don't trust
 Walter with his own creation. I do.
Umm, that's one hell of an assumption. I love D, and I have tremendous admiration for Walter's work. I'm just wanting the next stable version of the compiler to be that, stable. There should not be major issues (unlike minor bugs) with the compiler. I do all my research work using D now, so like the rest of the community, I want D to be as great as it can be (and I already find it much better than C++, its primary competitor).
Feb 24 2008
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 24 Feb 2008 21:29:02 +1100, Janice Caron <caron800 googlemail.com>  
wrote:

 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you can't  
 know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
Too glib. Have you actually thought that through? Is each person really expected to ask Walter ad hoc questions about D's design and expect Walter to reply to each one with the answer? That sounds like a waste of manpower and a cause of misunderstandings. If this really is the approach to use, then at least we can use the Wiki to share the results of queries with the rest of the community. I'm sure Walter will love to spend time on that endevour. Maybe that could be the basis of a specification that Walter can approve of. However, I don't think that this will happen nor do I think it is the better way to proceed. -- Derek
Feb 24 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption. --bb
Feb 24 2008
next sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Bill Baxter wrote:
 Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you 
 can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption.
Python has a Python Reference Manual as part of eeach release. AFAIK that is the specification for end-users, and if there is something in the Python language which does not confrom to that reference manual it is considered a bug when reported to Python. The reference manual is firmly embedded in the documentation for each release and the documentation comes fully formed as part of an installation of that release. This is at what D must aim if it intends to become a language to be used by the end-user programmer. Without a specification for each language release a computer language just ends up being a small club of those in the know rather than a useful product for end-users to create modules and applications.
Feb 24 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Edward Diener wrote:
 Bill Baxter wrote:
 Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you 
 can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption.
Python has a Python Reference Manual as part of eeach release. AFAIK that is the specification for end-users, and if there is something in the Python language which does not confrom to that reference manual it is considered a bug when reported to Python. The reference manual is firmly embedded in the documentation for each release and the documentation comes fully formed as part of an installation of that release. This is at what D must aim if it intends to become a language to be used by the end-user programmer.
That sounds exactly like the situation with D currently. The current version of the spec/documentation web pages ships with every compiler release. The Python Reference Manual doesn't look to be much different in level of detail from the D spec web pages. --bb
Feb 24 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Bill Baxter wrote:
 Edward Diener wrote:
 Bill Baxter wrote:
 Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you 
 can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption.
Python has a Python Reference Manual as part of eeach release. AFAIK that is the specification for end-users, and if there is something in the Python language which does not confrom to that reference manual it is considered a bug when reported to Python. The reference manual is firmly embedded in the documentation for each release and the documentation comes fully formed as part of an installation of that release. This is at what D must aim if it intends to become a language to be used by the end-user programmer.
That sounds exactly like the situation with D currently. The current version of the spec/documentation web pages ships with every compiler release. The Python Reference Manual doesn't look to be much different in level of detail from the D spec web pages.
I wish it were true that the D documentation is at the level of detail for D that the Python documentation is for Python. But reality intrudes and in numerous places the D documentation is either incomplete, or the links which one supposes to exist are not there, and one has to ask on this forum where the information exists. There is even TBD still on a number of topics of the D 1.0 documentation although I am not sure if this exists for the D 2.0 online documentation. Finally one should be able to download all documentation as a help and/or PDF file to one's local computer and this is clearly not the case for D. I will reiterate that it is supremely important for D, with each official release, to provide a complete set of language/library documentation for the end-user. Without that D will remain a niche language, despite the innovations which Mr. Bright has added to his C++ language base and the goodwill of those who support his language and his ideas.
Feb 24 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Edward Diener wrote:
 Bill Baxter wrote:
 Edward Diener wrote:
 Bill Baxter wrote:
 Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  However, how will we know if an application contains bugs if you 
 can't know
  "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption.
Python has a Python Reference Manual as part of eeach release. AFAIK that is the specification for end-users, and if there is something in the Python language which does not confrom to that reference manual it is considered a bug when reported to Python. The reference manual is firmly embedded in the documentation for each release and the documentation comes fully formed as part of an installation of that release. This is at what D must aim if it intends to become a language to be used by the end-user programmer.
That sounds exactly like the situation with D currently. The current version of the spec/documentation web pages ships with every compiler release. The Python Reference Manual doesn't look to be much different in level of detail from the D spec web pages.
I wish it were true that the D documentation is at the level of detail for D that the Python documentation is for Python. But reality intrudes and in numerous places the D documentation is either incomplete, or the links which one supposes to exist are not there, and one has to ask on this forum where the information exists. There is even TBD still on a number of topics of the D 1.0 documentation although I am not sure if this exists for the D 2.0 online documentation. Finally one should be able to download all documentation as a help and/or PDF file to one's local computer and this is clearly not the case for D.
My assessment was not based on a detailed comparison of course. But from a distance they sure look comparable. I think only someone who has spent a lot of time looking at both could really say which one is more complete. If you have done that for Python, then I'll take your word for it. I've never had much need to go to the Python reference manual. The library reference has always been enough for my uses. But I will say that the Python library reference leaves a lot to be desired in places. But anyway, if all you're arguing for is a level of detail on par with the Python RefMan, I'd say there's not too far to go.
 I will reiterate that it is supremely important for D, with each 
 official release, to provide a complete set of language/library 
 documentation for the end-user. Without that D will remain a niche 
 language, despite the innovations which Mr. Bright has added to his C++ 
 language base and the goodwill of those who support his language and his 
 ideas.
It pretty much serves my needs as it is. Yes there's an occasional need to ask for clarification and/or filing bug reports to to make something vague more clear. But it hardly prevents my day-to-day usage of D. I fail to see how a more detailed spec causes the hordes to appear at D's door. Can you flesh out that line of reasoning a bit? --bb
Feb 24 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Edward Diener wrote:
 Without a specification for each language release a computer language 
 just ends up being a small club of those in the know rather than a 
 useful product for end-users to create modules and applications.
Nearly all major languages had detailed and accurate specifications produced for them only *after* they became widely adopted. Languages that start out with a detailed and accurate specification tend to be failures. Some reasons: 1) It's exceedingly hard work to do a spec. That makes it not worthwhile unless there are very large forces to make it worthwhile (like a huge user base). 2) It takes a long time to produce a spec, so long that the language may become obsolete before it has a chance (cue Ada). 3) Producing a spec in advance means you've frozen in place design decisions that may turn out to be horribly, horribly wrong, but yet the language is stuck with them (cue exported templates).
Feb 29 2008
parent Derek Parnell <derek psych.ward> writes:
On Fri, 29 Feb 2008 14:24:44 -0800, Walter Bright wrote:

 Edward Diener wrote:
 Without a specification for each language release a computer language 
 just ends up being a small club of those in the know rather than a 
 useful product for end-users to create modules and applications.
Nearly all major languages had detailed and accurate specifications produced for them only *after* they became widely adopted. Languages that start out with a detailed and accurate specification tend to be failures. Some reasons: 1) It's exceedingly hard work to do a spec. That makes it not worthwhile unless there are very large forces to make it worthwhile (like a huge user base). 2) It takes a long time to produce a spec, so long that the language may become obsolete before it has a chance (cue Ada). 3) Producing a spec in advance means you've frozen in place design decisions that may turn out to be horribly, horribly wrong, but yet the language is stuck with them (cue exported templates).
This position applies if one assumes that a specification is not developed in conjunction with 'prototyping' and peer reviews. It also assumes that a specification must be 'final' before development can commence. That is a recipe for disaster. Another model is where the specification is developed iteratively, a 'step' in front of code development. Feedback from the code and the applications practical usage goes back into the next iteration of the specification. In the initial stages the specification can be in wild oscillation as ideas are attempted then modified or rejected. However, what soon occurs is a specification that is acceptable and only subject to incremental changes that tend to be non-breaking ones. And in the meantime, the application development is nearly always aligned to the written specification, which makes bug determination much easier to do. One of the reasons we have specifications is because it fits the needs of a difference audience than the actual code does. For example, most formal test cases are developed from specifications and not by reading the code. Test case developed by reading the code tend to test what the code does rather than test what the code is supposed to do. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 29 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el 25 de febrero a las 04:09 me escribiste:
 Janice Caron wrote:
On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
 However, how will we know if an application contains bugs if you can't know
 "what the designer intended it to do" in the first place?
You could ask. Too easy?
In fact that's exactly what happens. People either ask here or they file a bug report stating "this looks like a bug" and Walter responds "no that's behaving according to design". I'm not sure why some folks are so adamant about the spec thing. Perl, Python, and Ruby are quite popular, but none of them has a detailed spec as far as I know. And if they do, I'd bet that came about /after/ they became popular. So lack of a detailed spec did not prevent widespread adoption.
I think languages will well defined specifications are the only ones with several compilers/interpreters. Python has a well defined specification[1] (for a long, long time, AFAIK), and AFAIK again, is the only one that has several interpreters[2]. And there is a *huge* difference with D in those languages (and no, it's not that they are interpreted): their reference implementation are *open source* (as their development process). Other interpreters/compilers don't have to wait to a new reference compiler/interpreted release to see what's new and analize how to change from it, all is openly discussed and you can see the reference implementation evolve in small deltas via a SCM to keep up. That's why I think that putting the frontend in a public SCM is key for D, and I think to have a complete opensource reference implementation will be key too in the future. [1] http://docs.python.org/ref/ref.html [2] http://docs.python.org/ref/implementations.html (and they are more in progress, like http://www.philhassey.com/blog/category/tinypy/) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- He used to do surgery On girls in the eighties But gravity always wins
Feb 25 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 I think languages will well defined specifications are the only ones with
 several compilers/interpreters.
C had over 30 independent implementations just for DOS before the C standard ever came out.
 That's why I think that putting the frontend in a public SCM is key for D,
 and I think to have a complete opensource reference implementation will
 be key too in the future.
The D front end is completely open source, and the front end is where the semantics of the language are. Open sourcing the optimizer and register allocator isn't going to clarify how the language works. As gdc shows, the optimizer/backend is not necessary for building a compatible implementation. Before C++ was standardized, cfront was regarded as the 'reference implementation', but it was closed source. That didn't stop at least a dozen independent C++ compilers from being developed.
Feb 29 2008
parent Derek Parnell <derek psych.ward> writes:
On Fri, 29 Feb 2008 14:31:28 -0800, Walter Bright wrote:

 Leandro Lucarella wrote:
 I think languages will well defined specifications are the only ones with
 several compilers/interpreters.
C had over 30 independent implementations just for DOS before the C standard ever came out.
And that was a good thing? Can't we do better?
 That's why I think that putting the frontend in a public SCM is key for D,
 and I think to have a complete opensource reference implementation will
 be key too in the future.
The D front end is completely open source, and the front end is where the semantics of the language are.
But it is not 'open source' in the same sense as an open collaborative development project similar to OpenOffice. The official source is open to be read by any one but getting changes into the official source has a very high barrier.
 Open sourcing the optimizer and 
 register allocator isn't going to clarify how the language works. As gdc 
 shows, the optimizer/backend is not necessary for building a compatible 
 implementation.
 
 Before C++ was standardized, cfront was regarded as the 'reference 
 implementation', but it was closed source. That didn't stop at least a 
 dozen independent C++ compilers from being developed.
And they all developed different variants of C++ because there was no implementation independent specification. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 29 2008
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Derek Parnell escribió:
 On Sun, 24 Feb 2008 09:12:18 +0000, Janice Caron wrote:
 
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  So I would imagine that before another D compiler is written, a
  specification is created that forms the benchmark to measure what is a
  conforming D compiler.
Specifications can have bugs in them too.
Really?? I'm shocked beyond sarcasm!
 That's why specifications have continual addenda and/or new versions.
Ohhh, I wondered why that happened.
 Without that, conforming implementations would be forced to implement
 bugs.
Well thankfully we have people in this world who are willing to correct mistakes in specifications.
 The /real/ definition of a bug is probably "doesn't do what the
 designer intended it to do". That's certainly true when /I/ write code
 - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it
 to do is comply with a spec, in which case non-compliance is a bug,
 but other times I'm creating something new, but in either case, a bug
 is "it doesn't do what I intended".

 In the case of D, I'm happy that Walter is not constrained to a
 possibly buggy spec.
I think that you and I have different experience about what is a specification. To me, a specification is a description of what will be achieved by some system/application, which is agreed upon by the stakeholders of the system. Yes, it likely that it will contain errors, we are human no? Yes, it is likely to be changed over time; to clarify, to remove functionality no longer required, and to add functionality that is now required. All this happens under the watchful eyes of the stakeholders in order to minimize mistakes in the specification. A good piece of software will implement mistakes in the spec. That same softare will also be modified to keep in synchronization with the spec. In my experience, it often happens that mistakes in the spec are discovered by the implementers. In the case of D, I'm not happy that Walter is not constrained to a possibly buggy spec. A specification, with or without bugs, does not cause bug free software. However, how will we know if an application contains bugs if you can't know "what the designer intended it to do" in the first place? The specification is supposed to tell us what the designer wanted. I refuse to believe that Walter could not create a better D compiler if it was known what a D compiler was supposed to do.
See my response to Robert Fraser. I think what the community should do, is write a D specification that looks like this one: http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html It will explain everything: what's the grammar of the language, possibly how to write a lexer and a parser for it, what the compiler is supposed to do with a source file in order to compile it, etc. The specification could be a wiki, which Walter would check according to it's experience, intuition and the DMD front end. Finally, when the specification is done, other compilers could be implemented. At that point, it won't matter if they act like the DMD front end (which probably won't work according to this new specification), it will only matter that they work according to this new sepcification.
Feb 24 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 I refuse to believe that Walter could not create a better D compiler if it
 was known what a D compiler was supposed to do. 
This is so true. Back in college, I attended a lecture about the research process. A researcher would tend to erratically go all over the place trying to find an answer. Once he found it, he'd write up a paper explaining his process, skipping all the dead ends, reversals, and mistakes to make it appear as a straightforward, logical progression from problem to solution. I don't think it is possible to design a useful, non-trivial language without evolutionary feedback.
Feb 24 2008
parent Derek Parnell <derek psych.ward> writes:
On Sun, 24 Feb 2008 12:24:22 -0800, Walter Bright wrote:

 Derek Parnell wrote:
 I refuse to believe that Walter could not create a better D compiler if it
 was known what a D compiler was supposed to do. 
This is so true. Back in college, I attended a lecture about the research process. A researcher would tend to erratically go all over the place trying to find an answer. Once he found it, he'd write up a paper explaining his process, skipping all the dead ends, reversals, and mistakes to make it appear as a straightforward, logical progression from problem to solution. I don't think it is possible to design a useful, non-trivial language without evolutionary feedback.
This is also very true. A design process is always enhanced by 'prototyping' in order to uncover what the real requirements are. The other activity which is just as important in this process, and most others too, is serious and fearless peer review. It might be said that we have in DMD, the prototyping activity. With the forum and Walter's closer associates, we could be seeing an informal variety of peer review. The DigitalMars documentation for D could be argued as being the current version of the specification. Now all we need to see is the specification completed, in the sense of filling in the gaps from what's in Walter's head and cleaning up the known issues with it. Then we can continue the cycle by bringing the compilers "up to spec", which will feedback into an improved spec, and around we go again. Incremental improvement of D, the compilers, the libraries, and the D community's sanity. Well that last one might be a stretch goal ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 24 2008
prev sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  So I would imagine that before another D compiler is written, a
  specification is created that forms the benchmark to measure what is a
  conforming D compiler.
Specifications can have bugs in them too. That's why specifications have continual addenda and/or new versions. Without that, conforming implementations would be forced to implement bugs. The /real/ definition of a bug is probably "doesn't do what the designer intended it to do". That's certainly true when /I/ write code - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it to do is comply with a spec, in which case non-compliance is a bug, but other times I'm creating something new, but in either case, a bug is "it doesn't do what I intended". In the case of D, I'm happy that Walter is not constrained to a possibly buggy spec.
I heavily disagree with this attitude. Unless users of a computer language have a specification which defines that language for them and which they can use to know whether or not what they are doing is correct or not, that language can not be successful. It is of no interest to end users what Walter intended, as opposed to what is written as the specification. I would strongly urge Walter and the active members of the D community to ensure that the specification for versions 1 and 2 of D always remain as relevant as possible and that the specifications be available and downloadable from a single centralized place.
Feb 24 2008
parent Don Clugston <dac nospam.com.au> writes:
Edward Diener wrote:
 Janice Caron wrote:
 On 24/02/2008, Derek Parnell <derek psych.ward> wrote:
  So I would imagine that before another D compiler is written, a
  specification is created that forms the benchmark to measure what is a
  conforming D compiler.
Specifications can have bugs in them too. That's why specifications have continual addenda and/or new versions. Without that, conforming implementations would be forced to implement bugs. The /real/ definition of a bug is probably "doesn't do what the designer intended it to do". That's certainly true when /I/ write code - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it to do is comply with a spec, in which case non-compliance is a bug, but other times I'm creating something new, but in either case, a bug is "it doesn't do what I intended". In the case of D, I'm happy that Walter is not constrained to a possibly buggy spec.
I heavily disagree with this attitude. Unless users of a computer language have a specification which defines that language for them and which they can use to know whether or not what they are doing is correct or not, that language can not be successful. It is of no interest to end users what Walter intended, as opposed to what is written as the specification.
Well, it is 'interesting', as long as Walter regularly issues updates (it's useful to know if a particular annoying behaviour is likely to be fixed in a release available in three days time). But it's very inefficient, and as you say, it impairs adoption of the language.
 
 I would strongly urge Walter and the active members of the D community 
 to ensure that the specification for versions 1 and 2 of D always remain 
 as relevant as possible and that the specifications be available and 
 downloadable from a single centralized place.
Definitely. Note that in the past week, a great leap forward happened in this regard: the source for the spec is now available on dsource. This means that bugs and ambiguities in the spec can be fixed by people other than Walter. We can expect the quality of the spec to improve more rapidly now.
Feb 26 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:fg6iag085q4z.1pwf80bx3vys3.dlg 40tude.net...
 A bug is where the current behaviour is contrary to the specification.
 An enhancement is proposed behaviour that is not documented in the
 specification.

 The problem we (including Walter) have is that D does not have a
 specification and therefore there is no method to determine if a given
 behaviour is by design or a mistake. All we have is "common sense", 
 "that's

Exactly. The "struct tupleof not able to access private members" that was fixed in the most recent D2 update is a perfect example of this. tupleof is very ill-defined in the spec, so it's not entirely clear _what_ it should do, so it seems kind of arbitrary to classify that ability as an enhancement rather than a bug. This is the kind of stuff that would not happen with an exhaustively detailed spec.
Feb 24 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 Exactly.  The "struct tupleof not able to access private members" that was 
 fixed in the most recent D2 update is a perfect example of this.  tupleof is 
 very ill-defined in the spec, so it's not entirely clear _what_ it should 
 do, so it seems kind of arbitrary to classify that ability as an enhancement 
 rather than a bug.
 
 This is the kind of stuff that would not happen with an exhaustively 
 detailed spec. 
True about the spec. However, this is a _breaking_ change (that is, code that compiled frine with older versions has a slight chance of acting differently or breaking when this change is introduced). The same was also true of .init, and the same was also true when: version(Windows) { extern(Windows): } else { extern(C): } was fixed, and a few other bugs. So D1 isn't non-breaking. But I sort of would prefer it was.
Feb 24 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fps551$1q6a$1 digitalmars.com...

 True about the spec. However, this is a _breaking_ change (that is, code 
 that compiled frine with older versions has a slight chance of acting 
 differently or breaking when this change is introduced).
Actually it isn't, it's an _un_breaking change ;) Code that used to not work now does. So it's not like there's any existing code out there to break.
Feb 24 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jarrett Billingsley wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:fps551$1q6a$1 digitalmars.com...
 
 True about the spec. However, this is a _breaking_ change (that is, code
 that compiled frine with older versions has a slight chance of acting
 differently or breaking when this change is introduced).
Actually it isn't, it's an _un_breaking change ;) Code that used to not work now does. So it's not like there's any existing code out there to break.
Actually, extern (System) was introduced because users had come to rely on a bug that was later fixed ( versioned blocks with "extern(Windows):" in them). So more like fix and break, then change to unbreak again. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Feb 24 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:fps7e5$1scr$1 digitalmars.com...
 Jarrett Billingsley wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:fps551$1q6a$1 digitalmars.com...

 True about the spec. However, this is a _breaking_ change (that is, code
 that compiled frine with older versions has a slight chance of acting
 differently or breaking when this change is introduced).
Actually it isn't, it's an _un_breaking change ;) Code that used to not work now does. So it's not like there's any existing code out there to break.
Actually, extern (System) was introduced because users had come to rely on a bug that was later fixed ( versioned blocks with "extern(Windows):" in them). So more like fix and break, then change to unbreak again.
I was referring to the struct tupleof issue. Sorry.
Feb 24 2008
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Sun, 24 Feb 2008 09:28:25 -0500, Jarrett Billingsley wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:fg6iag085q4z.1pwf80bx3vys3.dlg 40tude.net...
 A bug is where the current behaviour is contrary to the specification.
 An enhancement is proposed behaviour that is not documented in the
 specification.

 The problem we (including Walter) have is that D does not have a
 specification and therefore there is no method to determine if a given
 behaviour is by design or a mistake. All we have is "common sense",
 "that's

Exactly. The "struct tupleof not able to access private members" that was fixed in the most recent D2 update is a perfect example of this. tupleof is very ill-defined in the spec, so it's not entirely clear _what_ it should do, so it seems kind of arbitrary to classify that ability as an enhancement rather than a bug. This is the kind of stuff that would not happen with an exhaustively detailed spec.
What makes you think the exhaustively detailed spec would not say the same thing? In my opinion if Walter put for the effort to write such a spec it would just state those things that the compiler does. (Yes if the spec was fully written out an critiqued then it could be corrected, but that is the same thing that is happening to the development compiler.)
Feb 24 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jesse Phillips" <jessekphillips gmail.com> wrote in message 
news:fpshnv$2632$1 digitalmars.com...
 What makes you think the exhaustively detailed spec would not say the
 same thing? In my opinion if Walter put for the effort to write such a
 spec it would just state those things that the compiler does. (Yes if the
 spec was fully written out an critiqued then it could be corrected, but
 that is the same thing that is happening to the development compiler.)
If the spec _did_ say the same thing as the compiler, I'd at least know that the compiler was behaving correctly, and wouldn't be asking Walter to backport this change to D1. But since the spec says _nothing_, I have no idea whether the compiler is correct or not.
Feb 25 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 25/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least know that
  the compiler was behaving correctly, and wouldn't be asking Walter to
  backport this change to D1.
I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable has a spec, since it is stable apart from bug fixes. But D2 is constantly evolving, with breaking changes happening every few releases. This evolution is the result of experience and feedback. D2 /cannot/ have a spec, until some day in the future when it becomes stable. Whether or not the D2 compiler is behaving "correctly" rather depends on what "correctly" will eventually be, and that's not fixed yet. It would therefore make no sense to backport D2 changes to D1 based on some assumption of spec-compliance, when D2 changes might not even be permanent.
  But since the spec says _nothing_, I have no idea whether the compiler is
  correct or not.
Even if it's bug free in D2.N, that doesn't mean it won't change in D2.(N+1), so you really can't use that as a basis for backporting anyway.
Feb 25 2008
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Janice Caron wrote:
 On 25/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least know that
  the compiler was behaving correctly, and wouldn't be asking Walter to
  backport this change to D1.
I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable has a spec, since it is stable apart from bug fixes.
I think you're confusing "D1 spec being stable" with "D1 spec being incomplete".
Feb 25 2008
parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Alexander Panek wrote:
 Janice Caron wrote:
 On 25/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least 
 know that
  the compiler was behaving correctly, and wouldn't be asking Walter to
  backport this change to D1.
I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable has a spec, since it is stable apart from bug fixes.
I think you're confusing "D1 spec being stable" with "D1 spec being incomplete".
Err, the other way round: "D1 spec being stable" doesn't mean "D1 spec being complete"
Feb 25 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 25/02/2008, Alexander Panek <alexander.panek brainsware.org> wrote:
  > I think you're confusing "D1 spec being stable" with "D1 spec being
  > incomplete".
On the contrary, I am saying nothing whatsoever about D1. You could argue that it has a spec; you could argue that it doesn't - frankly, I don't care either way. What I /am/ saying though, is that D2 does /not/ have a spec, and therefore one cannot make any claims that the D2 compiler is, or is not, "behaving correctly", and therefore cannot use that as a basis to decide what should or should not be backported to D1.
Feb 25 2008
parent Alexander Panek <alexander.panek brainsware.org> writes:
Janice Caron wrote:
 On 25/02/2008, Alexander Panek <alexander.panek brainsware.org> wrote:
  > I think you're confusing "D1 spec being stable" with "D1 spec being
  > incomplete".
On the contrary, I am saying nothing whatsoever about D1. You could argue that it has a spec; you could argue that it doesn't - frankly, I don't care either way.
I'm not arguing whether it has a spec, either. It was just stated that the specification is not /complete/. You know, this grey zone between "complete" and "nothing".
Feb 25 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.79.1203955731.2351.digitalmars-d puremagic.com...
 On 25/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least know 
 that
  the compiler was behaving correctly, and wouldn't be asking Walter to
  backport this change to D1.
I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable has a spec, since it is stable apart from bug fixes.
I don't use D2. I haven't really looked at it and I don't even have it installed. The only things I know about D2 are what's written in the changelog. I'm talking about the D1 compiler and D1's spec here. Secondly, I couldn't possibly be confusing the two specs since *gasp* both specs say the same thing about tupleof. Which is to say, not a whole hell of a lot.
 But D2 is constantly evolving, with breaking changes happening every
 few releases. This evolution is the result of experience and feedback.
 D2 /cannot/ have a spec, until some day in the future when it becomes
 stable. Whether or not the D2 compiler is behaving "correctly" rather
 depends on what "correctly" will eventually be, and that's not fixed
 yet. It would therefore make no sense to backport D2 changes to D1
 based on some assumption of spec-compliance, when D2 changes might not
 even be permanent.
IMO something doesn't have to be *finalized* to have a spec. See C++0x. For that matter you can *start* with a specification and build a program that follows it. In fact, that's kind of how I imagined it *should* be done.. Let me explain exactly what I'm talking about. Right now we're talking about D1 and D1 only. This is what the D1 spec says about .tupleof. Under structs/unions, in the "struct properties" table, it says: .tupleof: Gets type tuple of fields So there are two things you'll notice. One, apparently the compiler does not implement the spec here, since in the compiler, .tupleof gets you a tuple of the fields themselves, and not their types. typeof(S.tupleof) will get you a type tuple of the fields. Is the compiler wrong or is the spec wrong? Fortunately, because we have both, we can see that there is a discrepancy and raise a red flag (aka an RFC, which I will go and do right after this). Two, _this is all it says about tupleof_. It says absolutely _nothing_ about how .tupleof interacts with protection attributes, how it interacts with nested anonymous structs and unions, _anything_ really. It's five words. It's ill-specified. So in the case where the compiler gives an error upon using .tupleof on a struct with private fields, _is the compiler acting correctly_? There's no spec, so there's no discrepancy; instead the compiler is AWOL, and I guess it can do anything it wants because the corner cases are unspecified. This is where compiler-dependent stuff crops up and it's nothing but headaches. This instance is a call for a better-defined spec. Even if it's changed to say that it's illegal (and I'd rather it wouldn't be), _I don't care_, I want it to say which it is so that I know that when I write my code, I know that every compiler I compile it with will do the same thing and give me the same errors (or lack thereof). Long story short: the D1 spec says nothing about tupleof so it could really go either way (either keep it the way it is or backport the *present* D2 way). There is no harm in backporting, it's a non-breaking change, so I don't see why it couldn't be done.
Feb 25 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 "Janice Caron" wrote in message
 news:mailman.79.1203955731.2351.digitalmars-d puremagic.com...
 On 25/02/2008, Jarrett Billingsley wrote:

 I think you're confusing "D1 spec" with "D2 spec" here. D1 arguable
 has a spec, since it is stable apart from bug fixes.
I don't use D2. I haven't really looked at it and I don't even have it installed. The only things I know about D2 are what's written in the changelog. I'm talking about the D1 compiler and D1's spec here. Secondly, I couldn't possibly be confusing the two specs since *gasp* both specs say the same thing about tupleof. Which is to say, not a whole hell of a lot.
 But D2 is constantly evolving, with breaking changes happening every
 few releases. This evolution is the result of experience and feedback.
 D2 /cannot/ have a spec, until some day in the future when it becomes
 stable. Whether or not the D2 compiler is behaving "correctly" rather
 depends on what "correctly" will eventually be, and that's not fixed
 yet. It would therefore make no sense to backport D2 changes to D1
 based on some assumption of spec-compliance, when D2 changes might not
 even be permanent.
IMO something doesn't have to be *finalized* to have a spec. See C++0x. For that matter you can *start* with a specification and build a program that follows it. In fact, that's kind of how I imagined it *should* be done.. Let me explain exactly what I'm talking about. Right now we're talking about D1 and D1 only. This is what the D1 spec says about .tupleof. Under structs/unions, in the "struct properties" table, it says: .tupleof: Gets type tuple of fields So there are two things you'll notice. One, apparently the compiler does not implement the spec here, since in the compiler, .tupleof gets you a tuple of the fields themselves, and not their types. typeof(S.tupleof) will get you a type tuple of the fields. Is the compiler wrong or is the spec wrong? Fortunately, because we have both, we can see that there is a discrepancy and raise a red flag (aka an RFC, which I will go and do right after this). Two, _this is all it says about tupleof_. It says absolutely _nothing_ about how .tupleof interacts with protection attributes, how it interacts with nested anonymous structs and unions, _anything_ really. It's five words. It's ill-specified. So in the case where the compiler gives an error upon using .tupleof on a struct with private fields, _is the compiler acting correctly_? There's no spec, so there's no discrepancy; instead the compiler is AWOL, and I guess it can do anything it wants because the corner cases are unspecified. This is where compiler-dependent stuff crops up and it's nothing but headaches. This instance is a call for a better-defined spec. Even if it's changed to say that it's illegal (and I'd rather it wouldn't be), _I don't care_, I want it to say which it is so that I know that when I write my code, I know that every compiler I compile it with will do the same thing and give me the same errors (or lack thereof). Long story short: the D1 spec says nothing about tupleof so it could really go either way (either keep it the way it is or backport the *present* D2 way). There is no harm in backporting, it's a non-breaking change, so I don't see why it couldn't be done.
Mr. Denis apparently didn't find his reply worthy of appearing on the newsgroups, but I found it relevant nonetheless. ----------------- Koroskin Denis <2korden gmail.com> wrote: You know the feature is incomplete, so just don't use the feature. Why bother yourself and others?! ----------------- This is called feedback. Walter implements something, we tell him whether or not we like it. It's how the language gets better. Walter *can* make mistakes, and when he does, it's generally accepted that people point them out and he do something about them.
Feb 27 2008
parent "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Wed, 27 Feb 2008 17:22:05 +0300, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:
 Mr. Denis apparently didn't find his reply worthy of appearing on the
 newsgroups, but I found it relevant nonetheless.

 -----------------
 Koroskin Denis <2korden gmail.com> wrote:
 You know the feature is incomplete, so just don't use the feature. Why
 bother yourself and others?!
 -----------------

 This is called feedback.  Walter implements something, we tell him  
 whether
 or not we like it.  It's how the language gets better.  Walter *can* make
 mistakes, and when he does, it's generally accepted that people point  
 them
 out and he do something about them.
My bad, I misreplied it directly to instead of digitalmars.D (I didn't think Opera would behave that strange on Quick Reply) Hope, this one would hit the newsgroup :)
Feb 27 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least know that 
 the compiler was behaving correctly, and wouldn't be asking Walter to 
 backport this change to D1.
 
 But since the spec says _nothing_, I have no idea whether the compiler is 
 correct or not. 
I would think the spec needs to say something if tupleof bypassed access protections, because honoring the access protections should be assumed to be the default.
Feb 29 2008
parent Derek Parnell <derek psych.ward> writes:
On Fri, 29 Feb 2008 14:15:02 -0800, Walter Bright wrote:

 Jarrett Billingsley wrote:
 If the spec _did_ say the same thing as the compiler, I'd at least know that 
 the compiler was behaving correctly, and wouldn't be asking Walter to 
 backport this change to D1.
 
 But since the spec says _nothing_, I have no idea whether the compiler is 
 correct or not. 
I would think the spec needs to say something if tupleof bypassed access protections, because honoring the access protections should be assumed to be the default.
Assume as little as possible. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 29 2008
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
On Sun, 24 Feb 2008, Jarrett Billingsley wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:fg6iag085q4z.1pwf80bx3vys3.dlg 40tude.net...
 A bug is where the current behaviour is contrary to the specification.
 An enhancement is proposed behaviour that is not documented in the
 specification.

 The problem we (including Walter) have is that D does not have a
 specification and therefore there is no method to determine if a given
 behaviour is by design or a mistake. All we have is "common sense",
 "that's

Exactly. The "struct tupleof not able to access private members" that was fixed in the most recent D2 update is a perfect example of this. tupleof is very ill-defined in the spec, so it's not entirely clear _what_ it should do, so it seems kind of arbitrary to classify that ability as an enhancement rather than a bug.
Funny that you mentioned it. I just tested that .tupleof apparently doesn't even return any valid type / value :S. See http://d.puremagic.com/issues/show_bug.cgi?id=1866#c1. Of course specifying these and changing the old behavior breaks old code, but seriously any code that relies on unspecified features and buggy implementations will be horribly broken anyways some day. Walter should worry about what kind of effect these kind of weirdnesses have on the health of us poor little developers.
Feb 24 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Derek Parnell wrote:
 A bug is where the current behavior is contrary to the specification. 
 An enhancement is proposed behavior that is not documented in the
 specification.
D1 has received spec changes after it became stable, most notably ".init".
Feb 24 2008
prev sibling next sibling parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Walter Bright wrote:
 That isn't true at all. "Porting" changes to D1 is trivial, since the 
 code is about 98% common. The problem is there is often not a clear 
 distinction between a bug and an enhancement, and D1 cannot be a stable 
 language if it keeps getting enhancements.
BTW... it would be very nice if you could backport the "extern (C++) interface"-feature to D1 ;-) ... it is very cumbersome to emulate this with structs and function pointers. LLAP, Sascha
Feb 24 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sascha Katzner wrote:
 BTW... it would be very nice if you could backport the "extern (C++) 
 interface"-feature to D1 ;-) ... it is very cumbersome to emulate this 
 with structs and function pointers.
The problem is, everyone has a different such list. After all, D 2.0 is not a collection of features nobody wants.
Feb 24 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 I think Walter is doing a pretty good job of fixing bugs with D1, but 
 still there are a few instances where he has seemed a little too eager 
 to classify a fix as an enhancement, apparently so as to avoid having 
 to port it to D1.
That isn't true at all. "Porting" changes to D1 is trivial, since the code is about 98% common. The problem is there is often not a clear distinction between a bug and an enhancement, and D1 cannot be a stable language if it keeps getting enhancements.
If it's so easy to backport changes then why not create a 1.5x series of releases which are D1.x + non-breaking changes from D2? I had figured the reason for not doing so was that it would take too much time. Or is it the other stuff that takes too much time? (Maintaining a separate version of all the web pages, etc.) --bb
Feb 24 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 Bill Baxter wrote:
 I think Walter is doing a pretty good job of fixing bugs with D1, but 
 still there are a few instances where he has seemed a little too 
 eager to classify a fix as an enhancement, apparently so as to avoid 
 having to port it to D1.
That isn't true at all. "Porting" changes to D1 is trivial, since the code is about 98% common. The problem is there is often not a clear distinction between a bug and an enhancement, and D1 cannot be a stable language if it keeps getting enhancements.
If it's so easy to backport changes then why not create a 1.5x series of releases which are D1.x + non-breaking changes from D2? I had figured the reason for not doing so was that it would take too much time. Or is it the other stuff that takes too much time? (Maintaining a separate version of all the web pages, etc.)
Well, I guess there is the issue with making the Cartesian product of {D1,D2} x {DMD,GDC} x {Phobos,Tango} even more confusing. Which would not be good. So I'll just reiterate that I wish D1 were still getting backwards-compatible changes -- at least until D2 is so stable that even Tango supports it. That's the timeframe in which I believe D1 should have become frozen. Not the minute D2 was forked. --bb
Feb 24 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el 25 de febrero a las 02:19 me escribiste:
 Walter Bright wrote:
Bill Baxter wrote:
I think Walter is doing a pretty good job of fixing bugs with D1, but still
there are a few instances where he has seemed a little too eager to classify a 
fix as an enhancement, apparently so as to avoid having to port it to D1.
That isn't true at all. "Porting" changes to D1 is trivial, since the code is about 98% common. The problem is there is often not a clear distinction between a bug and an enhancement, and D1 cannot be a stable language if it keeps getting enhancements.
If it's so easy to backport changes then why not create a 1.5x series of releases which are D1.x + non-breaking changes from D2? I had figured the reason for not doing so was that it would take too much time. Or is it the other stuff that takes too much time? (Maintaining a separate version of all the web pages, etc.)
I think D should have 1.1, 1.2, 1.3, etc., series, where backward compatible new features are included to the language. Even minor backward incompatible changes could be added with a well defined cicle of future/deprecated features a la Python. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ADOLESCENTE MUERE DESNUCADO POR TRATAR DE AUTOCHUPARSE -- Cronista TV
Feb 24 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 If it's so easy to backport changes then why not create a 1.5x series of 
 releases which are D1.x + non-breaking changes from D2?  I had figured 
 the reason for not doing so was that it would take too much time.  Or is 
 it the other stuff that takes too much time?  (Maintaining a separate 
 version of all the web pages, etc.)
Having yet a 3rd version of the language would not be helpful, especially in the light of the troubles over having two incompatible runtime libraries.
Feb 24 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Denton Cockburn wrote:
 On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:
 
 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
I understand that, but there are still many outstanding bugs in D 1.0. 2.0 now, which is in development, a lot of the changes affect things elsewhere. Are you going to correct all of those side-effects before releasing 2.0? or are they going to be addressed during the development of 3.0? I was reading a thread on reddit a few days ago about issues people have with their favourite language. One of the issues with D was that people were still running into compiler errors and bugs in what is expected to be a systems programming language.
Agreed. I would never even consider D suitable for a production application. I think the problem, though, is that Walter is working a ll alone (basically) on the compiler, and the GDC team is just playing catch-up using the same front-end. I just read about dil, which looks interesting, but it doesn't seem to be getting anywhere fast. D needs a community compiler, with an open frontend & backend, where a large group canf ocus on fixing bugs & maintaining stability. Or an expensive corporate-backed compiler, I'd expect the same quality from that. Not to diss on Walter - you're doing a great job - but writing a compiler for a language as complex as D is not a one-man task.
Feb 23 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fpqa5g$2907$1 digitalmars.com...

 Not to diss on Walter - you're doing a great job - but writing a compiler 
 for a language as complex as D is not a one-man task.
And writing two compilers, two standards, and two runtime libraries with one man is just a joke.
Feb 23 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:
 Denton Cockburn wrote:
 On Sat, 23 Feb 2008 10:16:08 -0800, Walter Bright wrote:

 Denton Cockburn wrote:
 [quoted text muted]
D 1.0 regularly gets bug fixes with the focus on improving its stability.
 D needs a  community compiler, with an open frontend & backend, where a large
group
 canf ocus on fixing bugs & maintaining stability. Or an expensive 
 corporate-backed compiler, I'd expect the same quality from that.
The problem is that it is currently impossible to do that well. Most of the D specification is in the DMD front end. For example, I see nowhere in the specification that you cannot change a reference to a static array, or how to properly determine forward references (these are just examples, I'm sure there a *lot* of other examples... Descent currently has 439 (!) distintct kind of errors, converted to IDs from DMD, for the curious: http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/core/compiler/IProblem.java). If most of the specification is the DMD front end, then if the community makes another, clean compiler, it must be sure it works according to the specification. The only thing they can do is to test it against the DMD front end, because most of the error reporting and the logic that tells you how to find members in modules, when a function is covariant with another, etc., is in it. But it has some bugs, so... what's the *real* specification? Just an intuition of how things should work? Ummm... that's not good. I'm thinking about something like this: http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html Yeah, I know, it's huge. But it actually even tells you how to implement a Java compiler without having to read an implementation of it. Then everything is clear for everyone. And it's huge and tells you everything because it (probably) wasn't made by a single person.
Feb 23 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denton Cockburn wrote:
 I understand that, but there are still many outstanding bugs in D 1.0.
 2.0 now, which is in development, a lot of the changes affect things
 elsewhere.  Are you going to correct all of those side-effects before
 releasing 2.0? or are they going to be addressed during the development of
 3.0?
All the bugs present in 1.0 are also present in 2.0, and as they get fixed they get folded back into 1.0. You can see that effect in the changelog.
 I was reading a thread on reddit a few days ago about issues people have
 with their favourite language.  One of the issues with D was that people
 were still running into compiler errors and bugs in what is
 expected to be a systems programming language.
All useful compilers are full of bugs. For example, gcc has 4265 unresolved bugs. http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=gcc&content=
Feb 23 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
On Sat, 23 Feb 2008 21:46:19 -0800, Walter Bright wrote:

 All useful compilers are full of bugs. For example, gcc has 4265 
 unresolved bugs.
 
 http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=gcc&content=
Ouch. Touche.
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denton Cockburn wrote:
 On Sat, 23 Feb 2008 21:46:19 -0800, Walter Bright wrote:
 
 All useful compilers are full of bugs. For example, gcc has 4265 
 unresolved bugs.

 http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=gcc&content=
Ouch. Touche.
One way to look at the bug count is as a measure of how many people are using the product. Only a handful of bugs correlates to nobody using it. The rising bug count in D is not the result of increasing instability, but of increased usage of it and more sophisticated use. D also has a steadily more comprehensive test suite, as a direct result of fixing bugs. This test suite makes possible the ratcheting forward of the stability of the compiler, as it ensures all the previous issues stay fixed. The one I have for DM C++ has 25 years of bug reports merged in, and is an asset rivaling in value the C++ compiler itself.
Feb 24 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 Denton Cockburn wrote:
 On Sat, 23 Feb 2008 21:46:19 -0800, Walter Bright wrote:

 All useful compilers are full of bugs. For example, gcc has 4265 
 unresolved bugs.

 http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&
roduct=gcc&content= 
Ouch. Touche.
One way to look at the bug count is as a measure of how many people are using the product. Only a handful of bugs correlates to nobody using it. The rising bug count in D is not the result of increasing instability, but of increased usage of it and more sophisticated use.
In the case of gcc, the other way to look at the bug count (4265) is to realize that the number is the combined sum of four front ends (C, C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 bit). At least that is what I gathered from the link. So I think it's just a little unfair to compare dmd's bug count directly to gcc's, although I understand the point you were trying to make. :) -JJR
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is to 
 realize that the number is the combined sum of four front ends (C, C++, 
 Objective C, GNAT) and two processor IS targets (32 bit and 64 bit).  At 
 least that is what I gathered from the link. So I think it's just a 
 little unfair to compare dmd's bug count directly to gcc's, although I 
 understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway. For example, if feature A is not implemented, that's a bug. But if A is implemented, yet has a couple obscure problems with it, one bug has been replaced by two. Does that mean the quality has gone down? As soon as someone starts using the bug count as a measure of quality, people start "working" the bug count, and several things start happening: 1) people avoid putting bugs into the database 2) people argue about whether bug 114 is really one bug or 3 separate bugs 3) people argue about whether bug 543 is a bug or an enhancement 4) people will log a bunch of trivial bugs, then immediately 'fix' them, so they look like they're doing impressive work 5) people won't work on the hard bugs, because no matter how much time it takes to fix it, it will only count as "1" fix, and the other guy who fixed 3 typos gets credit for "3" fixes. All of this is counterproductive. I've seen it happen in one company that put a giant paper graph on the wall with the bug count logged daily. The fights got progressively more acrimonious to the point where management finally wised up and stopped grading programmers on the bug count before total meltdown ensued. I had another experience where I once published the outstanding bug list on the C++ compiler as a service to the users of it. One lazy journalist then did a comparative compiler review, and his review of my compiler consisted of little more than a cut&paste of the bug list. I never did that again. These sorts of things is what made me very reluctant to use bugzilla for D. Fortunately, these days people seem to have moved past naive bug counts.
Feb 24 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is 
 to realize that the number is the combined sum of four front ends (C, 
 C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 
 bit).  At least that is what I gathered from the link. So I think it's 
 just a little unfair to compare dmd's bug count directly to gcc's, 
 although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway. For example, if feature A is not implemented, that's a bug. But if A is implemented, yet has a couple obscure problems with it, one bug has been replaced by two. Does that mean the quality has gone down? As soon as someone starts using the bug count as a measure of quality, people start "working" the bug count, and several things start happening: 1) people avoid putting bugs into the database 2) people argue about whether bug 114 is really one bug or 3 separate bugs 3) people argue about whether bug 543 is a bug or an enhancement 4) people will log a bunch of trivial bugs, then immediately 'fix' them, so they look like they're doing impressive work 5) people won't work on the hard bugs, because no matter how much time it takes to fix it, it will only count as "1" fix, and the other guy who fixed 3 typos gets credit for "3" fixes. All of this is counterproductive. I've seen it happen in one company that put a giant paper graph on the wall with the bug count logged daily. The fights got progressively more acrimonious to the point where management finally wised up and stopped grading programmers on the bug count before total meltdown ensued. I had another experience where I once published the outstanding bug list on the C++ compiler as a service to the users of it. One lazy journalist then did a comparative compiler review, and his review of my compiler consisted of little more than a cut&paste of the bug list. I never did that again. These sorts of things is what made me very reluctant to use bugzilla for D. Fortunately, these days people seem to have moved past naive bug counts.
True, bug counts are a poor statistic. I guess the motive for using them is as an organizational mechanism, as well as a questionable measure of project progression. I suppose that they make good sense as long as they are not adopted as as a manipulative tool. -JJR -JJR
Feb 24 2008
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 24 de febrero a las 21:58 me escribiste:
 John Reimer wrote:
In the case of gcc, the other way to look at the bug count (4265) is to realize
that the 
number is the combined sum of four front ends (C, C++, Objective C, GNAT) and
two 
processor IS targets (32 bit and 64 bit).  At least that is what I gathered
from the 
link. So I think it's just a little unfair to compare dmd's bug count directly
to gcc's, 
although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway.
I agree, that's why I'm still wondering why did you mention it in the discussion :) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Bald men with no jobs and no money who live with their parents don't approach strange women. -- George Constanza
Feb 25 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 24 de febrero a las 21:58 me escribiste:
 John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is to
realize that the 
 number is the combined sum of four front ends (C, C++, Objective C, GNAT) and
two 
 processor IS targets (32 bit and 64 bit).  At least that is what I gathered
from the 
 link. So I think it's just a little unfair to compare dmd's bug count directly
to gcc's, 
 although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway.
I agree, that's why I'm still wondering why did you mention it in the discussion :)
To illustrate my point!
Feb 27 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 27 de febrero a las 17:17 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 24 de febrero a las 21:58 me escribiste:
John Reimer wrote:
In the case of gcc, the other way to look at the bug count (4265) is to realize
that 
the number is the combined sum of four front ends (C, C++, Objective C, GNAT)
and two 
processor IS targets (32 bit and 64 bit).  At least that is what I gathered
from the 
link. So I think it's just a little unfair to compare dmd's bug count directly
to 
gcc's, although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway.
I agree, that's why I'm still wondering why did you mention it in the discussion :)
To illustrate my point!
But nobody mentioned the bug count. We are talking about annoying bugs that you run into everyday, not 4000 bugs you never see in the day by day. Maybe they are just 10, but they are a lot whorst than the 4K gcc bugs. Not to mention the unimplemented specs (like the broken protection attributes for modules and such). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Every day 21 new born babies will be given to the wrong parents
Feb 28 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is 
 to realize that the number is the combined sum of four front ends (C, 
 C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 
 bit).  At least that is what I gathered from the link. So I think it's 
 just a little unfair to compare dmd's bug count directly to gcc's, 
 although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway. For example, if feature A is not implemented, that's a bug. But if A is implemented, yet has a couple obscure problems with it, one bug has been replaced by two. Does that mean the quality has gone down? As soon as someone starts using the bug count as a measure of quality, people start "working" the bug count, and several things start happening: 1) people avoid putting bugs into the database 2) people argue about whether bug 114 is really one bug or 3 separate bugs 3) people argue about whether bug 543 is a bug or an enhancement 4) people will log a bunch of trivial bugs, then immediately 'fix' them, so they look like they're doing impressive work 5) people won't work on the hard bugs, because no matter how much time it takes to fix it, it will only count as "1" fix, and the other guy who fixed 3 typos gets credit for "3" fixes.
It's little better I think if you assign points to bugs based on their estimated difficulty of fixing and relative significance. Inkscape folks were doing that with their last release. Maybe that's something that's built into launchpad? Still, in a corporate setting I can see there being issues even with a points system. Who decides how many points it's worth, what if a bug turns out to be harder than anticipated, somebody could still try to file and close a million trivial bugs to game the system. But in an environment where people actually care about the software they're creating, and not all just trying to get promoted, I think points for bugs can be a useful motivator. --bb
Feb 25 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 It's little better I think if you assign points to bugs based on their 
 estimated difficulty of fixing and relative significance.
A bug list is a great way to organize and manage what to do next on the product. It is *terrible* as a numeric measure of quality. Never underestimate the ability of people to manipulate any objective measure of their performance.
 Still, in a corporate setting I can see there being issues even with a 
 points system.  Who decides how many points it's worth, what if a bug 
 turns out to be harder than anticipated, somebody could still try to 
 file and close a million trivial bugs to game the system.  But in an 
 environment where people actually care about the software they're 
 creating, and not all just trying to get promoted, I think points for 
 bugs can be a useful motivator.
The situations I've seen it tried in were not populated by unmotivated, incompetent engineers. The problem is the bug count is a corrupting influence, that after a while even the best succumb to. I also saw a company that decided to grade its staff on minimizing inventory, because they were going to do "just in time" production. Well, the inventory got minimized, all right. A $10,000 sale would be lost because a 5 cent component was out of stock. (It got so bad that some of the engineers would actually buy critical components on their own nickel and keep a supply in their desk drawers.) You've got to be very, very careful about grading people on some sort of objective metric. Because you'll get what you grade for, and might find out that it's not what you wanted at all (like all those twilight zone episodes where the person gets 3 wishes from the devil).
Feb 27 2008
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 27 Feb 2008 17:26:15 -0800, Walter Bright wrote:

 
 A bug list is a great way to organize and manage what to do next on the 
 product. It is *terrible* as a numeric measure of quality.
Agreed. The absolute number of (known) bugs is not a relevant measure. I find that a better measure of stability is the changes in the bug count, and that only in an environment in which there is no penalty or reward for creating and/or finding bugs. In this case if there is a trend of reducing bug counts for a product, it more likely to be a stable one. Also, the relative size of the delta (increase or decrease) in bug counts after a new release is also indicative of quality, but nothing is absolute. -- Derek (skype: derek.j.parnell) Melbourne, Australia 28/02/2008 12:43:57 PM
Feb 27 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 These sorts of things is what made me very reluctant to use bugzilla for 
 D. Fortunately, these days people seem to have moved past naive bug counts.
In the open source world, bugs are usually taken as they are. But for the PM in a large company who thinks "int" is short for "interface", the number and priority of bugs is considered, not the difficulty of fixing them or importance to the system. On another note, can anyone explain the difference between "priority" and "severity"?
Feb 25 2008
parent reply Jan Claeys <digitalmars janc.be> writes:
Op Mon, 25 Feb 2008 11:33:02 -0800, schreef Robert Fraser:

 On another note, can anyone explain the difference between "priority"
What should be fixed first or last as decided by the decision makers. E.g. a new feature that is needed in order to convice a big new customer could be marked with a higher priority than a security bug that gets you no extra income for fixing it... ;-)
 and "severity"?
An "objective" assessment of how bad a bug is. E.g. something causing data loss or serious security problems would have a much high severity rating than a typo in the API documentation. -- JanC
May 07 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jan Claeys wrote:
 Op Mon, 25 Feb 2008 11:33:02 -0800, schreef Robert Fraser:
 
 On another note, can anyone explain the difference between "priority"
What should be fixed first or last as decided by the decision makers. E.g. a new feature that is needed in order to convice a big new customer could be marked with a higher priority than a security bug that gets you no extra income for fixing it... ;-)
 and "severity"?
An "objective" assessment of how bad a bug is. E.g. something causing data loss or serious security problems would have a much high severity rating than a typo in the API documentation.
In theory yes, but does anyone actually look at "Priority"? --bb
May 07 2008
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 08 May 2008 05:38:10 +0900, Bill Baxter wrote:

 In theory yes, but does anyone actually look at "Priority"?
YES! In my job, "priority" is the customer's chosen work order. Defy that and I lose parts of my anatomy ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 07 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:
 On Thu, 08 May 2008 05:38:10 +0900, Bill Baxter wrote:
 
 In theory yes, but does anyone actually look at "Priority"?
YES! In my job, "priority" is the customer's chosen work order. Defy that and I lose parts of my anatomy ;-)
Actually I was using "anybody" as a secret code word meaning "Walter". In general, yeh, I'm sure there are plenty of bugzilla users like yourself make full use of the priority field. --bb
May 07 2008
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Walter Bright wrote:
 John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is 
 to realize that the number is the combined sum of four front ends (C, 
 C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 
 bit).  At least that is what I gathered from the link. So I think it's 
 just a little unfair to compare dmd's bug count directly to gcc's, 
 although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway. For example, if feature A is not implemented, that's a bug. But if A is implemented, yet has a couple obscure problems with it, one bug has been replaced by two. Does that mean the quality has gone down?
Neither. The feature is not implemented properly, it's kind of counter productive to argue about the quality of some not implemented or broken feature. It would be better to discuss the progress of implementing or fixing a feature.
 As soon as someone starts using the bug count as a measure of quality, 
 people start "working" the bug count, and several things start happening:
 
 1) people avoid putting bugs into the database
From personal experience, I can say that this is not the case in the environments I have worked in so far. In every single of them, bug reports are highly appreciated. Especially because there is some sort of analogy to TDD: keeping the lights green is a good motivator.
 2) people argue about whether bug 114 is really one bug or 3 separate bugs
This can be good under some circumstances. E.g., if this bug says "I cannot open the file X with your tool Y", it can be caused by several things in given tool. Why not split it up into several bugs in the bug tracker to let different people work and comment on it? IMHO, splitting up stuff into smaller junks increases productivity, thus motivation, thus productivity, etc - you get my drift.
 3) people argue about whether bug 543 is a bug or an enhancement
What's wrong with that? Classification is important and helps prioritizing work, especially in teams.
 4) people will log a bunch of trivial bugs, then immediately 'fix' them,
 so they look like they're doing impressive work
 5) people won't work on the hard bugs, because no matter how much time
 it takes to fix it, it will only count as "1" fix, and the other guy who 
 fixed 3 typos gets credit for "3" fixes.
A guy like you shouldn't be working with such immature people. :)
 I had another experience where I once published the outstanding bug list 
 on the C++ compiler as a service to the users of it. One lazy journalist 
 then did a comparative compiler review, and his review of my compiler 
 consisted of little more than a cut&paste of the bug list. I never did 
 that again.
Seems like one should always have a balance between "'Tis so shiny!" documentation and issue tracking..
 These sorts of things is what made me very reluctant to use bugzilla for 
 D. Fortunately, these days people seem to have moved past naive bug counts.
Personally, I don't really see open source projects without a public issue tracker as well managed.. after all open source software lives from user feedback, right? Also, you may find workarounds for your specific problem in the comments of a bug report -- or the other way round: find confirmation of bugs that may be easier to reproduce for yourself. To conclude: I don't see bug count per se as quality measurement, rather response time and interactivity with the development team of a project (from a user, as well as contributor point of view). These qualities are pretty easy to spot via some issue tracking software (comments, fixes, workarounds, etc.) and give people a way of monitoring the development process. The latter can especially be important in situations where people have to decide what tool to use for their next project(s) -- and we all want this to be D! :)
Feb 25 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fptldk$1v86$1 digitalmars.com...

 5) people won't work on the hard bugs, because no matter how much time it 
 takes to fix it, it will only count as "1" fix, and the other guy who 
 fixed 3 typos gets credit for "3" fixes.
What if fixing a hard bug gets you .. let me count .. 23 fixes? Would that be enough motivation? (*cough*forward references*cough*) ;)
Feb 25 2008
prev sibling parent Clay Smith <clayasaurus gmail.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 In the case of gcc, the other way to look at the bug count (4265) is 
 to realize that the number is the combined sum of four front ends (C, 
 C++, Objective C, GNAT) and two processor IS targets (32 bit and 64 
 bit).  At least that is what I gathered from the link. So I think it's 
 just a little unfair to compare dmd's bug count directly to gcc's, 
 although I understand the point you were trying to make. :)
Bug count is an uninformative measure of quality anyway. For example, if feature A is not implemented, that's a bug. But if A is implemented, yet has a couple obscure problems with it, one bug has been replaced by two. Does that mean the quality has gone down? As soon as someone starts using the bug count as a measure of quality, people start "working" the bug count, and several things start happening: 1) people avoid putting bugs into the database 2) people argue about whether bug 114 is really one bug or 3 separate bugs 3) people argue about whether bug 543 is a bug or an enhancement 4) people will log a bunch of trivial bugs, then immediately 'fix' them, so they look like they're doing impressive work 5) people won't work on the hard bugs, because no matter how much time it takes to fix it, it will only count as "1" fix, and the other guy who fixed 3 typos gets credit for "3" fixes. All of this is counterproductive. I've seen it happen in one company that put a giant paper graph on the wall with the bug count logged daily. The fights got progressively more acrimonious to the point where management finally wised up and stopped grading programmers on the bug count before total meltdown ensued. I had another experience where I once published the outstanding bug list on the C++ compiler as a service to the users of it. One lazy journalist then did a comparative compiler review, and his review of my compiler consisted of little more than a cut&paste of the bug list. I never did that again. These sorts of things is what made me very reluctant to use bugzilla for D. Fortunately, these days people seem to have moved past naive bug counts.
Bug count is probably more a measure of product maturity. :)
Feb 27 2008