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