As so many have written about 1.0 I feel the urgent need to add my $0.02

First of all I do not care about when D 1.0 will be released. This is totally unimportant to me (within a plausible time range of 3-12 months from now, of course). The only really important thing is:

  * post-1.00-changes to the compiler must NOT break 1.00 code

I just revived some 0.79 test code and I had to insert a lot of casts and change all op-overloading methods. Also function parameter type matching seems to have changed, for float expressions won't match with a long parameter function signature anymore (more casts!).

While these changes may make sense it was frustrating work for nothing. It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01

I know at least 3 contributors who struggled through the undig project to bring it up to date with dmd 0.1xx. After removing formal errors some examples still won't work (as they did some time ago; problems in Windows API interfacing?).

The bottom line is: whatever you wish for 1.00 it will be of no significance
if the code written for dmd 1.00 will not compile and execute flawlessly in the
dmd 3.27 of 2010. So its not so much about what features to include now,
but about when to restrict the headroom for fundamental changes.

BTW my best guess is that 0.127 will be 1.00
I'm thinking about a website where you can place your bets!  :-)

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <413C702D.9F2A116@hls.via.at>, Helmut Leitner says...
>
>As so many have written about 1.0 I feel the urgent need to add my $0.02
>
>First of all I do not care about when D 1.0 will be released. This is totally unimportant to me (within a plausible time range of 3-12 months from now, of course). The only really important thing is:
>
>  * post-1.00-changes to the compiler must NOT break 1.00 code
>
>I just revived some 0.79 test code and I had to insert a lot of casts and change all op-overloading methods. Also function parameter type matching seems to have changed, for float expressions won't match with a long parameter function signature anymore (more casts!).
>
>While these changes may make sense it was frustrating work for nothing. It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01
>
>I know at least 3 contributors who struggled through the undig project to bring it up to date with dmd 0.1xx. After removing formal errors some examples still won't work (as they did some time ago; problems in Windows API interfacing?).
>
>The bottom line is: whatever you wish for 1.00 it will be of no significance
>if the code written for dmd 1.00 will not compile and execute flawlessly in the
>dmd 3.27 of 2010. So its not so much about what features to include now,
>but about when to restrict the headroom for fundamental changes.
>

I agree that v1.0 should not be released until the fundemental issues are settled.

Not to minimize the potential for the impact of language changes to legacy code, but I think some of these concerns post-v1.0 are taken into account with features of the language (ie: Versioning) and DMD reference compiler (ie: -d switch).

I was curious about the progress of D compared to other languages and it seems that it is actually coming along very well compared to Java, C and C++.

http://www.ils.unc.edu/blaze/java/javahist.html http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the library and also did the bulk of the language design. If I remember correctly (and someone please correct me if I'm wrong), but the design didn't start until late '99 and the implementation in earnest probably late 2001/early 2002.

I know there are concerns about the state of the library too, but all-in-all I think that is doing pretty well at this stage (a big THANKS to those developers).

I'm impatient for the release - I want to get on with turning out production code with it! But I can wait a few months to let things stabilize with the language and compiler and for the libraries to mature too.

>BTW my best guess is that 0.127 will be 1.00
>I'm thinking about a website where you can place your bets!  :-)
>

IMO, one thing that doesn't get a whole lot of mention in these groups is performance and maybe rightly so for the time being, as long as it is given some attention before the release of v1.0.

Although I personally might be guilty of putting /too/ much stock in screaming performance, I think Java and C++ history is on the side of spending at least a little time - once the compiler and language is stable - on optimizing things before v1.0 is released. I think waiting until 0.130 <g> or so for that would do D users and the language (in terms of acceptance) a lot of good. Once a language gets tagged with performance issue, it seems about half the potential converts walk away and don't look back for a couple of years.

I almost hate to mention it at this point, but the AMD64 stuff seems to be really taking off (I'm actually using it everyday) and some code gen. support for that should be in v1.1 or maybe v1.01 <g>. Good support for that right out of the gate w/ v1.0 may be a big differentiator for the language and DMD compiler too, but perhaps that is asking way to much of Walter..

- Dave

>-- 
>Helmut Leitner    leitner@hls.via.at
>Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> As so many have written about 1.0 I feel the urgent need to add my $0.02
> 
> First of all I do not care about when D 1.0 will be released. This is
> totally unimportant to me (within a plausible time range of 3-12 months
> from now, of course). The only really important thing is:
> 
>   * post-1.00-changes to the compiler must NOT break 1.00 code
> 
> I just revived some 0.79 test code and I had to insert a lot of casts
> and change all op-overloading methods. Also function parameter type matching seems to have changed, for float expressions won't match with
> a long parameter function signature anymore (more casts!). 
> 
> While these changes may make sense it was frustrating work for nothing. It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01
> 
> I know at least 3 contributors who struggled through the undig project to
> bring it up to date with dmd 0.1xx. After removing formal errors some
> examples still won't work (as they did some time ago; problems in Windows API interfacing?). 
> 
> The bottom line is: whatever you wish for 1.00 it will be of no significance if the code written for dmd 1.00 will not compile and execute flawlessly in the dmd 3.27 of 2010. So its not so much about what features to include now,
> but about when to restrict the headroom for fundamental changes.
> 
> BTW my best guess is that 0.127 will be 1.00
> I'm thinking about a website where you can place your bets!  :-)

I think it's really important that this /not/ strictly be the case. Time is a heck of a good teacher, and D needs to be able to take advantage of the lessons it offers.

What would be quite possible is to define a standard pragma to declare the version of D a module was written for.  Compiler implementations are then free to either error out elegantly, spew out a warning, or even shift gears and compile the older version of the spec.  A good compiler implementation, then, would be able to handle ten year old code without any issues, and all without forcing D into the same downward spiral that doomed C. :)

Incompatible changes are still a big deal, of course, but if, for example, the D group were to decide that a boolean type is in fact necessary, they should be allowed to break existing code and add a 'boolean' keyword instead of being forced to use something like '__Boolean' and define all sorts of implicit conversions just to preserve the behaviour of existing code.

Of course, incompatible changes within a major version (1.1, 1.2, etc) should be forbidden: breaking existing code is pretty major. :)

 -- andy

Good points. Regarding performance:

Support for AMD64 would likely boost performance right away ~ due to the additional registers available. D is actually pretty fast right now, although there are specific areas that are lacking (vectorized array processing; the ever-present and sometimes long-winded array initialization; etc).

On the other hand, with careful design you can craft D code that's quite a bit faster than the average-bear. For example, array slicing can speed up a text-oriented process significantly (it's much easier to do this in D than any other language I'm familiar with),  so it really depends upon the task at hand.

Would like to see it get better though! I recall that Valgrind showed D to have almost twice as many load/store ops as an equivalent C implementation for some test or other. While that's not indicative of a non-performant language, it does suggest a predilection for register spills (or something). Perhaps array initialization caused all those additional memory references <g>


"Dave" <Dave_member@pathlink.com> wrote in message
news:chi0i0$1fb5$1@digitaldaemon.com...
In article <413C702D.9F2A116@hls.via.at>, Helmut Leitner says...
>
>As so many have written about 1.0 I feel the urgent need to add my $0.02
>
>First of all I do not care about when D 1.0 will be released. This is totally unimportant to me (within a plausible time range of 3-12 months from now, of course). The only really important thing is:
>
>  * post-1.00-changes to the compiler must NOT break 1.00 code
>
>I just revived some 0.79 test code and I had to insert a lot of casts and change all op-overloading methods. Also function parameter type matching seems to have changed, for float expressions won't match with a long parameter function signature anymore (more casts!).
>
>While these changes may make sense it was frustrating work for nothing. It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01
>
>I know at least 3 contributors who struggled through the undig project to bring it up to date with dmd 0.1xx. After removing formal errors some examples still won't work (as they did some time ago; problems in Windows API interfacing?).
>
>The bottom line is: whatever you wish for 1.00 it will be of no
significance
>if the code written for dmd 1.00 will not compile and execute flawlessly in
the
>dmd 3.27 of 2010. So its not so much about what features to include now, but about when to restrict the headroom for fundamental changes.
>

I agree that v1.0 should not be released until the fundemental issues are settled.

Not to minimize the potential for the impact of language changes to legacy
code,
but I think some of these concerns post-v1.0 are taken into account with
features of the language (ie: Versioning) and DMD reference compiler (ie: -d
switch).

I was curious about the progress of D compared to other languages and it
seems
that it is actually coming along very well compared to Java, C and C++.

http://www.ils.unc.edu/blaze/java/javahist.html http://www.intap.net/~drw/cpp/cpp01_03.htm

Especially considering /one person/ is doing the compiler, much of the
library
and also did the bulk of the language design. If I remember correctly (and
someone please correct me if I'm wrong), but the design didn't start until
late
'99 and the implementation in earnest probably late 2001/early 2002.

I know there are concerns about the state of the library too, but all-in-all
I
think that is doing pretty well at this stage (a big THANKS to those
developers).

I'm impatient for the release - I want to get on with turning out production code with it! But I can wait a few months to let things stabilize with the language and compiler and for the libraries to mature too.

>BTW my best guess is that 0.127 will be 1.00
>I'm thinking about a website where you can place your bets!  :-)
>

IMO, one thing that doesn't get a whole lot of mention in these groups is
performance and maybe rightly so for the time being, as long as it is given
some
attention before the release of v1.0.

Although I personally might be guilty of putting /too/ much stock in
screaming
performance, I think Java and C++ history is on the side of spending at
least a
little time - once the compiler and language is stable - on optimizing
things
before v1.0 is released. I think waiting until 0.130 <g> or so for that
would do
D users and the language (in terms of acceptance) a lot of good. Once a
language
gets tagged with performance issue, it seems about half the potential
converts
walk away and don't look back for a couple of years.

I almost hate to mention it at this point, but the AMD64 stuff seems to be
really taking off (I'm actually using it everyday) and some code gen.
support
for that should be in v1.1 or maybe v1.01 <g>. Good support for that right
out
of the gate w/ v1.0 may be a big differentiator for the language and DMD
compiler too, but perhaps that is asking way to much of Walter..

- Dave

>--
>Helmut Leitner    leitner@hls.via.at
>Graz, Austria   www.hls-software.com

I agree that we must create a good standard now that needs not much changing later. And I think it is very important to make a collection of RESERVED WORDS. To think carefully, what things might be in future dmd releases and to reserve words for them.

I would suggest that we reserve everything beginning with d_ (d_in, d_with,
d_style, d_whatever ...)
Then we can take kewords whenever we want to without breaking any existing code.


And I think we should have a public discussion about what words should be reserved.


In article <413C702D.9F2A116@hls.via.at>, Helmut Leitner says...
>
>As so many have written about 1.0 I feel the urgent need to add my $0.02
>
>First of all I do not care about when D 1.0 will be released. This is totally unimportant to me (within a plausible time range of 3-12 months from now, of course). The only really important thing is:
>
>  * post-1.00-changes to the compiler must NOT break 1.00 code
>
>I just revived some 0.79 test code and I had to insert a lot of casts and change all op-overloading methods. Also function parameter type matching seems to have changed, for float expressions won't match with a long parameter function signature anymore (more casts!).
>
>While these changes may make sense it was frustrating work for nothing. It is acceptable to me in 0.xxx but would not be going from 1.00 to 1.01
>
>I know at least 3 contributors who struggled through the undig project to bring it up to date with dmd 0.1xx. After removing formal errors some examples still won't work (as they did some time ago; problems in Windows API interfacing?).
>
>The bottom line is: whatever you wish for 1.00 it will be of no significance
>if the code written for dmd 1.00 will not compile and execute flawlessly in the
>dmd 3.27 of 2010. So its not so much about what features to include now,
>but about when to restrict the headroom for fundamental changes.
>
>BTW my best guess is that 0.127 will be 1.00
>I'm thinking about a website where you can place your bets!  :-)
>
>-- 
>Helmut Leitner    leitner@hls.via.at
>Graz, Austria   www.hls-software.com

>I was curious about the progress of D compared to other languages and it seems that it is actually coming along very well compared to Java, C and C++.
>
>http://www.ils.unc.edu/blaze/java/javahist.html http://www.intap.net/~drw/cpp/cpp01_03.htm
>
>Especially considering /one person/ is doing the compiler, much of the library and also did the bulk of the language design. If I remember correctly (and someone please correct me if I'm wrong), but the design didn't start until late '99 and the implementation in earnest probably late 2001/early 2002.

Yes, but D didn't invent too much new stuff. It's just a mix of several languages with VERY few own ideas.

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:chifup$1m9j$1@digitaldaemon.com...
> >I was curious about the progress of D compared to other languages and it
seems
> >that it is actually coming along very well compared to Java, C and C++.
> >
> >http://www.ils.unc.edu/blaze/java/javahist.html http://www.intap.net/~drw/cpp/cpp01_03.htm
> >
> >Especially considering /one person/ is doing the compiler, much of the
library
> >and also did the bulk of the language design. If I remember correctly
(and
> >someone please correct me if I'm wrong), but the design didn't start
until late
> >'99 and the implementation in earnest probably late 2001/early 2002.
>
> Yes, but D didn't invent too much new stuff. It's just a mix of several languages with VERY few own ideas.

D does have some significant novel ideas, like its approach to utf strings, how foreach works, mixins, arrays, etc. But it isn't intended to be loaded with novel ideas, it's a refactoring and refinement of existing and proven ideas. D is an engineering job, not an academic research project.

>D does have some significant novel ideas, like its approach to utf strings, how foreach works, mixins, arrays, etc. But it isn't intended to be loaded with novel ideas, it's a refactoring and refinement of existing and proven ideas. D is an engineering job, not an academic research project.

Mixins are just like C-Macros with nicer synthax and less abilities. The way arrays are done isn't realy a "significant novel idea", is it?

Anyway I didn't say anithing negative about D. I just said, that there anren't any revolutionary ideas or anything like that.

antiAlias wrote:
> 
> I agree that v1.0 should not be released until the fundemental issues are settled.
> 

That was not my point - D may develop any way...
... BUT developments must not break 1.00 code.

Imagine for example an introductory book containing examples that won't run half a year later - a desaster for the author of the book, the frustrated readers and the language.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <chjude$2ab3$1@digitaldaemon.com>, Matthias Becker says...
>
>>D does have some significant novel ideas, like its approach to utf strings, how foreach works, mixins, arrays, etc. But it isn't intended to be loaded with novel ideas, it's a refactoring and refinement of existing and proven ideas. D is an engineering job, not an academic research project.
>
>Mixins are just like C-Macros with nicer synthax and less abilities. The way arrays are done isn't realy a "significant novel idea", is it?
>
>Anyway I didn't say anithing negative about D. I just said, that there anren't any revolutionary ideas or anything like that.
>
>

Mr.Matthias!
Java and C# are 'commercial movements' boasting the 'ideology' of
'Revolutonizing C/C++ through a true and modern successor' which, infact, is a
cunning and tempting idea to achieve dominance of the modern computer
programming world.
D , on the other hand, is the true and pure Evolution of C/C++ , having the
objective of serving the programmer world and not enslaving it :D !
My Salute to Mr.Walter Bright.
Irfan Hussain Sheikh,
Pakistan.