• ddj (1/1) Dec 13 2014 You already have better D1.
• Rikki Cattermole (6/7) Dec 13 2014 The usage of c++ for dmd front end is the original language for it. Aka
• ddj (5/13) Dec 13 2014 But then you miss all great features of D, all protection from
• ketmar via Digitalmars-d (11/12) Dec 13 2014 as D2 wasn't created from the scratch, it was easier to reuse already
• ddj (15/33) Dec 13 2014 Replacing unsupported D1 with unfinished D2 does not seem to me
• ketmar via Digitalmars-d (14/21) Dec 13 2014 that's right. we need D3, 'cause D2 is cluttered with legacy crap. ;-)
• ddj (9/26) Dec 13 2014 Unfortunately it is unclear to me how many current bugs/issues
• ketmar via Digitalmars-d (22/34) Dec 13 2014 there are some fixes that are going to 2.066, and there is the plan to
• ddj (1/13) Dec 13 2014 Thanks
• Mike Parker (4/5) Dec 13 2014 That's just the wrong way to look at it. Take a look at the bug list for...
• ddj (4/10) Dec 14 2014 Maybe, but gcc and java compilers have long history of stable
• uri (12/25) Dec 14 2014 As Mike said, look at the bug tracker history for these projects.
• Paulo Pinto (6/33) Dec 14 2014 Aren't you using certified compilers?
• ddj (12/39) Dec 15 2014 Actually, I think OSS too often has poor quality code. New

"ddj" <ddj nospam.org> writes:

You already have better D1.

Rikki Cattermole <alphaglosined gmail.com> writes:

On 14/12/2014 12:38 a.m., ddj wrote:
 You already have better D1.

The usage of c++ for dmd front end is the original language for it. Aka 
it would be rather hard to write a front end for D without a D compiler.
Its currently being ported over to D.

As for why it wasn't changed over when D2 started. Probably was seen as 
too much work at the time.

"ddj" <ddj nospam.org> writes:

But then you miss all great features of D, all protection from 
bugs that D offers, like contracts and tests! Initial saving time 
cost more in long term


On Saturday, 13 December 2014 at 12:19:19 UTC, Rikki Cattermole 
wrote:
 On 14/12/2014 12:38 a.m., ddj wrote:
 You already have better D1.

 The usage of c++ for dmd front end is the original language for 
 it. Aka it would be rather hard to write a front end for D 
 without a D compiler.
 Its currently being ported over to D.

 As for why it wasn't changed over when D2 started. Probably was 
 seen as too much work at the time.

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 13 Dec 2014 11:38:47 +0000
ddj via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You already have better D1.

as D2 wasn't created from the scratch, it was easier to reuse already
written c++ code. there is no big difference in having D2 compiler
written in c++ or in D1, both of them are not D2. DMD c++ is very close
to "restricted c with classes" with banned STL, templates, multiple
inheritance and so on. so it doesn't really matters.

besides, having it written in D1 means that D1 compiler must be
supported all this time, making devs effectively support TWO D versions
instead of one. and by using c++ devs can "outsource" c++ support to
another teams. ;-)

"ddj" <ddj nospam.org> writes:

Replacing unsupported D1 with unfinished D2 does not seem to me 
like good idea for language.

I like D, and I wish to learn it and use it.

But so many issues and bug fixes scares me from using it.

High activity in the project to me does not look like sign of 
good support, more like unstable and buggy implementation. Maybe 
problem is in implementation language you want to replace? I 
guess, best test for language is compiler bootstrapping. 
http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

IMHO, if you want million of users, at least no new feature 
should be added before number of issues and bug fixes stabilize 
to about one per month

Thanks

On Saturday, 13 December 2014 at 12:27:01 UTC, ketmar via 
Digitalmars-d wrote:
 On Sat, 13 Dec 2014 11:38:47 +0000
 ddj via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You already have better D1.

 as D2 wasn't created from the scratch, it was easier to reuse 
 already
 written c++ code. there is no big difference in having D2 
 compiler
 written in c++ or in D1, both of them are not D2. DMD c++ is 
 very close
 to "restricted c with classes" with banned STL, templates, 
 multiple
 inheritance and so on. so it doesn't really matters.

 besides, having it written in D1 means that D1 compiler must be
 supported all this time, making devs effectively support TWO D 
 versions
 instead of one. and by using c++ devs can "outsource" c++ 
 support to
 another teams. ;-)

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 13 Dec 2014 13:55:27 +0000
ddj via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Replacing unsupported D1 with unfinished D2 does not seem to me=20
 like good idea for language.

that's right. we need D3, 'cause D2 is cluttered with legacy crap. ;-)

 But so many issues and bug fixes scares me from using it.

nobody forces you to use current developement versions. stick with the
version of your choice (2.066 for example), that's all.

 I guess, best test for language is compiler bootstrapping.=20

there is ongoing project to convert DMD frontend to D. eventually this
new frontend will replace the old c++ one.

 IMHO, if you want million of users, at least no new feature=20
 should be added before number of issues and bug fixes stabilize=20
 to about one per month

not all D programmers wants "millon of users". i, for example, want a
language which will be great for me, not for "million of users". that's
why i think that D developement is very slow, "don't break the existing
code" is overrated and c++ interoperbility is on the bottom of the
list. but this is my own opinion, and i'm not even a major contributor.

what i want to say is that D community consists of many groups with
different visions, so it's hard to say what "we" exactly want. ;-)

"ddj" <ddj nospam.org> writes:

 nobody forces you to use current developement versions. stick 
 with the
 version of your choice (2.066 for example), that's all.

Unfortunately it is unclear to me how many current bugs/issues 
are related to stable version. On another side, I do not like to 
use stable but crippled version


 not all D programmers wants "millon of users". i, for example, 
 want a
 language which will be great for me, not for "million of 
 users". that's
 why i think that D developement is very slow, "don't break the 
 existing
 code" is overrated and c++ interoperbility is on the bottom of 
 the
 list. but this is my own opinion, and i'm not even a major 
 contributor.

 what i want to say is that D community consists of many groups 
 with
 different visions, so it's hard to say what "we" exactly want. 
 ;-)

I've seen many YouTube videos about D and as far a I can remember 
"million users" is at least Walter&Andre's wish. That is maybe 
good only for the Amazon books? :)

AFAIK c++ binary interoperability is very difficult problem due 
to different c++ compiler implementations.

Thanks

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 13 Dec 2014 14:48:03 +0000
ddj via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 nobody forces you to use current developement versions. stick=20
 with the
 version of your choice (2.066 for example), that's all.

=20
 Unfortunately it is unclear to me how many current bugs/issues=20
 are related to stable version. On another side, I do not like to=20
 use stable but crippled version

there are some fixes that are going to 2.066, and there is the plan to
eventually release 2.066.1 (already here), 2.066.2, etc. with those
fixes incorporated. so it should be fairly good to just stick with 2.066
and upgrade it when new minor version released, if you don't need that
shiny new features (and bugs ;-).

 I've seen many YouTube videos about D and as far a I can remember=20
 "million users" is at least Walter&Andre's wish. That is maybe=20
 good only for the Amazon books? :)

Walter and Andrei aren't the whole community. ;-) yes, they are project
leaders, but not anyone in community is always agree with them. ;-)

we are lacking manpower too, so some things has to be postponed. there
is not so many people who can donate their time to supporting old
compiler verions for example, so we can't support all released versions
to the extent we want to. it's much funnier to work on new features. ;-)

yet that things must be solved somehow, and community trying to do it's
best. there are plans to do better release cycle, better support and so
on. but almost all of that work is done by volunteers, so things aren't
rolling fast. this is the downside of being independent. ;-)

 AFAIK c++ binary interoperability is very difficult problem due=20
 to different c++ compiler implementations.

yes, there are alot of problems to solve -- that's why D doesn't have
it fully working from the start. but there is alot of work done in
current dev DMD, including different c++ mangling schemes, ABIs and so
on. i'm not really in position to talk about that though, as i'm not
interested in c++ at all.

"ddj" <ddj nospam.org> writes:

 Unfortunately it is unclear to me how many current bugs/issues 
 are related to stable version. On another side, I do not like 
 to use stable but crippled version

 there are some fixes that are going to 2.066, and there is the 
 plan to
 eventually release 2.066.1 (already here), 2.066.2, etc. with 
 those
 fixes incorporated. so it should be fairly good to just stick 
 with 2.066
 and upgrade it when new minor version released, if you don't 
 need that
 shiny new features (and bugs ;-).

Thanks

Mike Parker <aldacron gmail.com> writes:

On 12/13/2014 10:55 PM, ddj wrote:

 But so many issues and bug fixes scares me from using it.

That's just the wrong way to look at it. Take a look at the bug list for 
gcc, any of the Java compilers, or clang. Are you afraid to use them as 
well?

"ddj" <ddj nospam.org> writes:

On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker wrote:
 On 12/13/2014 10:55 PM, ddj wrote:

 But so many issues and bug fixes scares me from using it.

 That's just the wrong way to look at it. Take a look at the bug 
 list for gcc, any of the Java compilers, or clang. Are you 
 afraid to use them as well?

Maybe, but gcc and java compilers have long history of stable 
releases and many programs and libraries written. Clang has 
standards to implement and! static analyzer.

"uri" <uri gmail.com> writes:

On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote:
 On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker 
 wrote:
 On 12/13/2014 10:55 PM, ddj wrote:

 But so many issues and bug fixes scares me from using it.

 That's just the wrong way to look at it. Take a look at the 
 bug list for gcc, any of the Java compilers, or clang. Are you 
 afraid to use them as well?

 Maybe, but gcc and java compilers have long history of stable 
 releases and many programs and libraries written. Clang has 
 standards to implement and! static analyzer.

As Mike said, look at the bug tracker history for these projects. 
Even with all those stable releases there were always lots of 
open bugs and today in GCC 4.9 there are issues:

http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html

We use GCC 4.8 at my work where we develop class II and class III 
health-care devices - A life support system is class III...how 
well do you trust GCC? :-).

Joking aside we design for failure and have a 4 year verification 
process that weeds out critical bugs in our code and the compiler.

Cheers,
uri

"Paulo Pinto" <pjmlp progtools.org> writes:

On Monday, 15 December 2014 at 00:58:29 UTC, uri wrote:
 On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote:
 On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker 
 wrote:
 On 12/13/2014 10:55 PM, ddj wrote:

 But so many issues and bug fixes scares me from using it.

 That's just the wrong way to look at it. Take a look at the 
 bug list for gcc, any of the Java compilers, or clang. Are 
 you afraid to use them as well?

 Maybe, but gcc and java compilers have long history of stable 
 releases and many programs and libraries written. Clang has 
 standards to implement and! static analyzer.

 As Mike said, look at the bug tracker history for these 
 projects. Even with all those stable releases there were always 
 lots of open bugs and today in GCC 4.9 there are issues:

 http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html

 We use GCC 4.8 at my work where we develop class II and class 
 III health-care devices - A life support system is class 
 III...how well do you trust GCC? :-).

 Joking aside we design for failure and have a 4 year 
 verification process that weeds out critical bugs in our code 
 and the compiler.

 Cheers,
 uri

Aren't you using certified compilers?

It was my understanding that for life support systems only 
certified compilers are allowed.

..
Paulo

"ddj" <ddj nospam.org> writes:

On Monday, 15 December 2014 at 00:58:29 UTC, uri wrote:
 On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote:
 On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker 
 wrote:
 On 12/13/2014 10:55 PM, ddj wrote:

 But so many issues and bug fixes scares me from using it.

 That's just the wrong way to look at it. Take a look at the 
 bug list for gcc, any of the Java compilers, or clang. Are 
 you afraid to use them as well?

 Maybe, but gcc and java compilers have long history of stable 
 releases and many programs and libraries written. Clang has 
 standards to implement and! static analyzer.

 As Mike said, look at the bug tracker history for these 
 projects. Even with all those stable releases there were always 
 lots of open bugs and today in GCC 4.9 there are issues:

 http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html

 We use GCC 4.8 at my work where we develop class II and class 
 III health-care devices - A life support system is class 
 III...how well do you trust GCC? :-).

 Joking aside we design for failure and have a 4 year 
 verification process that weeds out critical bugs in our code 
 and the compiler.

 Cheers,
 uri

Actually, I think OSS too often has poor quality code. New 
features are continuously and unnecessary added, often breaking 
"stable" code. With exception of academic projects, I guess.

Long verification process is exactly what I wish to prevent.
While debugging my code, last thing I want to find is compiler 
bug.


code (and branch!) coverage, pex .. and I wish to repeat that 
experience with D at higher execution speed. On OSS IDE like 
Sharp/Mono Develop.

Thanks