In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>
>
>"Jason Mills" <jmills@cs.mun.ca> wrote in message news:d04ccv$2nh7$1@digitaldaemon.com...
>> I have been reading this newsgroup for several years. Although I post rarely I do read it every day. Early on I was so enthusiastic about D I could barely contain myself. I could not wait to use D at work, replacing C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a reality, improvements to C++ coming, together with existing versions of C# and Java, all with huge libraries ready to use out of the box, will D every be able to compete?
>
>I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?
>
>

What about releasing it along side the book you and Matthew are doing?  There could be things that come to light while writing the book that you may want to fix/add/improve upon.

(That said, I'm excersing some restraint here.  I'd like 1.0.  But I want it
bulletproof (I know nothing ever is, but you know what I mean <g>).

-Kramer

"jicman" <jicman_member@pathlink.com> wrote in message news:d04ru4$8l5$1@digitaldaemon.com...
>
> The questin is, what are you guys waiting for?

That is a very good question. Is it some crucial feature/bug lacking preventing using it for a major project, or is it concern that the language will change enough to cause any D source today to undergo major rewrites?

I can answer the latter concern - it isn't going to happen.

In article <4225EEA7.1030607@gmail.com>, clayasaurus says...
>
>Walter wrote:
>> "Jason Mills" <jmills@cs.mun.ca> wrote in message news:d04ccv$2nh7$1@digitaldaemon.com...
>> 
>>>I have been reading this newsgroup for several years. Although I post rarely I do read it every day. Early on I was so enthusiastic about D I could barely contain myself. I could not wait to use D at work, replacing C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a reality, improvements to C++ coming, together with existing versions of C# and Java, all with huge libraries ready to use out of the box, will D every be able to compete?
>> 
>> 
>> I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?
>> 
>> 
>
>I think D 1.0 is the day you are ready to make D public and face scrutinization from all those c++ programmers, and the day when people will start to think of D not as a concept but a serious language. Sure, you could call it 1.0 now, but are you ready for the aftermath? It would be tragic for the vast majority of people to try D 1.0, get a false impression from (insert bug/whatever) here, and never try it again.
>
>Then again, theoretically, the sooner D goes out the door, the better chance it may have to gain a foothold on the other c++ improvements (C#, Java), unless you think those languages arn't competitive to D and cater to different markets. (D seems to be for low level stuff, and Java C# high level GUI type stuff).
>
>If I were W, I would set a 1.0 date for D and release it with the book so that you will have the time to critically analize D and iron it out into a smooth machine, before the c++ programmer's can get ahold of it, critically anylize it, and try to dismiss it for (insert random drawback here). Cause ya know, from momentum, c++ is not going to be easily pushed aside for D.
>

I think those are some excellent thoughts!

I think I first noticed something about this "new language called D" back last Feb. or so, not all that long after I started on a project that made heavy use of C/++.

At the time, since I was in the process of investing a bunch of time becoming (hopefully) proficient (again) with the C/++ language, lib. and tools I'd be using, I dismissed it with all kinds of thoughts like "alot of features, ergo alot of baggage, ergo Java performance and portability issues, etc..".

All this to say that I was a skeptical C++ programmer who didn't give it much of a 2nd look until I got kind of tired of C/++ (again) and wanted to play a little and/or look for a better way. It's tough to let go of an 'in-demand' language like C++, esp. since it takes time and effort to get up to speed with.

There are probably many others out there like that who are or will be in the same boat, itching to try a new "better C++" language like D, but won't give it much of a chance unless the tools are stable and the tools do what a stable set of docs. say they should.

I think a good strategy for right now is to freeze the specs., make sure they are reflected accurately in stable docs. and fix the issues pertaining to the frozen v1.0 specs. that have been highlighted by DStress.

- Dave

"Walter" <newshound@digitalmars.com> wrote in message news:d04p7a$550$1@digitaldaemon.com...
> I've found myself wondering over the last few months what "1.0" actually
> is.
> Since D will undergo continuous improvement regardless, why don't we just
> drive a stake in the ground and call what we have "1.0"?

If you have a big enough helper base, I'd say you need to treat it like any other product and make sure the whole package is ready.  I get the impression that this still has the feel of a hobby project which means the team will get around to specs, better tutorials and bug fixes when they feel like it.  It's a fun stage, but I don't think it will work in the commercial/professional world.

You have to go from a project to a product.  I'm not a product manager, but I think a 'product' must assess what a customer needs to really feel comfortable with choosing D.  The language itself is probably only half of it.  I think the product will then include

* Is attitude correct?

    * Stop the moving target, or at least fake it.
        People don't like incomplete things.  Make it stationary and live
with it.  (See roadmap.)

    * got to make people feel supported, not like they are following a
temperamental hobbyist.

        * promise yourselves bugs will be fixed in an almost instant manner

        * create a newsgroup for support instead of feature debate

        * make sure you are ready to make real-world trade-offs
            see .Net below for example

* 'marketing' materials

    * clean up language comparison on D site

    * add to site a little; make friendlier

    * a confident roadmap
        features for 1.0, in stone
        features for 1.1, in stone, Fall 05
        features for 2.0, fixed but appendable, 2006
        (again, this should increase other's confidence)

* documentation

    * a complete spec
        no one is going to believe this is open (especially not slashdot)
until the spec is complete

    * a complete reference manual
        you have most of this on the site. get it cleaned and bound?

    * a complete programmer's manual
        keep it simple and non-didactic.  maybe keep it brief for
programmers who know C already.  maybe even for those who know C++ or Java.
A more thorough manual can probably be put off until next year.  still make
it a pdf and get it bound with the reference.

    * more tutorials
        especially ones written solving problems that the authors were
originally thinking of when they designed certain features.

* D
    no known bugs for 1.0

* a great library
    I think this should be most of the focus at this point.  I haven't
looked at phobos or dtl or whatever, but I think a major point for Java is
the promise that there is one main library with all you'll need to get
started.  Even though there were many mistakes in Date, AWT, etc.  And even
though any one with experience must roll their eyes at such a promise of
"one and only," this promise was huge to acceptance IMO.  (And it is
frustrating to work in C or Linux and have too many, similar choices of lib
and none seem to become a standard.)
    The promise of backward-compatibility with C libs is huge, but not
enough.
    Is the Java lib worth copying and only fixing the problems?  This would
probably provide comfort for lots of programmers.
    To combine the value of Java's inclusive libraries with C++'s generic
programming, you could create the ultimate container classes and let the
group fight it out for a month to get the spec perfect.  Anyone have ideas
on how other toolkits fell short in design (not just completeness)?  Now is
the time to fix that.
    Anyway, the lib should include most of all the components that the
original Java or .Net did.
    I think the world is still waiting on a wonderful GUI library.  The same
mistakes keep getting repeated.  It would be wonderful if D had it's own
amazing AWT with delegates, true objects but only when sensible, easy
parameterization, etc.  I have lots of thoughts in this area.

* does it work with .NET?
    Some may have ideological reasons against it, but this would be huge,
also.  It is the big "silver bullet" right now.  .Net has figured out that
it is all about libraries nowadays and you can use any lang to connect to
their libs.  So you both leverage all that programmer knowledge and you fit
in with the latest direction.  (I don't know .NET myself.)

Feel free to modify the list.  Discuss.  (-:

Walter wrote:
> "Jason Mills" <jmills@cs.mun.ca> wrote in message
> news:d04ccv$2nh7$1@digitaldaemon.com...
> 
>>I have been reading this newsgroup for several years. Although I post
>>rarely I do read it every day. Early on I was so enthusiastic about D I
>>could barely contain myself. I could not wait to use D at work,
>>replacing C++ and Java. I'm still patiently waiting for that day. With
>>C++/CLI soon a reality, improvements to C++ coming, together with
>>existing versions of C# and Java, all with huge libraries ready to use
>>out of the box, will D every be able to compete?
> 
> 
> I've found myself wondering over the last few months what "1.0" actually is.
> Since D will undergo continuous improvement regardless, why don't we just
> drive a stake in the ground and call what we have "1.0"?

Is it possible to wait till we get the regexps in D?

The it would be just so cool!

(I know, this is based on feeling only, but still?)

clayasaurus wrote:
<snip>
> I think D 1.0 is the day you are ready to make D public and face scrutinization from all those c++ programmers, and the day when people will start to think of D not as a concept but a serious language. Sure, you could call it 1.0 now, but are you ready for the aftermath? It would be tragic for the vast majority of people to try D 1.0, get a false impression from (insert bug/whatever) here, and never try it again.

Taken the words out of my mouth there.

I guess a good sign of progress is the DStress success rate.  As of 0.113 (the last column on the current DStress results page) it is 77%. I guess when it gets to 90% (by which time it'll be a slightly more realistic figure as more testcases'll have been added), it'll be time to look again at how ready for 1.0 we are.

> Then again, theoretically, the sooner D goes out the door, the better chance it may have to gain a foothold on the other c++ improvements (C#, Java), unless you think those languages arn't competitive to D and cater to different markets.

I guess that those languages both are competitive to D and cater to different markets.  To put it simply, there would be some overlap between the "Who D is For", "Who Java is For" and "Who C# is For" lists.  For example: "Programmers who enjoy the expressive power of C++ but are frustrated by the need to expend much effort explicitly managing memory and finding pointer bugs."

Before I discovered D I was pretty much a regular C++ user.  But I found myself doing some OOP stuff in Java, basically because certain OOP tasks (such as expression manipulation) benefit heavily from GC and seemed tricky to do in C++.  Now that we have D, it is my choice of language for similar purposes.

Of course, that might mean that "People who haven't discovered D" is one effective item on the "Who Java is For" list....

> (D seems to be for low level stuff, and Java C# high level GUI type
> stuff).

I personally guess D is for middle-level stuff....

> If I were W, I would set a 1.0 date for D and release it with the book so that you will have the time to critically analize D and iron it out into a smooth machine, before the c++ programmer's can get ahold of it, critically anylize it, and try to dismiss it for (insert random drawback here). Cause ya know, from momentum, c++ is not going to be easily pushed aside for D.

You're probably right.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Kramer" <Kramer_member@pathlink.com> wrote in message news:d04s2v$8sj$1@digitaldaemon.com...
> What about releasing it along side the book you and Matthew are doing?
There
> could be things that come to light while writing the book that you may
want to
> fix/add/improve upon.

That is a good idea, but books take a long time to write and even longer to publish. It's too far out.

> (That said, I'm excersing some restraint here.  I'd like 1.0.  But I want
it
> bulletproof (I know nothing ever is, but you know what I mean <g>).

I know what you mean. I've put a lot of priority on fixing all the crashers. Nothing gives a negative impression like crashing.

clayasaurus wrote:
> Then again, theoretically, the sooner D goes out the door, the better chance it may have to gain a foothold on the other c++ improvements (C#, Java), unless you think those languages arn't competitive to D and cater to different markets. (D seems to be for low level stuff, and Java C# high level GUI type stuff).

Then again, theoretically, the sooner D goes out of the door, the better chance it may have to gain a foothold on the other C++ improvements (C# and Java), unless you think those languages aren't competitive with D and cater for different markets.  (D seems to be for low-level stuff, and Java and C# for high-level GUI-type stuff.)

> If I were W, I would set a 1.0 date for D and release it with the book so that you will have the time to critically analize D and iron it out into a smooth machine, before the c++ programmer's can get ahold of it, critically anylize it, and try to dismiss it for (insert random drawback here).

If I were W, I would set a 1.0 date for D and release it with the book, so that I would have the time to critically analyse D and iron it out into a smooth machine, before the C++ programmers can get hold of it, critically analyse it, and try to dismiss it for (insert random drawback here).

Jason Mills wrote:
> I have been reading this newsgroup for several years. Although I post rarely I do read it every day. Early on I was so enthusiastic about D I could barely contain myself. I could not wait to use D at work, replacing C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a reality, improvements to C++ coming, together with existing versions of C# and Java, all with huge libraries ready to use out of the box, will D every be able to compete?

Hmm. A few thoughts:

How bug free is DMD right now?

Is it true that "average programs" (i.e. what anyone would write using Pascal, regular C, or the _average_ programmer using C++) can now be programmed without any fear of compiler bugs or the binary doing unexpedted things?

How would you (= Walter, Kris, Matthew, and the others who've done a lot of D coding) rate D now, say, against "the average C++ compilers of today"?
I'm not talking about rating as in the recent thread, just reliability.

And I'm _not_ talking about libraries, not even Phobos. Just the compiler itself. And _no_ templates, delegates or other Fine stuff -- just Regular Programming related.

"Charlie Patterson" <charliep1@excite.com> wrote in message news:d04ugr$c1t$1@digitaldaemon.com...
> Feel free to modify the list.  Discuss.  (-:

Some very good points.

Documentation:

If someone wants to go through the current spec with a critical eye, and send me a detailed critique on it (or at least focus on some particular part of it), so that can be improved, it would be a big help. I go through it from time to time, each time noticing new things and fixing them, but reviewing one's own writing is not so effective since one sees what one intended to write, not what is actually there.

Library:

Microsoft and Sun pour resources into libraries for .net and Java. I don't have those resources. I can do the basic core library, and I'm reasonably happy with it in Phobos. But more thorough libraries are going to have to come from the D community, for example Kris' Mango library, Vathix's socket routines, and Matthew's recls. There may be a chicken and egg thing with writing libraries - people may hold back on expending the considerable effort of doing one because D isn't 1.0, and yet consider D not 1.0 ready without it. This kind of motivates me to drive the stake in the ground now and call it 1.0.

Some libraries for certain areas can only be written by someone who has a consuming interest in that segment, they can't be casually done. For example, std.regexp needed a complex and intense focus to get it written, tested, and debugged. Doing that had little to do with D itself, it being coded in D is pretty much incidental.

Some stuff only I can reasonably do because it is tightly coupled with the compiler, such as the associative array implementation. But that kind of stuff is complete, and ready to rock.

When I look at, say, Python's libraries, I think we've got the essential stuff covered except for a standard gui library.