Is D 0.163 D 1.0?

[Dave]

Reiner Pope wrote:
> Peter C. Chapin wrote:
> 
>> It seems to me that an official 1.0 release will encourage library 
>> writers who might be waiting for D to stablize before investing too 
>> much time creating libraries for it. Everyone knows that "1.0" means 
>> "first cut." I don't think extensive libraries are necessary at this 
>> point. Relative stability of language features, however, would be 
>> desirable so that extensive libraries could be created without too 
>> much reworking later on.
>>
>> Peter
> 
> Not trying to be too argumentative here, but I obviously disagree with 
> what you said, otherwise I wouldn't have said it in the first place. The 
> problem is that the more *big* releases you make, the less interest 
> people take in the language, so it's a good idea too catch their 
> interest from the start. I disagree that "1.0" means first cut, because 
> in many OSS projects (which D effectively is), version numbers don't get

I wonder about that. I'd be willing to bet that the most popular OSS 
projects were all past 1.0 before they became really popular, especially 
languages, compilers and/or runtimes. Perl is at 5.6, Python is at 2.5, 
Ruby is at 1.8 (but that's deceptive), Java is at (effectively) about 
version 5. D has been at this for about 5-6 years, about the same amount 
of time for C++ and Java before they became "commercial quality" hits.

GCC wasn't considered stable enough for "real work" until v2.9.x or so, 
and GCC implemented pre-defined languages, not new ones. I get the 
feeling that G++ wasn't considered ready for prime time until 3.3.x or so.

> to 2.0 or beyond. IMHO it really means, "we've got a complete product 

IIRC, Walter has recently stated that D is already as stable as many 
compilers out there. We happen to have a highly visible bug list and 
regression tests that probably make things look worse than they really 
are _relative to other compilers_ who don't publish this stuff. In other 
words by objective measurement we may already have a "complete product" 
as far as the compilers and language spec. go.

> now, you should have no problems with it." So if someone believes this 

Version 5 of Perl was "the one". Before that (IIRC) there were a lot of 
quality issues, and after v5 the number and quality of Perl libs. has 
exploded.

> and then finds that it doesn't come with the built-in libraries they 
> wanted, all of a sudden D is going to use a potential user, because 

I think there have probably been many people who've given D the once 
over and said "interesting, but v0.1xx - too early" and not taken a 
second look or tried it. If they had tried it I think they would've 
probably seen that it was stable enough to contribute a few library 
functions for. In other words, the libs. aren't going to come until 
after many people try it, but many people won't try it until after v1.0 
because they won't spend the time on something they see as "alpha quality".

> they're not likely to come back and try again later unless they were 
> _extremely_ dedicated.
> 

I think most of us who've tried D would profess that once you try it 
there are so many advantages to it that it is definitely worth watching. 
The problem has been that people see "v0.1xx" with a cursory look and 
decide "it's not even in alpha yet" by virtue of the version number.

A stable language def. labeled v1.x will encourage the library 
development, IMHO.

Here's how I see things playing out, I could be wrong of course:

a) D at v1.0, people start writing small programs best done in C but 
done in scripting languages now because of the built-in arrays, etc.
b) As more small programs are developed, they will inspire lib. 
development and larger programs.
c) D with large, high-quality libs. developed in the crucible of real 
world usage will take over the world <g>

One of the great things about Java early on was the huge libraries. One 
of the worst things about the huge libraries was that much of them were 
buggy and very slow and had to be re-written anyhow. The first Java 
libs. synchronized everything, so then subsequent releases had to 
introduce new objects that weren't synchronized and people had to 
re-write code to take advantage of them and now the non-synchronized 
versions are probably used more often than the original in many cases. 
In the meantime Java got the reputation as very slow in large part 
because of all of the synchronized objects - D can't afford something 
like that either.

> Cheers,
> 
> Reiner