stability

Bill Baxter dnewsgroup at billbaxter.com
Sun Feb 24 16:22:04 PST 2008


Edward Diener wrote:
> Bill Baxter wrote:
>> Edward Diener wrote:
>>> Bill Baxter wrote:
>>>> Janice Caron wrote:
>>>>> On 24/02/2008, Derek Parnell <derek at 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



More information about the Digitalmars-d mailing list