"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4226033D.4030604@nospam.org...
> 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.

Good question.

I was fortunate, in doing D, to have available for ready use the optimizer and code generator from DMC++. This is very solid, as I've been maintaining it and improving it for 20+ years. It's very unusual for someone to find a bug in the code generator or optimizer, in either C++ or D. There's a very extensive test suite on it, essentially every fixed bug for the last 20 years is represented in the suite. I have a lot of confidence in that part of the compiler.

Garbage collectors tend to be a rich source of bugs. But I've gone through that learning curve years ago on other projects. D's gc is not cutting edge gc technology, but it is a good, solid, reliable implementation. It works.

Regular expressions are another potential problem area. But in poking around the internet I've found enough test vectors for it that I'm confident it works right.

The thread module is problematic, because I don't understand threads very well.

The rest of Phobos seems to be working well and is relatively trouble free.

That leaves the front end. The basics of the language - expression evaluation, statements, functions, classes, variables, all work well. The problems frequently come from things like poor error recovery after reporting a syntax error, and combinations of newer features I hadn't expected. The good news is that every bug that gets fixed gets represented in the test suite that gets run on every build. This has the effect that the compiler ratchets forward constantly, and problems that are fixed stay fixed. When I built DMDScript in D, which is a fairly large chunk of code, revealed really only a couple bugs in DMD (which got fixed).

Is D useable for serious development now? Yes.

Can I guarantee that there won't be any changes to the language that will break existing code? No. But I am very sensitive to this issue, I am extremely reluctant to introduce changes that will require more than minor editting to adapt to, and as much as possible there will be 'transition' versions of the compiler that will highlight what needs to be changed. An example of this is the switch from the (type)expr casting syntax to cast(type)expr. Both are allowed now, but the former generates a 'deprecated' error message.

"Walter" <newshound@digitalmars.com> wrote in message news:d04p7a$550$1@digitaldaemon.com...
>
> "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 a commercially viable language yet? IMO it is not.

I think 1.0 should be whenever it is.

The crux of that is how do we determine when it becomes so.

Any ideas on criteria?

Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?

"Linguo" <linguo@simpsons.invalid> wrote in message news:d04vu4$dvk$1@digitaldaemon.com...
> 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).

I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0?

Or something like that ...

I've been using D for about a year and half and it has steadily improved.  I use it now for various tasks and it works great.  They have all been relatively small ( under 15 modules ) , it would be interesting to hear from those who have done bigger projects in D ( Vathix, Kris, Ant -- where is Antonio btw ? ).

I can't speak for others but what _i'm_ waiting for to call D 1.0 is complete debug info , and a 95% or better on DStress.  I think the debug info is crucial , infact I think it was more crucial when D started ( make it easier to work out the bugs ) , but for 1.0 its a nessecity .

I think many of us have waited on a 1.0 to do a full blown campaign for D , so when it does hit 1.0 I expect it to gain ground fast.

What in your eyes ( Walter ) is needed for it to be 1.0 ?

Charlie




"Walter" <newshound@digitalmars.com> wrote in message news:d04son$9k2$1@digitaldaemon.com...
>
> "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.
>
>

> Is it a commercially viable language yet? IMO it is not.
>
> I think 1.0 should be whenever it is.

Well put.

> Any ideas on criteria?

I think DStress has setup a good 'score board'.  I like  your idea on getting people that aren't fans of the language, maybe time to setup a 'hostile focus group' :).

Charlie

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d056ph$lnj$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d04p7a$550$1@digitaldaemon.com...
> >
> > "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 a commercially viable language yet? IMO it is not.
>
> I think 1.0 should be whenever it is.
>
> The crux of that is how do we determine when it becomes so.
>
> Any ideas on criteria?
>
> Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?
>
>

Matthew wrote:
> 
> Is it a commercially viable language yet? IMO it is not.
> 
> I think 1.0 should be whenever it is.
> 
> The crux of that is how do we determine when it becomes so.
> 
> Any ideas on criteria?
> 

Walter has said he has his own bugs database. I'd say then, 1.0 would be all of the bugs (or most of them, I don't know) are fixed.

> Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?
> 
> 

_______________________
Carlos Santander Bernal

Matthew wrote:
> 
> I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0?
> 
> Or something like that ...
> 
> 
> 

I agree that 1.0 should wait for the book, but I think bug fixing should be a 1.0 goal and not 1.1.

_______________________
Carlos Santander Bernal

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?
> 
> Jason

Don't get discouraged because it isn't officially 1.0. As Anders recently said, version numbers don't mean that much nowadays. Also, as Walter said, what we have right now is basically a (decreasingly) buggy 1.0, because there won't be major changes.

So I'll say the same others have: just use D. If you can use it without experiencing problems, great. If you find bugs, just post them, and eventually/hopefully they'll be fixed. Usually there're work-arounds for the bugs.

Summing up, everything you do in D right now, will help D.

_______________________
Carlos Santander Bernal

"Carlos Santander B." <csantander619@gmail.com> wrote in message news:d058mj$ndf$1@digitaldaemon.com...
> Matthew wrote:
>>
>> Is it a commercially viable language yet? IMO it is not.
>>
>> I think 1.0 should be whenever it is.
>>
>> The crux of that is how do we determine when it becomes so.
>>
>> Any ideas on criteria?
>>
>
> Walter has said he has his own bugs database. I'd say then, 1.0 would be all of the bugs (or most of them, I don't know) are fixed.

I just think that's too narrow-minded, and open to bias. After all, who in the whole world is likely to be the least critical about D? ;$

We need the skeptics _in this group_ to be convinced before we've any hope of convincing people from without. As such, I think Walter's the absolute worst qualified to stipulate when D's ready to roll out. (Sorry, mate!)

That said, I don't think a sensible approach is to just randomly couch opinion from loud and opinionated types (such as me). I think we need something systematic (which I'm working on in a longer post I'm preparing now.)

Several times over the past few weeks I've said, in support of not-entirely-calm debates, that I don't feel that D is commercially ready.

Maybe the time has come for several/many of us to identify pet projects that we each have, and see if / how well some/all of them may be implemented in D.

For me, my projects are:

    shellext.com (http://shellext.com/)
    recls (http://recls.org/)
    Open-RJ (http://openrj.org/)
    STLSoft (http://stlsoft.org/)
    DTL
    b64 (http://synesis.com.au/software/)
    Synesis Software System Tools (http://synesis.com.au/systools.html)
    Arturius (http://arturius.org/ - not yet available in any form)

shellext.com - medium size, complete (for the moment)
------------

This is just a bunch of Windows shell extensions that I've done over the years. I don't think it's worth the costs in time for me to reimplement the existing ones in D, but I'd be happy to (try to) implement any new ones in it. All it needs are some requests/ideas, as the extant set pretty much covers my Windows shell needs.

recls - medium size, evolving
-----

This is a C/C++ project, and must remain so, since it's mapped to lots of different languages. It's sufficiently complex that I would be loathe to do separate implementations for different languages. (Note: this is about to have three new releases 1.5.3, 1.6.1 and 2.0 over the next few months, so expect std.recls in Phobos to _finally_ meet the documentation <g>)

Open-RJ - medium size, evolving
-------

This is a C project, with mappings to lots of different languages. Walter rejected the D mapping some time ago, and provided a 60% feature complete version if half a page of D: impressive. Since I can't let him outdo me, I will be doing the Open-RJ/D implementation entirely in D, sometime soonish.

STLSoft - large, evolving
-------

Walter's said to me many times that he hopes that I will gradually move STLSoft into D. Bits may come and go, but the philosophy of STLSoft is not entirely congruent with D.

DTL - large, currently inactive
----

Well, ahem, this is a D project. Just waiting for a clear desk for me to roll on it. Will most likely be driven by writing of DPD

b64 - very small, completed
----

Tiny little C library (with no dependencies on anything, which is nice!).

D already this, so not an issue.

System Tools - medium, stable
------------

Some of these would be excellent candidates for rewriting in D.

Arturius - large, pre-release development
--------

This is a compiler multiplexer, that is really useful and groovy, but not (yet) in a releasable state. I plan to use DMDScript in it, and also to write some of the filters in D. This'll receive more attention from me as it's going to be a dual proving ground for the research for "Extended STL" and for DPD. But it'll be some time ...



So, it looks to me like I (personally) will get a better feeling for D's commercial readiness by doing:

    Open-RJ/D (this is planned to happen in next month or two)
    implementing DTL and new Arturius filters (this will be happening
over next 2-3 months)
    any new (persuasive) Shell Extension requests
    maybe taking a couple of the system tools and reimplementing in D


None of these are huge projects - such as the size of Mango - apart from maybe DTL, but they would certainly inform, for me, on what I've been pontificating about over recent times.


May I suggest that others identify things that they are doing, or might do, in D, and we can identity a quorum of projects with which we can set D-1.0 acceptance criteria? Then we've got boxes to tick, which is nice ...


Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

Synesis Software Pty Ltd
P.O.Box 125
Waverley
New South Wales, 2024
Australia

-----------------------------------------------------