"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.

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.
> 

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

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.
> >
>

"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

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?

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

"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.

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.
> 
> 

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