• Ken Carpenter (7/7) Feb 10 2003 Hi Walter,
• Walter (5/10) Feb 10 2003 application
• Walter Kurtz (3/5) Feb 11 2003 then call the next version 1.0: It's a psychological factor ...
• Walter (4/7) Feb 11 2003 not
• Juarez Rudsatz (5/7) Feb 11 2003 Why not a beta stage ?
• Keith Fuller (2/9) Feb 11 2003
• Ilya Minkov (26/41) Feb 11 2003 Hey, types have to become solid *before* 1.0, changing them on the
• Daniel Yokomiso (7/32) Feb 12 2003 DTL will change until it got any user base, which would happen after I s...
• Walter (3/4) Feb 11 2003 -Walter
• Patrick Down (8/15) Feb 11 2003 For the most part I think that the current D has a good
• Walter (5/12) Feb 11 2003 I was thinking of just doing the floating point keyword rename, renaming
• Ilya Minkov (4/9) Feb 11 2003 That is *quite* an amount of superficial change.
• Walter (4/13) Feb 11 2003 True, but it is all superficial, and would be pretty easy to fix existin...
• Chris Lawson (10/22) Feb 11 2003 If people use D 1.0 thinking it's a major version, and something really
• Burton Radons (33/35) Feb 11 2003 You're asking Walter, but I probably have more experience writing
• Ken Carpenter (12/34) Feb 11 2003 application
• Michael Slater (30/58) Feb 15 2003 Two cents from an early PC C++ adopter (Zortech C++ and then onto
• Walter (6/12) Feb 15 2003 I reluctantly agree with you.
• Andy Friesen (3/25) Feb 15 2003 http://dada.perl.it/shootout/
• Michael Slater (13/21) Feb 16 2003 Well, the optimizer works well on the sieve. The -O code is almost twice...
• Walter (3/12) Feb 16 2003 Yup. It's a good project.

"Ken Carpenter" <kencr shaw.ca> writes:

Hi Walter,

Do you think D is nearly stable enough for writing a large-scale application
yet?  Do you have a timeframe in mind?

I'm only concerned with servers and console-mode code, so maturity of GUI
frameworks isn't important to me.

Thanks,


Ken Carpenter

"Walter" <walter digitalmars.com> writes:

"Ken Carpenter" <kencr shaw.ca> wrote in message
news:b2a6fd$euc$1 digitaldaemon.com...
 Hi Walter,

 Do you think D is nearly stable enough for writing a large-scale

application
 yet?  Do you have a timeframe in mind?

 I'm only concerned with servers and console-mode code, so maturity of GUI
 frameworks isn't important to me.

I can't promise nothing will change, but I think it's stable enough. I'm not
going to rip the guts out of the semantics.

Walter Kurtz <Walter_member pathlink.com> writes:

Hi,

I can't promise nothing will change, but I think it's stable enough. I'm not
going to rip the guts out of the semantics.

then call the next version 1.0: It's a psychological factor ...

W. Kurtz

"Walter" <walter digitalmars.com> writes:

"Walter Kurtz" <Walter_member pathlink.com> wrote in message
news:b2ac2o$ibo$1 digitaldaemon.com...
I can't promise nothing will change, but I think it's stable enough. I'm


not
going to rip the guts out of the semantics.

 then call the next version 1.0: It's a psychological factor ...

You're probably right.

Juarez Rudsatz <juarezNOSPAM correio.com> writes:

 
 then call the next version 1.0: It's a psychological factor ...


Why not a beta stage ?

o    	Templates are not so stable yet.
o    	Some type will be changed, like complex and char[]
o    	There are none STL
o    	The standart library is tiny

Keith Fuller <Keith_member pathlink.com> writes:

Those are all version 2.0 features.

In article <Xns931FDCE687E14juarezcom 63.105.9.61>, Juarez Rudsatz says...
 
 then call the next version 1.0: It's a psychological factor ...


Why not a beta stage ?

o    	Templates are not so stable yet.
o    	Some type will be changed, like complex and char[]
o    	There are none STL
o    	The standart library is tiny

Ilya Minkov <midiclub 8ung.at> writes:

Hey, types have to become solid *before* 1.0, changing them on the 
mid-run is not good anymore!

Daniel is doing a template library, but basic libraries still change: 
Burton makes his changes which are funded and are likely to make it into 
the standard library... Nor much has been done with a GUI lib yet, its 
design has to be tested throughly, maybe some conceptual improvements 
like automatic UnDo and such could make it into it.

I'd say someone is trying to force the standardization of language on a 
very early stage, when it's important to avoid design features which 
might be a problem on a later stage. Just that it's not completely clear 
now, because we only see the current state, but by the time 1.0 is 
published, 2.0 should be in sight and the path should be definate, so 
that it's clear that no false decisions were made by 1.0.

Haven't we already seen what trouble it may cause, when standardization 
is forced *slightly* before it's actually ready? Look at Java. There are 
plenty of other examples.

Else 2.0 would be some language, which raises itself far above the earth 
and doesn't see the 1.0 anymore... :) Or gets stuck in 1.0 constaints.

If someone needs to maintain a project during compiler development, it 
generally isn't a problem. The only problem is that the code which 
stayed untouched for a while might get a bit obsolete, but from my 
Delphi experience correcting for a few library changes is not a big problem.

BTW, What strategy would be chosen for future development: always 
preserve compatibility or sometimes break it if it brings a major 
improvement?



Keith Fuller wrote:
 Those are all version 2.0 features.
 
 In article <Xns931FDCE687E14juarezcom 63.105.9.61>, Juarez Rudsatz says...
 
then call the next version 1.0: It's a psychological factor ...


Why not a beta stage ?

o    	Templates are not so stable yet.
o    	Some type will be changed, like complex and char[]
o    	There are none STL
o    	The standart library is tiny

 
 
 

Daniel Yokomiso <Daniel_member pathlink.com> writes:

In article <b2c5qj$23aj$1 digitaldaemon.com>, Ilya Minkov says...
Hey, types have to become solid *before* 1.0, changing them on the 
mid-run is not good anymore!

Daniel is doing a template library, but basic libraries still change: 
Burton makes his changes which are funded and are likely to make it into 
the standard library... Nor much has been done with a GUI lib yet, its 
design has to be tested throughly, maybe some conceptual improvements 
like automatic UnDo and such could make it into it.


DTL will change until it got any user base, which would happen after I start
putting some real functionality in it ;-)


I'd say someone is trying to force the standardization of language on a 
very early stage, when it's important to avoid design features which 
might be a problem on a later stage. Just that it's not completely clear 
now, because we only see the current state, but by the time 1.0 is 
published, 2.0 should be in sight and the path should be definate, so 
that it's clear that no false decisions were made by 1.0.


IMO we should think about standards AFTER we have people really using D. Right
now we need libraries, applications, user base, compilers, language variants,
etc. so we can understand what is good and what isn't.


Haven't we already seen what trouble it may cause, when standardization 
is forced *slightly* before it's actually ready? Look at Java. There are 
plenty of other examples.

Else 2.0 would be some language, which raises itself far above the earth 
and doesn't see the 1.0 anymore... :) Or gets stuck in 1.0 constaints.


Backwards compatibility kills languages. Look at C++ or Java.


If someone needs to maintain a project during compiler development, it 
generally isn't a problem. The only problem is that the code which 
stayed untouched for a while might get a bit obsolete, but from my 
Delphi experience correcting for a few library changes is not a big problem.

BTW, What strategy would be chosen for future development: always 
preserve compatibility or sometimes break it if it brings a major 
improvement?

"Walter" <walter digitalmars.com> writes:

"Keith Fuller" <Keith_member pathlink.com> wrote in message
news:b2c25a$216q$1 digitaldaemon.com...
 Those are all version 2.0 features.


<g> -Walter

Patrick Down <Patrick_member pathlink.com> writes:

In article <b2bsq4$1tsh$1 digitaldaemon.com>, Walter says...
"Walter Kurtz" <Walter_member pathlink.com> wrote in message
news:b2ac2o$ibo$1 digitaldaemon.com...
I can't promise nothing will change, but I think it's stable enough. I'm


not
going to rip the guts out of the semantics.

 then call the next version 1.0: It's a psychological factor ...

You're probably right.


For the most part I think that the current D has a good 
set of version 1.0 features.  I really would like to see 
the foreach construct make it in because I think I will
have an impact on how people will write container 
libraries.  

Why not finish up the parts of the "future directions"
desired, do a feature freeze, and call it Beta 1.0?

"Walter" <walter digitalmars.com> writes:

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b2c4c8$22hl$1 digitaldaemon.com...
 For the most part I think that the current D has a good
 set of version 1.0 features.  I really would like to see
 the foreach construct make it in because I think I will
 have an impact on how people will write container
 libraries.

 Why not finish up the parts of the "future directions"
 desired, do a feature freeze, and call it Beta 1.0?

I was thinking of just doing the floating point keyword rename, renaming
some of the operator overloading names, I'm thinking about the order of
array dimensions, fixing a few bugs, and calling it 1.0.

Ilya Minkov <midiclub 8ung.at> writes:

That is *quite* an amount of superficial change.
Which i really welcome if it brings more order.
And thanks for considering o. of array dimensions! :)

Walter wrote:
 
 I was thinking of just doing the floating point keyword rename, renaming
 some of the operator overloading names, I'm thinking about the order of
 array dimensions, fixing a few bugs, and calling it 1.0.
 

"Walter" <walter digitalmars.com> writes:

True, but it is all superficial, and would be pretty easy to fix existing
code.

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b2c6j3$23rk$1 digitaldaemon.com...
 That is *quite* an amount of superficial change.
 Which i really welcome if it brings more order.
 And thanks for considering o. of array dimensions! :)

 Walter wrote:
 I was thinking of just doing the floating point keyword rename, renaming
 some of the operator overloading names, I'm thinking about the order of
 array dimensions, fixing a few bugs, and calling it 1.0.

Chris Lawson <cl nospamhere.tinfoilhat.ca> writes:

If people use D 1.0 thinking it's a major version, and something really 
big changes in the next release, those for whom it is too much a hassle 
will leave.

If we keep it at alpha/beta releases, people might not pick up the 
language (those who feel the need for a stable major release) right 
away, but down the road when things really stabalize it'll be much 
easier to bring those people in than win back those who left because the 
language went to 1.x too early.

Chris

Walter Kurtz wrote:
 Hi,
 
 
I can't promise nothing will change, but I think it's stable enough. I'm not
going to rip the guts out of the semantics.

 
 
 then call the next version 1.0: It's a psychological factor ...
 
 W. Kurtz
 
 

Burton Radons <loth users.sourceforge.net> writes:

Ken Carpenter wrote:
 Do you think D is nearly stable enough for writing a large-scale application
 yet?  Do you have a timeframe in mind?

You're asking Walter, but I probably have more experience writing 
mid-scale apps in D.  I'd say no; it becomes increasingly hard to 
appease the limitations on declaration order the more modules you add, 
although this depends upon the type of application (a GUI library which 
is 800kb has no troubles, a D compiler which is 300kb is a constant 
war).  You eventually have to start playing games with the compiler, 
sneaking in imports after certain declarations or putting them inside 
the class.  With one programmer, this is problematic; with multiple, it 
could be catastrophic.

As to the language itself, I find it impossible to separate what 
features I think should change from what features I think might change. 
  The most widespread changes will be in Phobos though, as there's no 
design to it; it's been added to piecemeal.  So you have older modules 
like "file" that overlap the functionality of "stream", and separate 
files that should be joined like "math", "math2", and "intrinsic".

For the rest of this thread.  Languages which went 1.0 before they 
begged for it have suffered terribly.  Python will probably never be 
able to fix division, and classes are still not really integrated into 
the language.  K&R could have fixed function declarations after their 
book (essentially the 1.0), but had to give too much importance to the 
existing body of code.  In our case it means supporting Phobos as-is and 
not being able to change any semantics, or else it's a worthless number. 
  I would rather wait too long to call the language "done for now" than 
do it too early, then be unable to change what turns out to be a mistake 
in the design.

If anyone is scared off because of D's beta state, so what?  People are 
scared off because it has a GC, because it's too much like C, because it 
has no corporate support, because Walter isn't appeasing them 
personally, because they object to language used in the introduction, 
and on and freaking on.  Rejecting a language because it's only complete 
for the most part is one of the reasons, and it's one we can't change 
because D IS a beta language.

"Ken Carpenter" <kencr shaw.ca> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b2c5if$2330$1 digitaldaemon.com...
 Ken Carpenter wrote:
 Do you think D is nearly stable enough for writing a large-scale


application
 yet?  Do you have a timeframe in mind?

 You're asking Walter, but I probably have more experience writing
 mid-scale apps in D.  I'd say no; it becomes increasingly hard to
 appease the limitations on declaration order the more modules you add,
 although this depends upon the type of application (a GUI library which
 is 800kb has no troubles, a D compiler which is 300kb is a constant
 war).  You eventually have to start playing games with the compiler,
 sneaking in imports after certain declarations or putting them inside
 the class.  With one programmer, this is problematic; with multiple, it
 could be catastrophic.

What's the reason for the declaration limitations/problems?  Doesn't D do
multiple passes to compile?  I never have problems like this with large
scale Java code.


 For the rest of this thread.  Languages which went 1.0 before they
 begged for it have suffered terribly.  Python will probably never be
 able to fix division, and classes are still not really integrated into
 the language.  K&R could have fixed function declarations after their
 book (essentially the 1.0), but had to give too much importance to the
 existing body of code.  In our case it means supporting Phobos as-is and
 not being able to change any semantics, or else it's a worthless number.
   I would rather wait too long to call the language "done for now" than
 do it too early, then be unable to change what turns out to be a mistake
 in the design.

I absolutely agree.  I have only played with D a bit so far, but I could
tell that it's not quite ready for a mission critical project.  I was just
wondering if there was an expected timeframe for this.  I would much rather
see "things done right" before declaring the language design "final".

Thanks for your feedback Burton.  It was very helpful.


Ken Carpenter

Michael Slater <mail effectivity.com> writes:

Two cents from an early PC C++ adopter (Zortech C++ and then onto 
Borland C++ when I worked at Borland):

Burton Radons wrote:
 Ken Carpenter wrote:
 
 Do you think D is nearly stable enough for writing a large-scale 
 application
 yet?  Do you have a timeframe in mind?


Rather than 'cut to ship', for a new programming language that is still 
in flux, it makes more sense to me to 'cook until done'. Are we willing 
to sacrifice quality to meet a ship date? What business factors are 
driving the ship date?

It's a devil to change things once the cat has escaped and the amount of 
existing code starts becoming something to worry about. People hate 
changing code because a new compiler breaks their old apps.

Anyone remember OWL? DDVTs? Even though OWL2 was a much better design 
than OWL1, we took major hell for changing things. From what I've seen 
so far, I think D has the potential to change as much as OWL changed 
going from 1 to 2.

 As to the language itself, I find it impossible to separate what 
 features I think should change from what features I think might change. 
  The most widespread changes will be in Phobos though, as there's no 
 design to it; it's been added to piecemeal.  So you have older modules 
 like "file" that overlap the functionality of "stream", and separate 
 files that should be joined like "math", "math2", and "intrinsic".

It sounds like there is cleanup to be done before labeling anything 1.0 
and shipping it.

 For the rest of this thread.  Languages which went 1.0 before they 
 begged for it have suffered terribly.  Python will probably never be 
 able to fix division, and classes are still not really integrated into 
 the language.  K&R could have fixed function declarations after their 
 book (essentially the 1.0), but had to give too much importance to the 
 existing body of code.  In our case it means supporting Phobos as-is and 
 not being able to change any semantics, or else it's a worthless number. 
  I would rather wait too long to call the language "done for now" than 
 do it too early, then be unable to change what turns out to be a mistake 
 in the design.

I agree with this sentiment wholeheartedly. I'm happy iterating all the 
way from 0.53 to 1.00 improving the language, runtime, documentation, 
etc., all the way along. Good new programming languages come along 
rarely. Most stuff is shipped out there half done. It's hard to build 
and maintain enthusiasm when the user is fighting the tools and the 
awkwardness of a system that hasn't quite been shaken out yet.

 If anyone is scared off because of D's beta state, so what?  People are 
 scared off because it has a GC, because it's too much like C, because it 
 has no corporate support, because Walter isn't appeasing them 
 personally, because they object to language used in the introduction, 
 and on and freaking on.  Rejecting a language because it's only complete 
 for the most part is one of the reasons, and it's one we can't change 
 because D IS a beta language.

In order to be as compelling as possible, D should positively radiate 
elegance, thoughtfulness, and pragmatism. A lot of this is going to come 
from learning things and fixing them along the path from 0.53 to 1.0.

As a data point, it would be interesting to see how D compares to other 
languages right now:

http://www.bagley.org/~doug/shootout/

Anyhow, more can be said, but the short of my two cents is "keep cooking".

--ms

"Walter" <walter digitalmars.com> writes:

"Michael Slater" <mail effectivity.com> wrote in message
news:b2ksp9$1hea$1 digitaldaemon.com...
 In order to be as compelling as possible, D should positively radiate
 elegance, thoughtfulness, and pragmatism. A lot of this is going to come
 from learning things and fixing them along the path from 0.53 to 1.0.

I reluctantly agree with you.

 As a data point, it would be interesting to see how D compares to other
 languages right now:

 http://www.bagley.org/~doug/shootout/

A cool site. Anyone care to do D versions of all these benchmarks?
Unfortunately, though, the author of the web page says he's set it aside for
the moment.

Andy Friesen <andy ikagames.com> writes:

http://dada.perl.it/shootout/

The sieve is the only one that's been done in D so far, though.

Walter wrote:
 "Michael Slater" <mail effectivity.com> wrote in message
 news:b2ksp9$1hea$1 digitaldaemon.com...
 
In order to be as compelling as possible, D should positively radiate
elegance, thoughtfulness, and pragmatism. A lot of this is going to come
from learning things and fixing them along the path from 0.53 to 1.0.

 
 
 I reluctantly agree with you.
 
 
As a data point, it would be interesting to see how D compares to other
languages right now:

http://www.bagley.org/~doug/shootout/

 
 
 A cool site. Anyone care to do D versions of all these benchmarks?
 Unfortunately, though, the author of the web page says he's set it aside for
 the moment.
 
 

Michael Slater <mail effectivity.com> writes:

Andy Friesen wrote:
 http://dada.perl.it/shootout/
 
 The sieve is the only one that's been done in D so far, though.

Well, the optimizer works well on the sieve. The -O code is almost twice 
as fast as the default code :-)

 Walter wrote:
 A cool site. Anyone care to do D versions of all these benchmarks?
 Unfortunately, though, the author of the web page says he's set it 
 aside for
 the moment.


I'll write up D versions of as many tests as I can this coming week. It 
should be a fun little jaunt. After I've taken a first pass at it, I'll 
post the code here so the folks that are more expert with the language 
can take a look and offer improvements.

The author of the Win32 version of the tests seems to keep his tests 
more up to date, although the version of D used for the sieve was 0.42.

Even if we have to run the tests on the other languages ourselves, I 
think we'll get some interesting data on how D fits into the language 
landscape.

--ms

"Walter" <walter digitalmars.com> writes:

"Michael Slater" <mail effectivity.com> wrote in message
news:b2nu6i$1aau$1 digitaldaemon.com...
 I'll write up D versions of as many tests as I can this coming week. It
 should be a fun little jaunt. After I've taken a first pass at it, I'll
 post the code here so the folks that are more expert with the language
 can take a look and offer improvements.

 The author of the Win32 version of the tests seems to keep his tests
 more up to date, although the version of D used for the sieve was 0.42.

 Even if we have to run the tests on the other languages ourselves, I
 think we'll get some interesting data on how D fits into the language
 landscape.

Yup. It's a good project.