Jump to page: 1 2 3
Thread overview
Timeframe for a stable 1.0 version?
Feb 11, 2003
Ken Carpenter
Feb 11, 2003
Walter
Feb 11, 2003
Walter Kurtz
Feb 11, 2003
Walter
Feb 11, 2003
Juarez Rudsatz
Feb 11, 2003
Keith Fuller
Feb 12, 2003
Ilya Minkov
Feb 12, 2003
Daniel Yokomiso
Feb 12, 2003
Walter
Feb 12, 2003
Patrick Down
Feb 12, 2003
Walter
Feb 12, 2003
Ilya Minkov
Feb 12, 2003
Walter
Feb 12, 2003
Chris Lawson
Feb 12, 2003
Burton Radons
Feb 12, 2003
Ken Carpenter
Feb 15, 2003
Michael Slater
Feb 15, 2003
Walter
Feb 16, 2003
Andy Friesen
Feb 16, 2003
Michael Slater
Feb 16, 2003
Walter
February 11, 2003
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


February 11, 2003
"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.


February 11, 2003
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


February 11, 2003
"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.


February 11, 2003
> 
>> 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
February 11, 2003
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


February 12, 2003
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?


February 12, 2003
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.

February 12, 2003
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
> 
> 
> 

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


<g> -Walter


« First   ‹ Prev
1 2 3