www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will D ever be ready?

reply Jason Mills <jmills cs.mun.ca> writes:
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 
C++/CLI soon a reality, improvements to C++ coming, together with 
existing versions of C# and Java, all with huge libraries ready to use 
out of the box, will D every be able to compete?

Jason
Mar 02 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Jason Mills wrote:
 I have been reading this newsgroup for several years. Although I post 
 rarely I do read it every day. Early on I was so enthusiastic about D I 
 could barely contain myself. I could not wait to use D at work, 
 replacing C++ and Java. I'm still patiently waiting for that day. With 
 C++/CLI soon a reality, improvements to C++ coming, together with 
 existing versions of C# and Java, all with huge libraries ready to use 
 out of the box, will D every be able to compete?

D as a language already is competitive with both C# and Java - I guess http://www.digitalmars.com/d/comparison.html speaks for itself in this respect. Of course, whether it will have a standard library to match C# and Java is another matter. There is potential for Phobos to grow, even more so with its being open source. But OTOH, it's debatable what features are best put into a standard library, as opposed to left out to encourage competing third-party libraries to develop. Sometimes there are many ways to do something and none is obviously the best - so different libraries would implement different approaches. The various D GUI libraries being developed with different designs and goals are an example of this. But the combination of Phobos and third-party D libraries certainly has a huge potential. Once we have enough D programmers, there will be a good collection of library functionality for various purposes, which may eventually be up to a par with what is available for C# and Java. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 02 2005
prev sibling next sibling parent reply sai <sai_member pathlink.com> writes:
So am I !!! Now I am getting bored. Version 1.0 seems like a dream now.
I guess I too need to take a break from obsessively following this ng.

sai


In article <d04ccv$2nh7$1 digitaldaemon.com>, Jason Mills says...
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 
C++/CLI soon a reality, improvements to C++ coming, together with 
existing versions of C# and Java, all with huge libraries ready to use 
out of the box, will D every be able to compete?

Jason

Mar 02 2005
parent reply jicman <jicman_member pathlink.com> writes:
The questin is, what are you guys waiting for?

In article <d04i8j$2ucb$1 digitaldaemon.com>, sai says...
So am I !!! Now I am getting bored. Version 1.0 seems like a dream now.
I guess I too need to take a break from obsessively following this ng.

sai


In article <d04ccv$2nh7$1 digitaldaemon.com>, Jason Mills says...
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 
C++/CLI soon a reality, improvements to C++ coming, together with 
existing versions of C# and Java, all with huge libraries ready to use 
out of the box, will D every be able to compete?

Jason


Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"jicman" <jicman_member pathlink.com> wrote in message
news:d04ru4$8l5$1 digitaldaemon.com...
 The questin is, what are you guys waiting for?

That is a very good question. Is it some crucial feature/bug lacking preventing using it for a major project, or is it concern that the language will change enough to cause any D source today to undergo major rewrites? I can answer the latter concern - it isn't going to happen.
Mar 02 2005
next sibling parent "bamb00" <no email.com> writes:
I've been using D for about a year and half and it has steadily improved.  I
use it now for various tasks and it works great.  They have all been
relatively small ( under 15 modules ) , it would be interesting to hear from
those who have done bigger projects in D ( Vathix, Kris, Ant -- where is
Antonio btw ? ).

I can't speak for others but what _i'm_ waiting for to call D 1.0 is
complete debug info , and a 95% or better on DStress.  I think the debug
info is crucial , infact I think it was more crucial when D started ( make
it easier to work out the bugs ) , but for 1.0 its a nessecity .

I think many of us have waited on a 1.0 to do a full blown campaign for D ,
so when it does hit 1.0 I expect it to gain ground fast.

What in your eyes ( Walter ) is needed for it to be 1.0 ?

Charlie




"Walter" <newshound digitalmars.com> wrote in message
news:d04son$9k2$1 digitaldaemon.com...
 "jicman" <jicman_member pathlink.com> wrote in message
 news:d04ru4$8l5$1 digitaldaemon.com...
 The questin is, what are you guys waiting for?

That is a very good question. Is it some crucial feature/bug lacking preventing using it for a major project, or is it concern that the

 will change enough to cause any D source today to undergo major rewrites?

 I can answer the latter concern - it isn't going to happen.

Mar 02 2005
prev sibling next sibling parent reply sai <sai_member pathlink.com> writes:
I am a graduate student of Mechanical engineering, I wanted to use D in doing
high performance dynamic optimization and for implementing real time simulators
for feedback controllers (Matlab is > 1000 times slower than real time!).

After learning Java and C# (and Matlab of course) I hate touching C or C++
But D came to me as a very pleasant surprise; it was love at first sight.

Anyway, I am not very good at using debuggers or even understand the source
of D front end etc. My programs in D crashed too often due to bugs in my code.
I wish, I could get a 'D' IDE with built in debugger, that works on windows.
I wish, phobos be as extensive as java api, with at least one standard GUI api.

I know, I may sound funny or silly for other expert programmers, but atleast for
me, the current state of D is not readily usable. 

Anyway, I am not blaming anyone, its just, you know .... a little disappointment
that the language you love does not have all the things you wanted. 

I know, it will take time, and for now, I have to be content with some other
language. 

Anyway, I really enjoyed whatever coding I did in D. 

 The questin is, what are you guys waiting for?


Well, I am waiting for a complete language, like array literal expressions, mixins, etc etc. extensive API with at least one GUI, with DTL distributed along with D compiler. Well again, I know, it will take time ..... D 1.0 .... D 2.0 ... I understand, Digitalmars is no Microsoft or no Sun. I guess I have to check back after a long vacation from this ng. Best Wishes and Mighty kudos for Walter and all others involved sai
Mar 02 2005
next sibling parent Jason Mills <jmills cs.mun.ca> writes:
sai wrote:
 Anyway, I am not very good at using debuggers or even understand the source
 of D front end etc. My programs in D crashed too often due to bugs in my code.
 I wish, I could get a 'D' IDE with built in debugger, that works on windows.
 I wish, phobos be as extensive as java api, with at least one standard GUI api.

Yes. For D to be accepted at my work place, a D IDE, Phobos ~ Java API, a "standard" GUI library are a must. I can make do without some of these tools, but other "part-time" programmers I work with will not. Hence, we use Java or C++ .NET (C++ MFC before that). Jason
Mar 02 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
I know when I first started out D, I was wondering why all my classes 
would seg fault :-/ (it was because i never 'newed' it).

Is there a way for the compiler to give a better error (run time error 
message) instead of 'segmentation fault'. Maybe something like, 
'filename-line# cannot access null class'

sai wrote:
 I am a graduate student of Mechanical engineering, I wanted to use D in doing
 high performance dynamic optimization and for implementing real time simulators
 for feedback controllers (Matlab is > 1000 times slower than real time!).
 
 After learning Java and C# (and Matlab of course) I hate touching C or C++
 But D came to me as a very pleasant surprise; it was love at first sight.
 
 Anyway, I am not very good at using debuggers or even understand the source
 of D front end etc. My programs in D crashed too often due to bugs in my code.
 I wish, I could get a 'D' IDE with built in debugger, that works on windows.
 I wish, phobos be as extensive as java api, with at least one standard GUI api.
 
 I know, I may sound funny or silly for other expert programmers, but atleast
for
 me, the current state of D is not readily usable. 
 
 Anyway, I am not blaming anyone, its just, you know .... a little
disappointment
 that the language you love does not have all the things you wanted. 
 
 I know, it will take time, and for now, I have to be content with some other
 language. 
 
 Anyway, I really enjoyed whatever coding I did in D. 
 
 
The questin is, what are you guys waiting for?


Well, I am waiting for a complete language, like array literal expressions, mixins, etc etc. extensive API with at least one GUI, with DTL distributed along with D compiler. Well again, I know, it will take time ..... D 1.0 .... D 2.0 ... I understand, Digitalmars is no Microsoft or no Sun. I guess I have to check back after a long vacation from this ng. Best Wishes and Mighty kudos for Walter and all others involved sai

Mar 02 2005
parent reply brad domain.invalid writes:
clayasaurus wrote:
 I know when I first started out D, I was wondering why all my classes 
 would seg fault :-/ (it was because i never 'newed' it).

I totally agree. I still get bitten by segfaults. I start taking the C approach to finding them, by rolling up my sleaves and looking for possible null pointer references, etc. I never find the obvious null pointer - because it isn't there :) And I'm so used to C/C++ that when I see object.foo() (instead of object->foo()) I think "that can't be the problem, it's not a pointer" So, please please can we have a message other than segfault for objects that haven't been instantiated? Brad
Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
<brad domain.invalid> wrote in message
news:d05gbg$11g0$1 digitaldaemon.com...
 clayasaurus wrote:
 I know when I first started out D, I was wondering why all my classes
 would seg fault :-/ (it was because i never 'newed' it).

I totally agree. I still get bitten by segfaults. I start taking the C approach to finding them, by rolling up my sleaves and looking for possible null pointer references, etc.

Too find them, compile with -g and then run it under the debugger. The debugger will point you at which line failed.
  I never find the obvious null
 pointer - because it isn't there :)  And I'm so used to C/C++ that when
 I see object.foo() (instead of object->foo()) I think "that can't be the
 problem, it's not a pointer"
 So, please please can we have a message other than segfault for objects
 that haven't been instantiated?

Mar 02 2005
next sibling parent reply brad domain.invalid writes:
Walter wrote:
 <brad domain.invalid> wrote in message
 news:d05gbg$11g0$1 digitaldaemon.com...
 
clayasaurus wrote:

I know when I first started out D, I was wondering why all my classes
would seg fault :-/ (it was because i never 'newed' it).

I totally agree. I still get bitten by segfaults. I start taking the C approach to finding them, by rolling up my sleaves and looking for possible null pointer references, etc.

Too find them, compile with -g and then run it under the debugger. The debugger will point you at which line failed.

I guess I've gotten out of the habit of using a debugger with D because it initially wasn't supported under Linux.
Mar 02 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
brad domain.invalid wrote:
 Walter wrote:
 
 <brad domain.invalid> wrote in message
 news:d05gbg$11g0$1 digitaldaemon.com...

 clayasaurus wrote:

 I know when I first started out D, I was wondering why all my classes
 would seg fault :-/ (it was because i never 'newed' it).

I totally agree. I still get bitten by segfaults. I start taking the C approach to finding them, by rolling up my sleaves and looking for possible null pointer references, etc.

Too find them, compile with -g and then run it under the debugger. The debugger will point you at which line failed.

I guess I've gotten out of the habit of using a debugger with D because it initially wasn't supported under Linux.

Old versions of Turbo Pascal used to show the address where the program crashed. Then you'd give this address to the compiler, and it would recompile till it found the address, and then show what source line that corresponds to. At least on Linux one could install a handler for SIGSEGV to output the offending location.
Mar 03 2005
prev sibling parent John Demme <me teqdruid.com> writes:
Walter wrote:
 <brad domain.invalid> wrote in message
 news:d05gbg$11g0$1 digitaldaemon.com...
 
clayasaurus wrote:

I know when I first started out D, I was wondering why all my classes
would seg fault :-/ (it was because i never 'newed' it).

I totally agree. I still get bitten by segfaults. I start taking the C approach to finding them, by rolling up my sleaves and looking for possible null pointer references, etc.

Too find them, compile with -g and then run it under the debugger. The debugger will point you at which line failed.

Not in Linux! I find my self putting a lot of code like: if (a is null) writefln("null ptr");
Mar 02 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 will change enough to cause any D source today to undergo major rewrites?
 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?
Mar 02 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:

 will change enough to cause any D source today to undergo major rewrites?
 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?

I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour. -- Derek Melbourne, Australia 3/03/2005 4:03:08 PM
Mar 02 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 3 Mar 2005 16:04:23 +1100, Derek Parnell wrote:

 On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:
 
 will change enough to cause any D source today to undergo major rewrites?
 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?

I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.

In fact, I'd like this syntax extended for non-array built-in types too. bool Foo(real A, char[] B) { . . . } real x; if ( x.Foo("abc") ) { . . .}; It would make life *so* much easier rather than special coding for structs, some more for classes, and some more for built-in types. I mean, these are decisions that the compiler can make with making me work so hard :D -- Derek Melbourne, Australia 3/03/2005 4:11:36 PM
Mar 02 2005
parent Zorba the Greek <Zorba_member pathlink.com> writes:
In article <1lj4myiqvas8v$.coq7aamqhkac$.dlg 40tude.net>, Derek Parnell says...
On Thu, 3 Mar 2005 16:04:23 +1100, Derek Parnell wrote:

 On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:
 
 will change enough to cause any D source today to undergo major rewrites?
 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?

I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.

In fact, I'd like this syntax extended for non-array built-in types too. bool Foo(real A, char[] B) { . . . } real x; if ( x.Foo("abc") ) { . . .}; It would make life *so* much easier rather than special coding for structs, some more for classes, and some more for built-in types. I mean, these are decisions that the compiler can make with making me work so hard :D -- Derek Melbourne, Australia 3/03/2005 4:11:36 PM

Careful though. I bet this does not work: class Bar { bool Foo(real A, char[] B) { . . . } } real x; if ( x.Bar.Foo("abc") ) { . . .}; This is potentially the kind of thing that /might/ be pulled. Not saying that it will, but the peripheral stuff is often yanked for a major release (as Glen described so well).
Mar 02 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I sure hope so 'cos I've spent the last couple of weeks writing a whole
 heap of code that depends on this behaviour.

:)
Mar 02 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0651s$1mgp$1 digitaldaemon.com...
 will change enough to cause any D source today to undergo major


 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?

I don't see any reason to take it out.
Mar 02 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
Thanks a lot, Walter.

 I mean this was supported last time I checked it
 char[][] split(char[] s, char c) { ... }
 char[] s = "a b c";
 char[][] sv = s.split(' ');

 May I rely on this trick?

I don't see any reason to take it out.

Mar 02 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 2 Mar 2005 22:43:35 -0800, Walter <newshound digitalmars.com>  
wrote:
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d0651s$1mgp$1 digitaldaemon.com...
 will change enough to cause any D source today to undergo major


 I can answer the latter concern - it isn't going to happen.

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"? I mean this was supported last time I checked it char[][] split(char[] s, char c) { ... } char[] s = "a b c"; char[][] sv = s.split(' '); May I rely on this trick?

I don't see any reason to take it out.

Ahh.. but is it in the spec? Will you add it to the spec? So other D compilers will also support it? Regan
Mar 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsm2yxbvj23k2f5 ally...
 Ahh.. but is it in the spec? Will you add it to the spec? So other D
 compilers will also support it?

I put it in so that arrays and basic types could be extended by the programmer to have generic 'property' like features. It should go in the spec, you're right.
Mar 03 2005
parent reply "Carlos Santander B." <csantander619 gmail.com> writes:
Walter wrote:
 
 I put it in so that arrays and basic types could be extended by the
 programmer to have generic 'property' like features. It should go in the
 spec, you're right.
 
 

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ? Also, right now, it only works with arrays, not basic types, classes, structs, unions or enums. _______________________ Carlos Santander Bernal
Mar 03 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B.  
<csantander619 gmail.com> wrote:
 Walter wrote:
  I put it in so that arrays and basic types could be extended by the
 programmer to have generic 'property' like features. It should go in the
 spec, you're right.

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Assuming: path.module1.foo(char[] a, int i); path.module2.foo(char[] a, int i); char[] a; a.path.module1.foo(1); a.path.module2.foo(2); perhaps? or maybe it's better to force the user to revert to: path.module1.foo(a,1); path.module2.foo(a,2);
 Also, right now, it only works with arrays, not basic types, classes,  
 structs, unions or enums.

It would be kewl if it worked with all types, if so, how should it handle: class A { void foo() { } } void foo(A a) { } A a = new A(); a.foo(); //which do we call? The same applies to struct, union, and when the function clashes with a property of a basic type or array. Regan
Mar 03 2005
parent reply "Nick Sabalausky" <z a.a> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsm244zh323k2f5 ally...
 On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B. 
 <csantander619 gmail.com> wrote:
 Walter wrote:
  I put it in so that arrays and basic types could be extended by the
 programmer to have generic 'property' like features. It should go in the
 spec, you're right.

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Assuming: path.module1.foo(char[] a, int i); path.module2.foo(char[] a, int i); char[] a; a.path.module1.foo(1); a.path.module2.foo(2); perhaps?

maybe?: a..foo(1); Although maybe that would cause problems for the compiler distinguishing it from the array slicing use of '..'?
 or maybe it's better to force the user to revert to:

 path.module1.foo(a,1);
 path.module2.foo(a,2);

 Also, right now, it only works with arrays, not basic types, classes, 
 structs, unions or enums.

It would be kewl if it worked with all types, if so, how should it handle: class A { void foo() { } } void foo(A a) { } A a = new A(); a.foo(); //which do we call? The same applies to struct, union, and when the function clashes with a property of a basic type or array. Regan

It makes sense to use on arrays and basic types because they have no other way to use blah.func() syntax. But, I don't think it should be allowed for classes because it would lead to major abuses to the ideas of a class and encapsulation. For instance, adding "member functions" to a class without actually inhereting it. Although maybe that would be good...? I guess it just feels kinda dangerous to me.
Mar 03 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 3 Mar 2005 18:54:48 -0500, Nick Sabalausky <z a.a> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsm244zh323k2f5 ally...
 On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B.
 <csantander619 gmail.com> wrote:
 Walter wrote:
  I put it in so that arrays and basic types could be extended by the
 programmer to have generic 'property' like features. It should go in  
 the
 spec, you're right.

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Assuming: path.module1.foo(char[] a, int i); path.module2.foo(char[] a, int i); char[] a; a.path.module1.foo(1); a.path.module2.foo(2); perhaps?

this maybe?: a..foo(1); Although maybe that would cause problems for the compiler distinguishing it from the array slicing use of '..'?

Good point. Yuck. I think then, the solution is that in cases where there is conflict you have to specify the name in full and pass the parameter. I think this feature is still incredibly useful. This one problem does not detract much, if anything from it's usefulness. Regan
Mar 03 2005
parent "Nick Sabalausky" <z a.a> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsm27utj923k2f5 ally...
 On Thu, 3 Mar 2005 18:54:48 -0500, Nick Sabalausky <z a.a> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsm244zh323k2f5 ally...
 On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B.
 <csantander619 gmail.com> wrote:
 Walter wrote:
  I put it in so that arrays and basic types could be extended by the
 programmer to have generic 'property' like features. It should go in 
 the
 spec, you're right.

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Assuming: path.module1.foo(char[] a, int i); path.module2.foo(char[] a, int i); char[] a; a.path.module1.foo(1); a.path.module2.foo(2); perhaps?

this maybe?: a..foo(1); Although maybe that would cause problems for the compiler distinguishing it from the array slicing use of '..'?

Good point. Yuck. I think then, the solution is that in cases where there is conflict you have to specify the name in full and pass the parameter. I think this feature is still incredibly useful. This one problem does not detract much, if anything from it's usefulness. Regan

Well, I'm not sure it means we couldn't keep the "disambiguate-ing" syntax, just that we probably couldn't use it for global resolution. Although, maybe it would be better to have consistency from disallowing it across all name collisions, like you said.
Mar 03 2005
prev sibling parent reply "Carlos Santander B." <csantander619 gmail.com> writes:
Nick Sabalausky wrote:
 
 
 It makes sense to use on arrays and basic types because they have no other 
 way to use blah.func() syntax. But, I don't think it should be allowed for 
 classes because it would lead to major abuses to the ideas of a class and 
 encapsulation. For instance, adding "member functions" to a class without 
 actually inhereting it.
 
 Although maybe that would be good...? I guess it just feels kinda dangerous 
 to me. 
 
 

Good point. Now I agree they shouldn't be allowed for classes and structs. Unions and enums would be ok, I think? _______________________ Carlos Santander Bernal
Mar 03 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 03 Mar 2005 19:51:15 -0500, Carlos Santander B.  
<csantander619 gmail.com> wrote:
 Nick Sabalausky wrote:
   It makes sense to use on arrays and basic types because they have no  
 other way to use blah.func() syntax. But, I don't think it should be  
 allowed for classes because it would lead to major abuses to the ideas  
 of a class and encapsulation. For instance, adding "member functions"  
 to a class without actually inhereting it.


I don't think it's an abuse of encapsulation. You're not getting any more access to the class eg. class A {} void foo(A a) {} foo cannot modify/access 'a' as much as a real member function could, it just looks like one.
  Although maybe that would be good...? I guess it just feels kinda  
 dangerous to me.

Good point. Now I agree they shouldn't be allowed for classes and structs. Unions and enums would be ok, I think?

Unions can have member functions too. Regan
Mar 03 2005
prev sibling parent reply Mark Junker <mjscod gmx.de> writes:
Walter schrieb:

The questin is, what are you guys waiting for?


 That is a very good question. Is it some crucial feature/bug lacking
 preventing using it for a major project, or is it concern that the language
 will change enough to cause any D source today to undergo major rewrites?

I really like the idea of using D but it's much too unstable: 1. Too many known and (IMHO) critical bugs 2. New versions of D may break existing code due to introduction of new bugs (I really miss the QA - this seems to be too unprofessional) Walter, you're a good developer but you should only publish new releases when you don't break existing (and syntactically error-free) code (DStress?) Regards, Mark
Mar 03 2005
parent "Nick Sabalausky" <z a.a> writes:
 Walter, you're a good developer but you should only publish new releases 
 when you don't break existing (and syntactically error-free) code 
 (DStress?)

existing code if a good reason arises. This prevents the language from prematurely backing itself into a corner from decicions that later turn out to be bad choices.
Mar 03 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Jason Mills" <jmills cs.mun.ca> wrote in message 
news:d04ccv$2nh7$1 digitaldaemon.com...
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, replacing 
C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a 
reality, improvements to C++ coming, together with existing versions of C# 
and Java, all with huge libraries ready to use out of the box, will D every 
be able to compete?

 Jason

Not to single you out, but the best way to help D compete is to get invovled. I'm talkin' to all of you out there sittin' on the fence - yeah you know who you are! :-) If everyone waits for D to arrive it will never arrive (deep, eh?). The day dmd-1.0.zip comes out it will be a nice time to reflect a little and start planning for what to do next, but practically speaking it will a lot like dmd-0.nnn.zip. I don't think there was a day that C++ suddenly arrived. It just grew and grew. Java and C# have huge marketing machines behind them so they try to trumpet milestones as changing the world - but mostly the world changes very slowly. Hence the importance of all the libraries/tools/community surrounding what Walter does.
Mar 02 2005
parent Jason Mills <jmills cs.mun.ca> writes:
Ben Hinkle wrote:
 "Jason Mills" <jmills cs.mun.ca> wrote in message 
 news:d04ccv$2nh7$1 digitaldaemon.com...
 
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, replacing 
C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a 
reality, improvements to C++ coming, together with existing versions of C# 
and Java, all with huge libraries ready to use out of the box, will D every 
be able to compete?

Jason

Not to single you out, but the best way to help D compete is to get invovled. I'm talkin' to all of you out there sittin' on the fence - yeah you know who you are! :-) If everyone waits for D to arrive it will never arrive (deep, eh?).

I would love too to get involved. But I'm afraid I have no free time. Working full time, working on my masters, and family life take all my time. That said, I will soon be finished my masters. Then I should be able to contribute something beyond d.vim.
 The day dmd-1.0.zip comes out it will be a nice time to reflect a little and 
 start planning for what to do next, but practically speaking it will a lot 
 like dmd-0.nnn.zip. I don't think there was a day that C++ suddenly arrived. 
 It just grew and grew. Java and C# have huge marketing machines behind them 
 so they try to trumpet milestones as changing the world - but mostly the 
 world changes very slowly. Hence the importance of all the 
 libraries/tools/community surrounding what Walter does.

Mar 02 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Mar 2005 09:11:11 -0330, Jason Mills wrote:

 I have been reading this newsgroup for several years. Although I post 
 rarely I do read it every day. Early on I was so enthusiastic about D I 
 could barely contain myself. I could not wait to use D at work, 
 replacing C++ and Java. I'm still patiently waiting for that day. With 
 C++/CLI soon a reality, improvements to C++ coming, together with 
 existing versions of C# and Java, all with huge libraries ready to use 
 out of the box, will D every be able to compete?
 
 Jason

whether it will ever be really finished. But if you are asking will it ever be in a state in which we can use it, then I guess it is vert nearly there now. And over then next year or two, it will only get better (most cost effective) to use. Currently, it will take a bit of work on your part to make things happen, but better libraries and better code generation, and hopefully better syntax, are still to come. Even though there are some bugs still in the current DMD implementation, I haven't seen too many in which incorrect object code is being created. So I suggest you start using D with a purpose, if only to get some practice in how to think in D. Also, try to find a library project, or some other way in which you can personally contribute to the future of D. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 3/03/2005 2:19:11 AM
Mar 02 2005
parent Jason Mills <jmills cs.mun.ca> writes:
Derek Parnell wrote:
 On Wed, 02 Mar 2005 09:11:11 -0330, Jason Mills wrote:
 
 
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 
C++/CLI soon a reality, improvements to C++ coming, together with 
existing versions of C# and Java, all with huge libraries ready to use 
out of the box, will D every be able to compete?

Jason

By the phrase "be ready", do you mean "be finished"? If so, then I doubt whether it will ever be really finished. But if you are asking will it ever be in a state in which we can use it, then I guess it is vert nearly there now. And over then next year or two, it will only get better (most cost effective) to use. Currently, it will take a bit of work on your part to make things happen, but better libraries and better code generation, and hopefully better syntax, are still to come.

I guess what I mean by "ready" is "when can I ditch Java and C++ and use D at work?". See my other post.
 Even though there are some bugs still in the current DMD implementation, I
 haven't seen too many in which incorrect object code is being created.
 
 So I suggest you start using D with a purpose, if only to get some practice
 in how to think in D. Also, try to find a library project, or some other
 way in which you can personally contribute to the future of D.
 

Mar 02 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Jason Mills wrote:
 I have been reading this newsgroup for several years. Although I post 
 rarely I do read it every day. Early on I was so enthusiastic about D I 
 could barely contain myself. I could not wait to use D at work, 
 replacing C++ and Java. I'm still patiently waiting for that day. With 
 C++/CLI soon a reality, improvements to C++ coming, together with 
 existing versions of C# and Java, all with huge libraries ready to use 
 out of the box, will D every be able to compete?
 
 Jason

This is more of a personal philosophical question. It all depends your point of view. For some, D is already pretty good and does what they need to get done better than c++. For some (more advanced?), D is not quite ready and gets a lot of requests for reflection, and some don't like some design aspect of D, or D is bugged for them and are waiting for a fix. If D works for you and you can convince your workplace, more power to you. You see D won't just magically replace c++ without a bit of successful advocacy, but I wouldn't try to advocate it until it is ready for your workplace, or else people will get bad first impressions. Speaking of which, I don't expect D to make huge inroads until we get a 1.0 version along with a book, maybe big W + M can go on a book tour ;) For me (as kinda an intermediate newbie), I guess I'm too ignorant to notice/understand whatever is wrong with phobos and D. So it works for me and I use it.
Mar 02 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Jason Mills" <jmills cs.mun.ca> wrote in message
news:d04ccv$2nh7$1 digitaldaemon.com...
 I have been reading this newsgroup for several years. Although I post
 rarely I do read it every day. Early on I was so enthusiastic about D I
 could barely contain myself. I could not wait to use D at work,
 replacing C++ and Java. I'm still patiently waiting for that day. With
 C++/CLI soon a reality, improvements to C++ coming, together with
 existing versions of C# and Java, all with huge libraries ready to use
 out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?
Mar 02 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d04ccv$2nh7$1 digitaldaemon.com...
 
I have been reading this newsgroup for several years. Although I post
rarely I do read it every day. Early on I was so enthusiastic about D I
could barely contain myself. I could not wait to use D at work,
replacing C++ and Java. I'm still patiently waiting for that day. With
C++/CLI soon a reality, improvements to C++ coming, together with
existing versions of C# and Java, all with huge libraries ready to use
out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

I think D 1.0 is the day you are ready to make D public and face scrutinization from all those c++ programmers, and the day when people will start to think of D not as a concept but a serious language. Sure, you could call it 1.0 now, but are you ready for the aftermath? It would be tragic for the vast majority of people to try D 1.0, get a false impression from (insert bug/whatever) here, and never try it again. Then again, theoretically, the sooner D goes out the door, the better chance it may have to gain a foothold on the other c++ improvements (C#, Java), unless you think those languages arn't competitive to D and cater to different markets. (D seems to be for low level stuff, and Java C# high level GUI type stuff). If I were W, I would set a 1.0 date for D and release it with the book so that you will have the time to critically analize D and iron it out into a smooth machine, before the c++ programmer's can get ahold of it, critically anylize it, and try to dismiss it for (insert random drawback here). Cause ya know, from momentum, c++ is not going to be easily pushed aside for D.
Mar 02 2005
next sibling parent Dave <Dave_member pathlink.com> writes:
In article <4225EEA7.1030607 gmail.com>, clayasaurus says...
Walter wrote:
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d04ccv$2nh7$1 digitaldaemon.com...
 
I have been reading this newsgroup for several years. Although I post
rarely I do read it every day. Early on I was so enthusiastic about D I
could barely contain myself. I could not wait to use D at work,
replacing C++ and Java. I'm still patiently waiting for that day. With
C++/CLI soon a reality, improvements to C++ coming, together with
existing versions of C# and Java, all with huge libraries ready to use
out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

I think D 1.0 is the day you are ready to make D public and face scrutinization from all those c++ programmers, and the day when people will start to think of D not as a concept but a serious language. Sure, you could call it 1.0 now, but are you ready for the aftermath? It would be tragic for the vast majority of people to try D 1.0, get a false impression from (insert bug/whatever) here, and never try it again. Then again, theoretically, the sooner D goes out the door, the better chance it may have to gain a foothold on the other c++ improvements (C#, Java), unless you think those languages arn't competitive to D and cater to different markets. (D seems to be for low level stuff, and Java C# high level GUI type stuff). If I were W, I would set a 1.0 date for D and release it with the book so that you will have the time to critically analize D and iron it out into a smooth machine, before the c++ programmer's can get ahold of it, critically anylize it, and try to dismiss it for (insert random drawback here). Cause ya know, from momentum, c++ is not going to be easily pushed aside for D.

I think those are some excellent thoughts! I think I first noticed something about this "new language called D" back last Feb. or so, not all that long after I started on a project that made heavy use of C/++. At the time, since I was in the process of investing a bunch of time becoming (hopefully) proficient (again) with the C/++ language, lib. and tools I'd be using, I dismissed it with all kinds of thoughts like "alot of features, ergo alot of baggage, ergo Java performance and portability issues, etc..". All this to say that I was a skeptical C++ programmer who didn't give it much of a 2nd look until I got kind of tired of C/++ (again) and wanted to play a little and/or look for a better way. It's tough to let go of an 'in-demand' language like C++, esp. since it takes time and effort to get up to speed with. There are probably many others out there like that who are or will be in the same boat, itching to try a new "better C++" language like D, but won't give it much of a chance unless the tools are stable and the tools do what a stable set of docs. say they should. I think a good strategy for right now is to freeze the specs., make sure they are reflected accurately in stable docs. and fix the issues pertaining to the frozen v1.0 specs. that have been highlighted by DStress. - Dave
Mar 02 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
clayasaurus wrote:
<snip>
 I think D 1.0 is the day you are ready to make D public and face 
 scrutinization from all those c++ programmers, and the day when people 
 will start to think of D not as a concept but a serious language. Sure, 
 you could call it 1.0 now, but are you ready for the aftermath? It would 
 be tragic for the vast majority of people to try D 1.0, get a false 
 impression from (insert bug/whatever) here, and never try it again.

Taken the words out of my mouth there. I guess a good sign of progress is the DStress success rate. As of 0.113 (the last column on the current DStress results page) it is 77%. I guess when it gets to 90% (by which time it'll be a slightly more realistic figure as more testcases'll have been added), it'll be time to look again at how ready for 1.0 we are.
 Then again, theoretically, the sooner D goes out the door, the better 
 chance it may have to gain a foothold on the other c++ improvements (C#, 
 Java), unless you think those languages arn't competitive to D and cater 
 to different markets.

I guess that those languages both are competitive to D and cater to different markets. To put it simply, there would be some overlap between the "Who D is For", "Who Java is For" and "Who C# is For" lists. For example: "Programmers who enjoy the expressive power of C++ but are frustrated by the need to expend much effort explicitly managing memory and finding pointer bugs." Before I discovered D I was pretty much a regular C++ user. But I found myself doing some OOP stuff in Java, basically because certain OOP tasks (such as expression manipulation) benefit heavily from GC and seemed tricky to do in C++. Now that we have D, it is my choice of language for similar purposes. Of course, that might mean that "People who haven't discovered D" is one effective item on the "Who Java is For" list....
 (D seems to be for low level stuff, and Java C# high level GUI type
 stuff).

I personally guess D is for middle-level stuff....
 If I were W, I would set a 1.0 date for D and release it with the book 
 so that you will have the time to critically analize D and iron it out 
 into a smooth machine, before the c++ programmer's can get ahold of it, 
 critically anylize it, and try to dismiss it for (insert random drawback 
 here). Cause ya know, from momentum, c++ is not going to be easily 
 pushed aside for D.

You're probably right. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 02 2005
prev sibling next sibling parent reply Linguo <linguo simpsons.invalid> writes:
clayasaurus wrote:
 Then again, theoretically, the sooner D goes out the door, the better 
 chance it may have to gain a foothold on the other c++ improvements (C#, 
 Java), unless you think those languages arn't competitive to D and cater 
 to different markets. (D seems to be for low level stuff, and Java C# 
 high level GUI type stuff).

Then again, theoretically, the sooner D goes out of the door, the better chance it may have to gain a foothold on the other C++ improvements (C# and Java), unless you think those languages aren't competitive with D and cater for different markets. (D seems to be for low-level stuff, and Java and C# for high-level GUI-type stuff.)
 If I were W, I would set a 1.0 date for D and release it with the book 
 so that you will have the time to critically analize D and iron it out 
 into a smooth machine, before the c++ programmer's can get ahold of it, 
 critically anylize it, and try to dismiss it for (insert random drawback 
 here).

If I were W, I would set a 1.0 date for D and release it with the book, so that I would have the time to critically analyse D and iron it out into a smooth machine, before the C++ programmers can get hold of it, critically analyse it, and try to dismiss it for (insert random drawback here).
Mar 02 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Linguo" <linguo simpsons.invalid> wrote in message
news:d04vu4$dvk$1 digitaldaemon.com...
 clayasaurus wrote:
 Then again, theoretically, the sooner D goes out the door, the better
 chance it may have to gain a foothold on the other c++ improvements
 (C#, Java), unless you think those languages arn't competitive to D
 and cater to different markets. (D seems to be for low level stuff,
 and Java C# high level GUI type stuff).

Then again, theoretically, the sooner D goes out of the door, the better chance it may have to gain a foothold on the other C++ improvements (C# and Java), unless you think those languages aren't competitive with D and cater for different markets. (D seems to be for low-level stuff, and Java and C# for high-level GUI-type stuff.)
 If I were W, I would set a 1.0 date for D and release it with the
 book so that you will have the time to critically analize D and iron
 it out into a smooth machine, before the c++ programmer's can get
 ahold of it, critically anylize it, and try to dismiss it for (insert
 random drawback here).

If I were W, I would set a 1.0 date for D and release it with the book, so that I would have the time to critically analyse D and iron it out into a smooth machine, before the C++ programmers can get hold of it, critically analyse it, and try to dismiss it for (insert random drawback here).

I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0? Or something like that ...
Mar 02 2005
next sibling parent reply "Carlos Santander B." <csantander619 gmail.com> writes:
Matthew wrote:
 
 I agree that the book's release and 1.0 coinciding would be nice, but 
 it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 
 1.0 is out mid-year, the pre-release book extract articles can be tied 
 in with it, and in that way the book'd coincide with D 1.1, which'll be 
 a large bug fix improvement of 1.0?
 
 Or something like that ...
 
 
 

I agree that 1.0 should wait for the book, but I think bug fixing should be a 1.0 goal and not 1.1. _______________________ Carlos Santander Bernal
Mar 02 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <csantander619 gmail.com> wrote in message 
news:d058mm$ndf$2 digitaldaemon.com...
 Matthew wrote:
 I agree that the book's release and 1.0 coinciding would be nice, but 
 it's unlikely that the book'll be in the shops before Nov/Dec. Maybe 
 if 1.0 is out mid-year, the pre-release book extract articles can be 
 tied in with it, and in that way the book'd coincide with D 1.1, 
 which'll be a large bug fix improvement of 1.0?

 Or something like that ...

I agree that 1.0 should wait for the book, but I think bug fixing should be a 1.0 goal and not 1.1.

Of course. I simply meant that 1.1 will inevitably be a response to all the things that crop up as a consequence of 1.0. We cannot anticipate everything. ;)
Mar 02 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "Linguo" <linguo simpsons.invalid> wrote in message
 news:d04vu4$dvk$1 digitaldaemon.com...
 
clayasaurus wrote:

Then again, theoretically, the sooner D goes out the door, the better
chance it may have to gain a foothold on the other c++ improvements
(C#, Java), unless you think those languages arn't competitive to D
and cater to different markets. (D seems to be for low level stuff,
and Java C# high level GUI type stuff).

Then again, theoretically, the sooner D goes out of the door, the better chance it may have to gain a foothold on the other C++ improvements (C# and Java), unless you think those languages aren't competitive with D and cater for different markets. (D seems to be for low-level stuff, and Java and C# for high-level GUI-type stuff.)
If I were W, I would set a 1.0 date for D and release it with the
book so that you will have the time to critically analize D and iron
it out into a smooth machine, before the c++ programmer's can get
ahold of it, critically anylize it, and try to dismiss it for (insert
random drawback here).

If I were W, I would set a 1.0 date for D and release it with the book, so that I would have the time to critically analyse D and iron it out into a smooth machine, before the C++ programmers can get hold of it, critically analyse it, and try to dismiss it for (insert random drawback here).

I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0?

Good point. With the bosses it's Kommon Noledge to never use a 1.0 anyway.
Mar 02 2005
prev sibling next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
 If I were W, I would set a 1.0 date for D and release it with the

 so that you will have the time to critically analize D and iron it

<alert comment="ianawndipootv ... i am not a writer ..."> Some years back, Bruce Eckel released one or more of his books electronically. (C/C++/Java?) Seemed like an interesting concept, but I don't have the impression that approach caught on ... Seems to have enormous potential to "speed a 'book' to market", however. I don't think writers over the age of 22 expect to actually make any money at their endeavors. The overhead of getting a hardback / paperback to a shelf in a bookstore has top be enormous. Seems like an electronic book could resemble a "wiki" that was more or less moderated. </alert>
Mar 02 2005
prev sibling parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
 I think D 1.0 is the day you are ready to make D public and face
 scrutinization from all those c++ programmers,

I wonder how much "affection and fondness" C++ programmers have for it. <alert comment="war stories from older newbie"> I started using C in the early 80's and thought it was pretty primitive and "dangerous". I actually kind of liked Ada for the rigor it imposed ... if you had a dedicated VAX for compiles and/or worked late at night. I was on a project about '87 that used the AT&T C++ 1.2 CppFront and thought the concept was brilliant. Single inheritance, no templates/generics, no STL. no exceptions. When the native compilers from Borland and others came out, I was one happy techie. (I think this is about the time frame that The WB started being noticed ... could be wrong) But I never cared for C++ 2.0. Just an ugly 'pug' of a language. Yuck. The "gotchas" of C were traded for the obscurity and "what in the world is going on" of C++ 2.0. I try not to use the capabilities of C++ that go much beyond 1.2. I recall admiring how Ada did exceptions and templates, but the C++ approach seemed deeply flawed and just unreadibly ugly. The C++ world seems tremendously interested in using the template/generic capability to write "Game Of Life" code. That's bizarre. </alert>
Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:d05fb0$109c$1 digitaldaemon.com...
 The "gotchas" of C were traded for the obscurity and "what in the
 world is going on" of C++ 2.0. I try not to use the capabilities of
 C++ that go much beyond 1.2. I recall admiring how Ada did exceptions
 and templates, but the C++ approach seemed deeply flawed and just
 unreadibly ugly.

C++'s groundbreaking ideas w.r.t. generic programming are, in a word, brilliant. But I, too, find the expression of those ideas in the C++ syntax to be so flawed as to be well nigh unusable. The use of < > in particular. My brain simply refuses to parse them as if they were brackets. But that by itself might be passable, but the nail in the coffin was then overloading << and >>, and then making the classes that overloaded them templates themselves using < and > !! It has all the visual appeal of gibberish. I aimed to fix that in D. I love templates and generic programming, but it's got to look right.
 The C++ world seems tremendously interested in using the
 template/generic capability to write "Game Of Life" code. That's
 bizarre.

It's good that there are people who push the limits like that, it's the way progress is made. Some of that stuff is so 'out there' is it really even C++ anymore? Is C++ just the 'machine code' of a new language layered on top of it?
Mar 02 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter wrote:

The C++ world seems tremendously interested in using the
template/generic capability to write "Game Of Life" code. That's
bizarre.

It's good that there are people who push the limits like that, it's the way progress is made. Some of that stuff is so 'out there' is it really even C++ anymore? Is C++ just the 'machine code' of a new language layered on top of it?

Some of Boost, but especially this "Game of Life" business really is out there to show off. It's a shame that the in-built competitiveness in humans can sometimes turn to endeavours less worth than the effort. The Eiffel tower, Statue of Liberty, WTC towers, having a newer car than your neighbor, unassisted deep diving world records. Awwwwwww. What person in their right mind aspires for World Chess Champion? That capacity would be put to a lot more use for mankind in so many other ways. At least Larry Ellison gave us a database, as a side effect of his actual personal ambitions. OTOH, if all this brain power and time would be used to improve on the C++ template system, instead of showing off _within_ it, then D'd be in for a much rougher ride! :-)
Mar 03 2005
parent "Walter" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4226E899.9050301 nospam.org...
 What person in their right mind aspires for World Chess Champion? That
 capacity would be put to a lot more use for mankind in so many other
 ways.

It's funny you said that. When I was a kid, I enjoyed playing chess. When I started programming computers, when I'd play chess, instead of thinking about my next move I was always designing a program that would figure it out for me. (Causing me to play rather poorly.) I now find chess to be rather dull. Writing programs scratches the same itch, but in the end you actually accomplish something, which is infinitely more satisfying.
Mar 03 2005
prev sibling parent "Charlie Patterson" <charliep1 excite.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d05hcn$12oe$1 digitaldaemon.com...
 C++'s groundbreaking ideas w.r.t. generic programming are, in a word,
 brilliant. But I, too, find the expression of those ideas in the C++ 
 syntax
 to be so flawed as to be well nigh unusable.

Maybe you've see the interview with the authors, but they had planned to write a new language to support the idea of generic programming. Then templates were coming along and, I think, Stroustrup convinced them to write the STL. They claim happiness, but I don't think it turned out as expected. Anyway, if all this is true, it's another good example of placing a stake to early. I think Java was moving in about then and the C++ people were probably desperate to show off the power of a more complete language so they rushed out templates and STL. (Not that this was expressed in the article.) Now we're stuck with it and the only way "back" is with a new language.
Mar 04 2005
prev sibling next sibling parent reply Kramer <Kramer_member pathlink.com> writes:
In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
"Jason Mills" <jmills cs.mun.ca> wrote in message
news:d04ccv$2nh7$1 digitaldaemon.com...
 I have been reading this newsgroup for several years. Although I post
 rarely I do read it every day. Early on I was so enthusiastic about D I
 could barely contain myself. I could not wait to use D at work,
 replacing C++ and Java. I'm still patiently waiting for that day. With
 C++/CLI soon a reality, improvements to C++ coming, together with
 existing versions of C# and Java, all with huge libraries ready to use
 out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

What about releasing it along side the book you and Matthew are doing? There could be things that come to light while writing the book that you may want to fix/add/improve upon. (That said, I'm excersing some restraint here. I'd like 1.0. But I want it bulletproof (I know nothing ever is, but you know what I mean <g>). -Kramer
Mar 02 2005
parent "Walter" <newshound digitalmars.com> writes:
"Kramer" <Kramer_member pathlink.com> wrote in message
news:d04s2v$8sj$1 digitaldaemon.com...
 What about releasing it along side the book you and Matthew are doing?

 could be things that come to light while writing the book that you may

 fix/add/improve upon.

That is a good idea, but books take a long time to write and even longer to publish. It's too far out.
 (That said, I'm excersing some restraint here.  I'd like 1.0.  But I want

 bulletproof (I know nothing ever is, but you know what I mean <g>).

I know what you mean. I've put a lot of priority on fixing all the crashers. Nothing gives a negative impression like crashing.
Mar 02 2005
prev sibling next sibling parent reply "Charlie Patterson" <charliep1 excite.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d04p7a$550$1 digitaldaemon.com...
 I've found myself wondering over the last few months what "1.0" actually 
 is.
 Since D will undergo continuous improvement regardless, why don't we just
 drive a stake in the ground and call what we have "1.0"?

If you have a big enough helper base, I'd say you need to treat it like any other product and make sure the whole package is ready. I get the impression that this still has the feel of a hobby project which means the team will get around to specs, better tutorials and bug fixes when they feel like it. It's a fun stage, but I don't think it will work in the commercial/professional world. You have to go from a project to a product. I'm not a product manager, but I think a 'product' must assess what a customer needs to really feel comfortable with choosing D. The language itself is probably only half of it. I think the product will then include * Is attitude correct? * Stop the moving target, or at least fake it. People don't like incomplete things. Make it stationary and live with it. (See roadmap.) * got to make people feel supported, not like they are following a temperamental hobbyist. * promise yourselves bugs will be fixed in an almost instant manner * create a newsgroup for support instead of feature debate * make sure you are ready to make real-world trade-offs see .Net below for example * 'marketing' materials * clean up language comparison on D site * add to site a little; make friendlier * a confident roadmap features for 1.0, in stone features for 1.1, in stone, Fall 05 features for 2.0, fixed but appendable, 2006 (again, this should increase other's confidence) * documentation * a complete spec no one is going to believe this is open (especially not slashdot) until the spec is complete * a complete reference manual you have most of this on the site. get it cleaned and bound? * a complete programmer's manual keep it simple and non-didactic. maybe keep it brief for programmers who know C already. maybe even for those who know C++ or Java. A more thorough manual can probably be put off until next year. still make it a pdf and get it bound with the reference. * more tutorials especially ones written solving problems that the authors were originally thinking of when they designed certain features. * D no known bugs for 1.0 * a great library I think this should be most of the focus at this point. I haven't looked at phobos or dtl or whatever, but I think a major point for Java is the promise that there is one main library with all you'll need to get started. Even though there were many mistakes in Date, AWT, etc. And even though any one with experience must roll their eyes at such a promise of "one and only," this promise was huge to acceptance IMO. (And it is frustrating to work in C or Linux and have too many, similar choices of lib and none seem to become a standard.) The promise of backward-compatibility with C libs is huge, but not enough. Is the Java lib worth copying and only fixing the problems? This would probably provide comfort for lots of programmers. To combine the value of Java's inclusive libraries with C++'s generic programming, you could create the ultimate container classes and let the group fight it out for a month to get the spec perfect. Anyone have ideas on how other toolkits fell short in design (not just completeness)? Now is the time to fix that. Anyway, the lib should include most of all the components that the original Java or .Net did. I think the world is still waiting on a wonderful GUI library. The same mistakes keep getting repeated. It would be wonderful if D had it's own amazing AWT with delegates, true objects but only when sensible, easy parameterization, etc. I have lots of thoughts in this area. * does it work with .NET? Some may have ideological reasons against it, but this would be huge, also. It is the big "silver bullet" right now. .Net has figured out that it is all about libraries nowadays and you can use any lang to connect to their libs. So you both leverage all that programmer knowledge and you fit in with the latest direction. (I don't know .NET myself.) Feel free to modify the list. Discuss. (-:
Mar 02 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Charlie Patterson" <charliep1 excite.com> wrote in message
news:d04ugr$c1t$1 digitaldaemon.com...
 Feel free to modify the list.  Discuss.  (-:

Some very good points. Documentation: If someone wants to go through the current spec with a critical eye, and send me a detailed critique on it (or at least focus on some particular part of it), so that can be improved, it would be a big help. I go through it from time to time, each time noticing new things and fixing them, but reviewing one's own writing is not so effective since one sees what one intended to write, not what is actually there. Library: Microsoft and Sun pour resources into libraries for .net and Java. I don't have those resources. I can do the basic core library, and I'm reasonably happy with it in Phobos. But more thorough libraries are going to have to come from the D community, for example Kris' Mango library, Vathix's socket routines, and Matthew's recls. There may be a chicken and egg thing with writing libraries - people may hold back on expending the considerable effort of doing one because D isn't 1.0, and yet consider D not 1.0 ready without it. This kind of motivates me to drive the stake in the ground now and call it 1.0. Some libraries for certain areas can only be written by someone who has a consuming interest in that segment, they can't be casually done. For example, std.regexp needed a complex and intense focus to get it written, tested, and debugged. Doing that had little to do with D itself, it being coded in D is pretty much incidental. Some stuff only I can reasonably do because it is tightly coupled with the compiler, such as the associative array implementation. But that kind of stuff is complete, and ready to rock. When I look at, say, Python's libraries, I think we've got the essential stuff covered except for a standard gui library.
Mar 02 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

 Documentation:
 
 If someone wants to go through the current spec with a critical eye, and
 send me a detailed critique on it (or at least focus on some particular part
 of it), so that can be improved, it would be a big help. I go through it
 from time to time, each time noticing new things and fixing them, but
 reviewing one's own writing is not so effective since one sees what one
 intended to write, not what is actually there.

Well, you could start with the Wiki4D - since that is the method of leaving feedback that is recommended on *each* official page, but still has a lot of typos and other corrections that haven't made into back into the offical spec pages a few years later ? Just delete them from the Wiki page, after correcting them... (leaving just the discussion and controversy on the Wiki4D) --anders
Mar 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d06l3n$284u$1 digitaldaemon.com...
 Walter wrote:

 Documentation:

 If someone wants to go through the current spec with a critical eye, and
 send me a detailed critique on it (or at least focus on some particular


 of it), so that can be improved, it would be a big help. I go through it
 from time to time, each time noticing new things and fixing them, but
 reviewing one's own writing is not so effective since one sees what one
 intended to write, not what is actually there.

Well, you could start with the Wiki4D - since that is the method of leaving feedback that is recommended on *each* official page, but still has a lot of typos and other corrections that haven't made into back into the offical spec pages a few years later ? Just delete them from the Wiki page, after correcting them... (leaving just the discussion and controversy on the Wiki4D)

Good, I'll do that.
Mar 03 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

Just delete them from the Wiki page, after correcting them...
(leaving just the discussion and controversy on the Wiki4D)

Good, I'll do that.

I tried to update the summary page for you: http://www.prowiki.org/wiki4d/wiki.cgi?DocumentationAmendments --anders
Mar 03 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Charlie Patterson wrote:
 "Walter" <newshound digitalmars.com> wrote in message 
 news:d04p7a$550$1 digitaldaemon.com...
 
I've found myself wondering over the last few months what "1.0" actually 
is.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

If you have a big enough helper base, I'd say you need to treat it like any other product and make sure the whole package is ready. I get the impression that this still has the feel of a hobby project which means the team will get around to specs, better tutorials and bug fixes when they feel like it. It's a fun stage, but I don't think it will work in the commercial/professional world. You have to go from a project to a product. I'm not a product manager, but I think a 'product' must assess what a customer needs to really feel comfortable with choosing D. The language itself is probably only half of it. I think the product will then include * Is attitude correct? * Stop the moving target, or at least fake it. People don't like incomplete things. Make it stationary and live with it. (See roadmap.) * got to make people feel supported, not like they are following a temperamental hobbyist. * promise yourselves bugs will be fixed in an almost instant manner * create a newsgroup for support instead of feature debate * make sure you are ready to make real-world trade-offs see .Net below for example * 'marketing' materials * clean up language comparison on D site * add to site a little; make friendlier * a confident roadmap features for 1.0, in stone features for 1.1, in stone, Fall 05 features for 2.0, fixed but appendable, 2006 (again, this should increase other's confidence) * documentation * a complete spec no one is going to believe this is open (especially not slashdot) until the spec is complete * a complete reference manual you have most of this on the site. get it cleaned and bound? * a complete programmer's manual keep it simple and non-didactic. maybe keep it brief for programmers who know C already. maybe even for those who know C++ or Java. A more thorough manual can probably be put off until next year. still make it a pdf and get it bound with the reference. * more tutorials especially ones written solving problems that the authors were originally thinking of when they designed certain features. * D no known bugs for 1.0 * a great library I think this should be most of the focus at this point. I haven't looked at phobos or dtl or whatever, but I think a major point for Java is the promise that there is one main library with all you'll need to get started. Even though there were many mistakes in Date, AWT, etc. And even though any one with experience must roll their eyes at such a promise of "one and only," this promise was huge to acceptance IMO. (And it is frustrating to work in C or Linux and have too many, similar choices of lib and none seem to become a standard.) The promise of backward-compatibility with C libs is huge, but not enough. Is the Java lib worth copying and only fixing the problems? This would probably provide comfort for lots of programmers. To combine the value of Java's inclusive libraries with C++'s generic programming, you could create the ultimate container classes and let the group fight it out for a month to get the spec perfect. Anyone have ideas on how other toolkits fell short in design (not just completeness)? Now is the time to fix that. Anyway, the lib should include most of all the components that the original Java or .Net did. I think the world is still waiting on a wonderful GUI library. The same mistakes keep getting repeated. It would be wonderful if D had it's own amazing AWT with delegates, true objects but only when sensible, easy parameterization, etc. I have lots of thoughts in this area. * does it work with .NET? Some may have ideological reasons against it, but this would be huge, also. It is the big "silver bullet" right now. .Net has figured out that it is all about libraries nowadays and you can use any lang to connect to their libs. So you both leverage all that programmer knowledge and you fit in with the latest direction. (I don't know .NET myself.) Feel free to modify the list. Discuss. (-:

Thought provoking! The other day I was pondering over, _how_ would D really beat enough corn stalks to stake out a significant patch on the field. A parallel that came to mind was that between Linux and Windows. The W crowd have a fixed set of programmers, all "just trying to get the task at hand finished before Frday". The L crowd don't mind how much thinking or typing (er, usually together called "programming") it takes, as long as the end result is something you dare to show the community with your own name. (Or handle.) Standard issue today in Open Source (OS) development is having a place in an existing infrastructure of Fast and Serious multi-multi-programmer environment. Bug routing facilities, source code repositories, mailing lists with fine-grain sections, ad-hoc-like on-going regrouping of human resources, well divided task sections (like Documentation, Testing, Conceptualising, Project Management, Code Writing, Install Package Management, Platrofm Issues, PR-activities, etc.) All of these are taken care of in the infrastructure. Today, we have dsource, Digital Mars D documentation pages, this newsgroup, an IRC channel, and a few other things. But they're all separate islands. I know that Walter wants (and should) keep the back-end Proprietary. No problem. But everything else should be handled like OS does. With all facilities taken maximum benefit from. --- I just installed Fedora Core 3. While I was somewhat disimpressed with the initial user experience, I have to admit, both FC, Gnome, and KDE-apps have made serious technical advancements since the last free RH release. That made me feel sorry for Bill Gates. He goes on linearly (or might I venture to say, logarithmically), while the opponents go O(squared), if not even O(exponential). 5 years from now, and he'll have a heck of a time convincing everyone of the Emperor's Clothes. (Heck, even Apple, the epitome of Closed Source, lock-in, patronising, and customer hoarding -- gave up by Os X!) Using that metaphor, C++ is like an aircraft carrier. Of course you can shoot dead an entire nation with it. But times change. Today, the words are Agility, Rate of Development, ability to Answer to Today's Demands, and, last but not least -- a dedicated community! With these, we ought to fly circles around C++. And not even need a staff of 2000 just to get from Washington DC to New York. Another thought: what if we adopt some Open Source startegies to improve the rate of advancement? My dream would be that we use _all_ methods available, to speed up D development. Including documentation, libraries, suggestions to Phobos, package management and distribution, -- everything. ---- I know Walter's too busy (and dammit, _should_ be too busy) to set all this up, so we need somebody else to put up The Authoritative Development Environment (a la Sourceforge, etc.), with Walter's blessing, and _under_his_command_. ((( Jan Knepper, are you listening?? You might use the thing for a lot of good for yourself, too! ))) For all I know, this could even be an Invitation Only Site. But that's not for me to decide.
Mar 02 2005
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter wrote:
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d04ccv$2nh7$1 digitaldaemon.com...
 
I have been reading this newsgroup for several years. Although I post
rarely I do read it every day. Early on I was so enthusiastic about D I
could barely contain myself. I could not wait to use D at work,
replacing C++ and Java. I'm still patiently waiting for that day. With
C++/CLI soon a reality, improvements to C++ coming, together with
existing versions of C# and Java, all with huge libraries ready to use
out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

Is it possible to wait till we get the regexps in D? The it would be just so cool! (I know, this is based on feeling only, but still?)
Mar 02 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d04p7a$550$1 digitaldaemon.com...
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d04ccv$2nh7$1 digitaldaemon.com...
 I have been reading this newsgroup for several years. Although I post
 rarely I do read it every day. Early on I was so enthusiastic about D
 I
 could barely contain myself. I could not wait to use D at work,
 replacing C++ and Java. I'm still patiently waiting for that day.
 With
 C++/CLI soon a reality, improvements to C++ coming, together with
 existing versions of C# and Java, all with huge libraries ready to
 use
 out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

Is it a commercially viable language yet? IMO it is not. I think 1.0 should be whenever it is. The crux of that is how do we determine when it becomes so. Any ideas on criteria? Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?
Mar 02 2005
next sibling parent reply "bamb00" <no email.com> writes:
 Is it a commercially viable language yet? IMO it is not.

 I think 1.0 should be whenever it is.

Well put.
 Any ideas on criteria?

I think DStress has setup a good 'score board'. I like your idea on getting people that aren't fans of the language, maybe time to setup a 'hostile focus group' :). Charlie "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d056ph$lnj$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:d04p7a$550$1 digitaldaemon.com...
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d04ccv$2nh7$1 digitaldaemon.com...
 I have been reading this newsgroup for several years. Although I post
 rarely I do read it every day. Early on I was so enthusiastic about D
 I
 could barely contain myself. I could not wait to use D at work,
 replacing C++ and Java. I'm still patiently waiting for that day.
 With
 C++/CLI soon a reality, improvements to C++ coming, together with
 existing versions of C# and Java, all with huge libraries ready to
 use
 out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

Is it a commercially viable language yet? IMO it is not. I think 1.0 should be whenever it is. The crux of that is how do we determine when it becomes so. Any ideas on criteria? Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?

Mar 02 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Several times over the past few weeks I've said, in support of 
not-entirely-calm debates, that I don't feel that D is commercially 
ready.

Maybe the time has come for several/many of us to identify pet projects 
that we each have, and see if / how well some/all of them may be 
implemented in D.

For me, my projects are:

    shellext.com (http://shellext.com/)
    recls (http://recls.org/)
    Open-RJ (http://openrj.org/)
    STLSoft (http://stlsoft.org/)
    DTL
    b64 (http://synesis.com.au/software/)
    Synesis Software System Tools (http://synesis.com.au/systools.html)
    Arturius (http://arturius.org/ - not yet available in any form)

shellext.com - medium size, complete (for the moment)
------------

This is just a bunch of Windows shell extensions that I've done over the 
years. I don't think it's worth the costs in time for me to reimplement 
the existing ones in D, but I'd be happy to (try to) implement any new 
ones in it. All it needs are some requests/ideas, as the extant set 
pretty much covers my Windows shell needs.

recls - medium size, evolving
-----

This is a C/C++ project, and must remain so, since it's mapped to lots 
of different languages. It's sufficiently complex that I would be loathe 
to do separate implementations for different languages. (Note: this is 
about to have three new releases 1.5.3, 1.6.1 and 2.0 over the next few 
months, so expect std.recls in Phobos to _finally_ meet the 
documentation <g>)

Open-RJ - medium size, evolving
-------

This is a C project, with mappings to lots of different languages. 
Walter rejected the D mapping some time ago, and provided a 60% feature 
complete version if half a page of D: impressive. Since I can't let him 
outdo me, I will be doing the Open-RJ/D implementation entirely in D, 
sometime soonish.

STLSoft - large, evolving
-------

Walter's said to me many times that he hopes that I will gradually move 
STLSoft into D. Bits may come and go, but the philosophy of STLSoft is 
not entirely congruent with D.

DTL - large, currently inactive
----

Well, ahem, this is a D project. Just waiting for a clear desk for me to 
roll on it. Will most likely be driven by writing of DPD

b64 - very small, completed
----

Tiny little C library (with no dependencies on anything, which is 
nice!).

D already this, so not an issue.

System Tools - medium, stable
------------

Some of these would be excellent candidates for rewriting in D.

Arturius - large, pre-release development
--------

This is a compiler multiplexer, that is really useful and groovy, but 
not (yet) in a releasable state. I plan to use DMDScript in it, and also 
to write some of the filters in D. This'll receive more attention from 
me as it's going to be a dual proving ground for the research for 
"Extended STL" and for DPD. But it'll be some time ...



So, it looks to me like I (personally) will get a better feeling for D's 
commercial readiness by doing:

    Open-RJ/D (this is planned to happen in next month or two)
    implementing DTL and new Arturius filters (this will be happening 
over next 2-3 months)
    any new (persuasive) Shell Extension requests
    maybe taking a couple of the system tools and reimplementing in D


None of these are huge projects - such as the size of Mango - apart from 
maybe DTL, but they would certainly inform, for me, on what I've been 
pontificating about over recent times.


May I suggest that others identify things that they are doing, or might 
do, in D, and we can identity a quorum of projects with which we can set 
D-1.0 acceptance criteria? Then we've got boxes to tick, which is nice 
...


Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

Synesis Software Pty Ltd
P.O.Box 125
Waverley
New South Wales, 2024
Australia

-----------------------------------------------------
Mar 02 2005
next sibling parent "Nick Sabalausky" <z a.a> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d059o0$oqo$2 digitaldaemon.com...
 Several times over the past few weeks I've said, in support of 
 not-entirely-calm debates, that I don't feel that D is commercially ready.

 Maybe the time has come for several/many of us to identify pet projects 
 that we each have, and see if / how well some/all of them may be 
 implemented in D.

I wrote a couple of indie/budget games for windows a few years ago (A breakout clone and a centepede clone). The existing code for both is awful, so I've just started on a complete rewrite of both in D, which will end up as "Deluxe" versions with extra features (replacing the old versions).
Mar 02 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 3 Mar 2005 08:03:58 +1100, Matthew wrote:

 Several times over the past few weeks I've said, in support of 
 not-entirely-calm debates, that I don't feel that D is commercially 
 ready.
 
 Maybe the time has come for several/many of us to identify pet projects 
 that we each have, and see if / how well some/all of them may be 
 implemented in D.
 
 For me, my projects are:

** Build ---------------- This is a utility to make compiling D applications a piece of cake. It is designed to remove the need for make files. Currently its at V1.9 (build #342) which is fairly stable now. http://www.dsource.org/projects/build ** Euphoria-to-D translator --------------------------- I love using the Euphoria language for applications that don't need blistering speed (its an interpreted language). It is sort of like a dynamically typed D. But there are two aspects that irk me though. (a) Sometimes a bit of speed is required, but not As Fast As Possible type speed. So translating Euphoria to D then compiling the D code should help speed up things. (b) It is not open source, and the "Walter"-type that controls its evolution is really slow to add anything useful, and resists 'modernization'. Euphoria was designed in 1993 and is still only at v2.4. So this is my first step in creating an open source version of a language translator. This will be a springboard for creating an alternative interpreter. Currently, I'm implementing the built-in data types (all four of them) supported by Euphoria - integer, atom, sequence and object. This is progressing well and I'm about 50% done with that phase. ** Windows Application Development Library ------------------------------------------ In Euphoria I've developed, with help from others, a *huge* library that makes developing Windows applications a whole lot easier. I would like to port this library, or at least what I've learned about developing Windows Apps, over to D. I haven't started yet. But I do have 40,000+ lines of Euphoria code to work with ;-) The "Hello World" program could look something like ... import winapp; int Application() { createForm("Window, Hello World", "Button, Close, Flag=autoclose" ); return 0; } -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 3/03/2005 11:28:11 PM
Mar 03 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1megwbcgd48m4$.abrxmvtejvwi$.dlg 40tude.net...
 ** Windows Application Development Library
 ------------------------------------------
 In Euphoria I've developed, with help from others, a *huge* library that
 makes developing Windows applications a whole lot easier. I would like to
 port this library, or at least what I've learned about developing Windows
 Apps, over to D.

I think this would be a very valuable effort. Also, does Euphoria have a gui package that could be translated? C++ gui libraries just seem to be highly resistant to translating :-(, perhaps Euphoria will make it easier?
Mar 03 2005
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
** Euphoria-to-D translator
---------------------------
I love using the Euphoria language for applications that don't need
blistering speed (its an interpreted language). It is sort of like a
dynamically typed D. But there are two aspects that irk me though.
  (a) Sometimes a bit of speed is required, but not As Fast As Possible
type speed. So translating Euphoria to D then compiling the D code should
help speed up things.
  (b) It is not open source, and the "Walter"-type that controls its
evolution is really slow to add anything useful, and resists
'modernization'. Euphoria was designed in 1993 and is still only at v2.4.

So this is my first step in creating an open source version of a language
translator. This will be a springboard for creating an alternative
interpreter. Currently, I'm implementing the built-in data types (all four
of them) supported by Euphoria - integer, atom, sequence and object. This
is progressing well and I'm about 50% done with that phase.

please post link to this language.
Mar 04 2005
parent J C Calvarese <jcc7 cox.net> writes:
In article <d09vbl$1d09$1 digitaldaemon.com>, Mark T says...
** Euphoria-to-D translator
---------------------------
I love using the Euphoria language for applications that don't need
blistering speed (its an interpreted language). It is sort of like a
dynamically typed D. But there are two aspects that irk me though.
  (a) Sometimes a bit of speed is required, but not As Fast As Possible
type speed. So translating Euphoria to D then compiling the D code should
help speed up things.
  (b) It is not open source, and the "Walter"-type that controls its
evolution is really slow to add anything useful, and resists
'modernization'. Euphoria was designed in 1993 and is still only at v2.4.

So this is my first step in creating an open source version of a language
translator. This will be a springboard for creating an alternative
interpreter. Currently, I'm implementing the built-in data types (all four
of them) supported by Euphoria - integer, atom, sequence and object. This
is progressing well and I'm about 50% done with that phase.

please post link to this language.

I think this is the "official" Euphoria web site if that's what you're seeking: http://www.rapideuphoria.com/ jcc7
Mar 04 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
bamb00 wrote:
Is it a commercially viable language yet? IMO it is not.

I think 1.0 should be whenever it is.

Well put.
Any ideas on criteria?

I think DStress has setup a good 'score board'. I like your idea on getting people that aren't fans of the language, maybe time to setup a 'hostile focus group' :).

I think the biggest advantage/burden of D is that is doesn't not link to C++ very well. The problem being that, say you want to use a lib in C++ (like Qt) to make a GUI, you are going to have to make C bindings for it and then D'atize it again :-/ Also, you can't use D on the current game consoles (Xbox, PS/2), becaus e the dev kits all use c++. (please correct me if wrong) The people who depend heavily on c++ libs (like Qt), are those who we arn't going to be able to convert to D. Unless, of course, there is a mass re-write of c++ applications to D.
Mar 02 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message 
news:42262A7A.1080606 gmail.com...
 bamb00 wrote:
Is it a commercially viable language yet? IMO it is not.

I think 1.0 should be whenever it is.

Well put.
Any ideas on criteria?

I think DStress has setup a good 'score board'. I like your idea on getting people that aren't fans of the language, maybe time to setup a 'hostile focus group' :).

I think the biggest advantage/burden of D is that is doesn't not link to C++ very well. The problem being that, say you want to use a lib in C++ (like Qt) to make a GUI, you are going to have to make C bindings for it and then D'atize it again :-/ Also, you can't use D on the current game consoles (Xbox, PS/2), becaus e the dev kits all use c++. (please correct me if wrong) The people who depend heavily on c++ libs (like Qt), are those who we arn't going to be able to convert to D. Unless, of course, there is a mass re-write of c++ applications to D.

Hmm. For any readers of Imperfect C++'s chapter 8, Objects Across Borders, you'll be familiar with my invention of Portable Vtables. I've thought for a while about prodding Walter to see if we can have something along these lines built into D, so it'd be a lot easier than it is in C++. Then we can directly talk between the two languages in a binary-compatible form. Walter, you read those chapters - at least I hope you did - while reviewing the book. Do you think it'd be easy to adapt D, e.g. via a 'pinterface' keyword?
Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d05a7k$pl7$2 digitaldaemon.com...
 Walter, you read those chapters - at least I hope you did - while
 reviewing the book. Do you think it'd be easy to adapt D, e.g. via a
 'pinterface' keyword?

D can hook directly to C++ vtables, as long as the C++ class uses single inheritance. It becomes a COM interface. Don't actually need to worry about AddRef() and Release(). That said, I think the yoogest (too borrow from Trump) problem in interfacing with C++ is C++'s memory allocation strategies. A lot of those C++ libraries have their own MyFunkyStringClass, and it's use is all wrapped up in how they decided to do memory. Trying to hook that stuff up to D is such a mess it would be easier to reimplement it in D entirely.
Mar 02 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter wrote:
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d05a7k$pl7$2 digitaldaemon.com...
 
Walter, you read those chapters - at least I hope you did - while
reviewing the book. Do you think it'd be easy to adapt D, e.g. via a
'pinterface' keyword?

D can hook directly to C++ vtables, as long as the C++ class uses single inheritance. It becomes a COM interface. Don't actually need to worry about AddRef() and Release(). That said, I think the yoogest (too borrow from Trump) problem in interfacing with C++ is C++'s memory allocation strategies. A lot of those C++ libraries have their own MyFunkyStringClass, and it's use is all wrapped up in how they decided to do memory. Trying to hook that stuff up to D is such a mess it would be easier to reimplement it in D entirely.

Could this be (at least partially) alleviated with a Copy On Read strategy?
Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:42263C1C.5030009 nospam.org...
 Could this be (at least partially) alleviated with a Copy On Read

Perhaps. But then it's gotta be fed back in.
Mar 02 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Walter wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42263C1C.5030009 nospam.org...
 
Could this be (at least partially) alleviated with a Copy On Read

strategy? Perhaps. But then it's gotta be fed back in.

Right! And it may be too much work to fix the general case. In the mean time, one might get some success by restricting the effort to a manageable size. Eg. - only workable if the C++ and D coder are aware of each other - common data should be objects only - establish a simple how-to-program rule - KISS: limited applicability, but easy to code I wonder if there are de facto practices already for this? If not, I might have an idea. Oh, is there any real world use for this? Or do all cooperation projects really need the General solution?
Mar 03 2005
prev sibling next sibling parent reply "Carlos Santander B." <csantander619 gmail.com> writes:
Matthew wrote:
 
 Is it a commercially viable language yet? IMO it is not.
 
 I think 1.0 should be whenever it is.
 
 The crux of that is how do we determine when it becomes so.
 
 Any ideas on criteria?
 

Walter has said he has his own bugs database. I'd say then, 1.0 would be all of the bugs (or most of them, I don't know) are fixed.
 Another one might be when it can stand up to criticism from people who 
 have an inclination to dislike it, rather than from those (like me) who 
 are inclined to like it. I mean, if the people who are biased towards it 
 think it's not ready, surely it's not ready?
 
 

_______________________ Carlos Santander Bernal
Mar 02 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <csantander619 gmail.com> wrote in message 
news:d058mj$ndf$1 digitaldaemon.com...
 Matthew wrote:
 Is it a commercially viable language yet? IMO it is not.

 I think 1.0 should be whenever it is.

 The crux of that is how do we determine when it becomes so.

 Any ideas on criteria?

Walter has said he has his own bugs database. I'd say then, 1.0 would be all of the bugs (or most of them, I don't know) are fixed.

I just think that's too narrow-minded, and open to bias. After all, who in the whole world is likely to be the least critical about D? ;$ We need the skeptics _in this group_ to be convinced before we've any hope of convincing people from without. As such, I think Walter's the absolute worst qualified to stipulate when D's ready to roll out. (Sorry, mate!) That said, I don't think a sensible approach is to just randomly couch opinion from loud and opinionated types (such as me). I think we need something systematic (which I'm working on in a longer post I'm preparing now.)
Mar 02 2005
parent "Carlos Santander B." <csantander619 gmail.com> writes:
Matthew wrote:
 "Carlos Santander B." <csantander619 gmail.com> wrote in message 
 news:d058mj$ndf$1 digitaldaemon.com...
 
Walter has said he has his own bugs database. I'd say then, 1.0 would 
be all of the bugs (or most of them, I don't know) are fixed.

I just think that's too narrow-minded, and open to bias. After all, who in the whole world is likely to be the least critical about D? ;$

lol!
 
 We need the skeptics _in this group_ to be convinced before we've any 
 hope of convincing people from without. As such, I think Walter's the 
 absolute worst qualified to stipulate when D's ready to roll out. 
 (Sorry, mate!)
 
 That said, I don't think a sensible approach is to just randomly couch 
 opinion from loud and opinionated types (such as me). I think we need 
 something systematic (which I'm working on in a longer post I'm 
 preparing now.)
 
 
 

Ok, I see your point. Maybe using DStress instead, as others have suggested? _______________________ Carlos Santander Bernal
Mar 02 2005
prev sibling parent Glen Perkins <Glen_member pathlink.com> writes:
In article <d056ph$lnj$1 digitaldaemon.com>, Matthew says...
"Walter" <newshound digitalmars.com> wrote in message
 I've found myself wondering over the last few months what "1.0"
 actually is.
 Since D will undergo continuous improvement regardless, why don't we
 just
 drive a stake in the ground and call what we have "1.0"?

Is it a commercially viable language yet? IMO it is not. I think 1.0 should be whenever it is. The crux of that is how do we determine when it becomes so. Any ideas on criteria? Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?

For a 1.0 release I think correctness of the design (which to a significant extent can never be changed after "1.0") is more important than solidity of implementation (which can be continually improved forever). The point just before 1.0 is a magic moment where you know far more than you did when you first made your design decisions and yet you are still completely free to change anything. For this reason, I think that before 1.0 is declared, every effort should be made by Walter to gather feedback on his design decisions from as broad an audience as possible and to reconsider those decisions while there is still an opportunity to change. The points that cause the most controversy and criticism should be identified, the arguments for each alternative laid out, with no bias toward the existing design, and the pros and cons of each identified as clearly as possible. Then Walter should put his past decisions and arguments out of his mind and reconsider each of these controversial points de novo, asking himself what choices he would make if he were making them now for the first time, trying to avoid the urge to defend previous positions or protect existing code. (This is his last chance to make changes without legacy constraints, and I think he should exploit it fully.) Even done with a completely open mind, my guess is that only a very small number of issues would end up as serious candidates for change, but that a few sensible changes would significantly close the gap between D's existing design and perfection in the eyes of its future market.
Mar 03 2005
prev sibling next sibling parent reply Glen Perkins <Glen_member pathlink.com> writes:
In article <d04p7a$550$1 digitaldaemon.com>, Walter says...

I've found myself wondering over the last few months what "1.0" actually is.

Having formally participated in the design of Java and Flash ActionScript, I can say that the biggest non-commercial part of the definition of "what 1.0 actually is" was cutting off your ability to ever change your mind about some things. Freezing your mistakes. After 1.0, you are still able to add things, but you can't really remove anything, and the things you add have to be squeezed into the spaces not already occupied by something you can't remove. Having to squeeze new, better ideas into cracks between old, worse ideas makes a language into, well, C++ or Perl 5.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

Yes, many things will still be changeable, but many will not. The "stake in the ground" is a stake thru the heart of anybody who still fervently hopes to pursuade you to change certain things before it's too late. Even though it is true that D will undergo continuous improvement, you will never again be completely free to "do things right" after 1.0 ships. I don't think it's possible to avoid that outcome entirely (except by never shipping, which would be a tragedy), but I think there are ways to minimize it. When your first priority is to deliver revenue numbers to Wall St. this quarter, or crush Microsoft, or surprise your competitors by unveiling your stealth project, your options are limited. But if you have the luxury of making the best possible language design your first priority, do whatever you can to get the world to help before committing to 1.0. No matter how smart you are, the world collectively is smarter. It's also self-contradictory, overwhelming, and chaotic, so taking advantage of that extra smartness isn't trivial, but I think it's a tremendously valuable resource. You've already been engaging the world to some extent via this forum, but maybe one last push would be useful. Before making the 1.0 committment, you might consider getting some docs together that describe the *goals* for the language (what you're trying to optimize for), and why you believe the existing design decisions to be better than their major alternatives at meeting those goals. Just the process of writing such a thing, as a pursuasive document, not as a declaration of fact, might be useful to you. Then get the word out (Slashdot, etc.) that you'd like people to read these design arguments, think about them, try writing some code, and then respond with their highest priority requests for any changes. Then instead of defending your previous decisions, as is a natural temptation, and doing battle with the change suggestions, try to relax and see what emerges. Try to imagine that nothing had been decided (or implemented!) yet, that there was no existing design to defend, and you were free to let a design "emerge" naturally from the data. This emergence isn't a majority vote, just a sense of what the mass of users were thinking that you could adapt to without legacy constraints on your decision making. I think the existing design is so close to optimal for what you are optimizing for that the fundamental design of D will be overwhelmingly endorsed. Also, since the existing design would form the basis for discussion, what I think would emerge would simply be minor modifications. People's highest priority change requests would be in the details, I believe. I really think that if you could relax your commitment to the existing details and dispassionately observe what emerges and implement that, it would be better than what you have now, though I don't know how. (Sort of a stochastic optimization algorithm that isn't best for each individual but is best overall.) I also think it would be so close to what you have that the changes would be relatively minor, though if what emerged did imply a need for big changes, you'd want to know that before 1.0 since it would eventually become obvious later, and later might be too late.
Mar 02 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
This post shows a lot of good sense!  Very well put, Glen.  I beleive 
Walter does need to be much more receptive to outside opinion.

My only hesitation would be using slashdot as a resource.... ugh... 
That site is the last place I'd search for a sane evaluation of a 
language (Although, it is useful for getting general publicity).  I 
believe language reviewers have to be much more carefully chosen, or 
there will be chaos.  But such critical evaluation is necessary.

-JJR

Glen Perkins wrote:
 In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
 
 
I've found myself wondering over the last few months what "1.0" actually is.

Having formally participated in the design of Java and Flash ActionScript, I can say that the biggest non-commercial part of the definition of "what 1.0 actually is" was cutting off your ability to ever change your mind about some things. Freezing your mistakes. After 1.0, you are still able to add things, but you can't really remove anything, and the things you add have to be squeezed into the spaces not already occupied by something you can't remove. Having to squeeze new, better ideas into cracks between old, worse ideas makes a language into, well, C++ or Perl 5.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

Yes, many things will still be changeable, but many will not. The "stake in the ground" is a stake thru the heart of anybody who still fervently hopes to pursuade you to change certain things before it's too late. Even though it is true that D will undergo continuous improvement, you will never again be completely free to "do things right" after 1.0 ships. I don't think it's possible to avoid that outcome entirely (except by never shipping, which would be a tragedy), but I think there are ways to minimize it. When your first priority is to deliver revenue numbers to Wall St. this quarter, or crush Microsoft, or surprise your competitors by unveiling your stealth project, your options are limited. But if you have the luxury of making the best possible language design your first priority, do whatever you can to get the world to help before committing to 1.0. No matter how smart you are, the world collectively is smarter. It's also self-contradictory, overwhelming, and chaotic, so taking advantage of that extra smartness isn't trivial, but I think it's a tremendously valuable resource. You've already been engaging the world to some extent via this forum, but maybe one last push would be useful. Before making the 1.0 committment, you might consider getting some docs together that describe the *goals* for the language (what you're trying to optimize for), and why you believe the existing design decisions to be better than their major alternatives at meeting those goals. Just the process of writing such a thing, as a pursuasive document, not as a declaration of fact, might be useful to you. Then get the word out (Slashdot, etc.) that you'd like people to read these design arguments, think about them, try writing some code, and then respond with their highest priority requests for any changes. Then instead of defending your previous decisions, as is a natural temptation, and doing battle with the change suggestions, try to relax and see what emerges. Try to imagine that nothing had been decided (or implemented!) yet, that there was no existing design to defend, and you were free to let a design "emerge" naturally from the data. This emergence isn't a majority vote, just a sense of what the mass of users were thinking that you could adapt to without legacy constraints on your decision making. I think the existing design is so close to optimal for what you are optimizing for that the fundamental design of D will be overwhelmingly endorsed. Also, since the existing design would form the basis for discussion, what I think would emerge would simply be minor modifications. People's highest priority change requests would be in the details, I believe. I really think that if you could relax your commitment to the existing details and dispassionately observe what emerges and implement that, it would be better than what you have now, though I don't know how. (Sort of a stochastic optimization algorithm that isn't best for each individual but is best overall.) I also think it would be so close to what you have that the changes would be relatively minor, though if what emerged did imply a need for big changes, you'd want to know that before 1.0 since it would eventually become obvious later, and later might be too late.

Mar 02 2005
parent Glen Perkins <Glen_member pathlink.com> writes:
In article <d05uu7$1gfs$1 digitaldaemon.com>, John Reimer says...
This post shows a lot of good sense!  Very well put, Glen.  I beleive 
Walter does need to be much more receptive to outside opinion.

My only hesitation would be using slashdot as a resource.... ugh... 

That site is the last place I'd search for a sane evaluation of a 
language (Although, it is useful for getting general publicity).  I 
believe language reviewers have to be much more carefully chosen, or 
there will be chaos.  But such critical evaluation is necessary.

-JJR

Yeah, the first example that popped into my mind wasn't necessarily the best.... ;-) I would hope to have a wide range of experiences represented, though, because a popular language would eventually be USED in far more ways than initially imagined.
Glen Perkins wrote:
 In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
 
 
I've found myself wondering over the last few months what "1.0" actually is.

Having formally participated in the design of Java and Flash ActionScript, I can say that the biggest non-commercial part of the definition of "what 1.0 actually is" was cutting off your ability to ever change your mind about some things. Freezing your mistakes. After 1.0, you are still able to add things, but you can't really remove anything, and the things you add have to be squeezed into the spaces not already occupied by something you can't remove. Having to squeeze new, better ideas into cracks between old, worse ideas makes a language into, well, C++ or Perl 5.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

Yes, many things will still be changeable, but many will not. The "stake in the ground" is a stake thru the heart of anybody who still fervently hopes to pursuade you to change certain things before it's too late. Even though it is true that D will undergo continuous improvement, you will never again be completely free to "do things right" after 1.0 ships. I don't think it's possible to avoid that outcome entirely (except by never shipping, which would be a tragedy), but I think there are ways to minimize it. When your first priority is to deliver revenue numbers to Wall St. this quarter, or crush Microsoft, or surprise your competitors by unveiling your stealth project, your options are limited. But if you have the luxury of making the best possible language design your first priority, do whatever you can to get the world to help before committing to 1.0. No matter how smart you are, the world collectively is smarter. It's also self-contradictory, overwhelming, and chaotic, so taking advantage of that extra smartness isn't trivial, but I think it's a tremendously valuable resource. You've already been engaging the world to some extent via this forum, but maybe one last push would be useful. Before making the 1.0 committment, you might consider getting some docs together that describe the *goals* for the language (what you're trying to optimize for), and why you believe the existing design decisions to be better than their major alternatives at meeting those goals. Just the process of writing such a thing, as a pursuasive document, not as a declaration of fact, might be useful to you. Then get the word out (Slashdot, etc.) that you'd like people to read these design arguments, think about them, try writing some code, and then respond with their highest priority requests for any changes. Then instead of defending your previous decisions, as is a natural temptation, and doing battle with the change suggestions, try to relax and see what emerges. Try to imagine that nothing had been decided (or implemented!) yet, that there was no existing design to defend, and you were free to let a design "emerge" naturally from the data. This emergence isn't a majority vote, just a sense of what the mass of users were thinking that you could adapt to without legacy constraints on your decision making. I think the existing design is so close to optimal for what you are optimizing for that the fundamental design of D will be overwhelmingly endorsed. Also, since the existing design would form the basis for discussion, what I think would emerge would simply be minor modifications. People's highest priority change requests would be in the details, I believe. I really think that if you could relax your commitment to the existing details and dispassionately observe what emerges and implement that, it would be better than what you have now, though I don't know how. (Sort of a stochastic optimization algorithm that isn't best for each individual but is best overall.) I also think it would be so close to what you have that the changes would be relatively minor, though if what emerged did imply a need for big changes, you'd want to know that before 1.0 since it would eventually become obvious later, and later might be too late.


Mar 02 2005
prev sibling parent "Charlie Patterson" <charliep1 excite.com> writes:
"Glen Perkins" <Glen_member pathlink.com> wrote in message 
news:d05f1m$vrd$1 digitaldaemon.com...
 In article <d04p7a$550$1 digitaldaemon.com>, Walter says...

 Yes, many things will still be changeable, but many will not. The "stake 
 in the
 ground" is a stake thru the heart of anybody who still fervently hopes to
 pursuade you to change certain things before it's too late. Even though it 
 is
 true that D will undergo continuous improvement, you will never again be
 completely free to "do things right" after 1.0 ships.

I agree with the heartache of a 1.0 that can't be changed. But I'd like to make the point that D is a lot of best practices. Take the success of C, Eiffel, Java, C++ and throw out the weaknesses where possible. D doesn't have an all-new exception system or an all new X-oriented paradigm and way of thinking. Aspect-Oriented is too new to know what will come of it... and it's not in D. In other words, some of the exposing to the public has been done, and some of the critical thinking has been done... in the form of avoiding the obvious, well-vocalized mistakes of these other languages. Maybe another way to approach this is to add those things which the current community want and that the world-at-large has never complained about (array and struct init, or whatever). And *back out of* any features that are currently controvertial (unit testing powerful enough?) and unusual for the world. Stake that as 1.0. Then get more debate for 2.0 and the controversial features. I think there is plenty of fruit juicy goodness in the non-controversial features. (compiled, slices, etc.) to warrant a 1.0 and get some first-round libraries started. (Will the APIs be formal enough so that the underlying impl can be improved?)
Mar 04 2005
prev sibling next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
 I've found myself wondering over the
 last few months what "1.0" actually is.

Simple, and I'll be glad to help <g> 1. Examine my pet project 2. Identify what would be most useful to support it 3. "Make it so" 4. Call it version = 1.0 Take a couple of days off. 1'. Anticipate what would be most useful for my pet project in the future 2'. Call that ++version 3'. "Make it so." 4'. GoTo step 1' If you hold up your end of the above, I will commit to telling everyone I know about how wonderful 'D' is. Fair?
Mar 02 2005
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
I've found myself wondering over the last few months what "1.0" actually is.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

book is released...because the book may take longer to finish than this year (plus the book should be fully focused on the D v1.x release). Also I've been wondering how you've been doing on attacking the items placed in the MIID (Most Important List for D) thread, that you started (news:cht9gl$20m8$1 digitaldaemon.com) back in September of 2004? Plus I think that the DStress tests should be in the 90%+ passing range as a few others have voiced. But of course, if you want to place the stake in the ground now...why not make the next release as D v1.0 RC1! Afterall, it works well for Microsoft, and they're still able to remove / add things right up into the last minute...if need be before it becomes the next major release number. Just an idea. :) D's been pretty solid for the more avg things I've been writing, and the few times I had to fix something about 5 builds ago, it ended up that the compiler's error checking had improved, which it pointed out a few of my coding mistakes. Walter, many Kudos!! David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Mar 02 2005
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
I've found myself wondering over the last few months what "1.0" actually is.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

Are you speaking about the language or the compiler? I think we are ready for a "D language specification 1.0", while for the "Digital Mars D compiler 1.0" you still need some little work (you are close, though). The real point is: what is D? A language? A language + a reference compiler? Language + compiler + library? Either one is good, but if you want a commercially viable product, I think you should offer more. I'm still convinced that the big Java success was due to a standard library and a standard GUI. This was the boost that converted a little language to do web pages to one of the most used programming language in the world. While D is a very good language, we are no more in the 1980s, when C++ was born (and even that, I think OWL and MFC made most of its success). A language with a core library can be good only for some niche today, while to appeal the vast majority of developers (and especially managers) you should provide more. What? An IDE and a GUI. Do them yourself, let's do them all toghether, find a company that will do them, but do something. Ciao
Mar 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Roberto Mariottini wrote:

I've found myself wondering over the last few months what "1.0" actually is.
Since D will undergo continuous improvement regardless, why don't we just
drive a stake in the ground and call what we have "1.0"?

Are you speaking about the language or the compiler? I think we are ready for a "D language specification 1.0", while for the "Digital Mars D compiler 1.0" you still need some little work (you are close, though).

Excellent comment! If there was only DMD, I know I wouldn't have started with D. Luckily, David Friedman took the frontend and some other patches and turned into something really useful! (which is GDC if you missed it) http://home.earthlink.net/~dvdfrdmn/d/ I still think D specification needs more work before it can be "frozen"
 The real point is: what is D? A language? A language + a reference compiler?
 Language + compiler + library? Either one is good, but if you want a
 commercially viable product, I think you should offer more.

Java was the one pioneering mixing all terms together in a blender... And then Sun went on to rename their apps, hardware and their linux ? Fortunately, it's more sane here in the Digital Mars part of the woods: D is the language, DMD is a D compiler, Phobos is the D runtime library But a more clear separation of D, DMD and Phobos could be useful, as has been suggested before (and partly started upon by several)
 I'm still convinced that the big Java success was due to a standard library and
 a standard GUI. This was the boost that converted a little language to do web
 pages to one of the most used programming language in the world.

Java has changed both their standard library and standard GUI since... It started out with a small little language (that was Java 1.0) which changed greatly into the new language (Java 2). The GUI changed from the native AWT to the all-java Swing, more or less at the same time. The Collections API also replaced the first simple array/hash classes. (for some reason they still left all the old stuff in too, deprecated) So I'm not sure the Java of today is even the same as it was back then ? (especially not with "Java 2 version 5" and SWT being a AWT/Swing merge)
 What? An IDE and a GUI. Do them yourself, let's do them all toghether, find a
 company that will do them, but do something.

Many IDEs can be "persuaded" into supporting D, as well as C/C++/etc. And this with out redoing a full development environment from scratch? http://www.algonet.se/~afb/d/xcode/ As for GUIs, there are a few out there but they're all rather big to be shipping with the language or even runtime library. Maybe MinWin ? http://home.comcast.net/~benhinkle/minwin/ I'm not sure that D needs either of a IDE or GUI bundled with it, and for that matter it can sure use more than just one compiler... It now mostly seems to be about a) documentation b) co-operation ? (in order to use the existing IDEs and GUIs with any "D", that is) --anders
Mar 03 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
 Roberto Mariottini wrote:

 I'm still convinced that the big Java success was due to a standard 
 library and a standard GUI. This was the boost that converted a 
 little language to do web pages to one of the most used programming 
 language in the world.


How did Java "do web pages" before it had a "standard GUI"? Or are you talking about server-side Java (JSP, servlets and the like)? <snip>
 It started out with a small little language (that was Java 1.0) which 
 changed greatly into the new language (Java 2). The GUI changed from 
 the native AWT to the all-java Swing, more or less at the same time.

No it didn't. It added Swing as an alternative to plain AWT. Moreover, the Swing component classes are still derived from the root AWT classes.
 The Collections API also replaced the first simple array/hash 
 classes. (for some reason they still left all the old stuff in too, 
 deprecated)

Yes, this "some reason" is, generally speaking, the exact raison d'être of deprecation. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 03 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 It started out with a small little language (that was Java 1.0) which 
 changed greatly into the new language (Java 2). The GUI changed from 
 the native AWT to the all-java Swing, more or less at the same time.

No it didn't. It added Swing as an alternative to plain AWT. Moreover, the Swing component classes are still derived from the root AWT classes.

I took some "liberties" explaining, this being a D newsgroup (not Java) But most people seem to prefer Swing over the Awful Windowing Toolkit ?
 The Collections API also replaced the first simple array/hash classes. 
 (for some reason they still left all the old stuff in too, deprecated)

Yes, this "some reason" is, generally speaking, the exact raison d'être of deprecation.

Well, usually deprecating something means it will eventually go away ? In Java's case, it seems like Vector and Hashtable are here forever... Anyway, all of this is off-topic... :-) (and I'm not really a Java expert) I just meant that Java and Java 2 are really different beasts ? And some say that JDK 1.5 really forms a new "Java 3" language. --anders
Mar 03 2005
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d06qfa$2d78$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

I just meant that Java and Java 2 are really different beasts ?
And some say that JDK 1.5 really forms a new "Java 3" language.

This doesn't change anything. The success of Java is due to having a big (and bigger, and bigger) library and a working (and better, and better) GUI from the beginning. JBuilder, Visual Age, and other IDE did the rest. Theese three items made the big Java commercial success. Ciao
Mar 04 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Roberto Mariottini wrote:

I just meant that Java and Java 2 are really different beasts ?
And some say that JDK 1.5 really forms a new "Java 3" language.

This doesn't change anything. The success of Java is due to having a big (and bigger, and bigger) library and a working (and better, and better) GUI from the beginning. JBuilder, Visual Age, and other IDE did the rest. Theese three items made the big Java commercial success.

As long as it doesn't delay the release of D 1.0 (indefinitely ?), I don't have a problem with it having a kickass standard library :-) But if it does, I would rather have some simple stuff in D 1.0 and save the rest of it for D 2.0 instead ? It'll probably change, too. Even if this means that the Template Library and Widget Toolkit has to wait. There's still the C stdlib, and 3rd party libraries ? Just thought it better to finalize the D language specification and fix the compiler bugs, and worry about the libraries once that's done. --anders
Mar 04 2005
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d0967b$fo2$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

As long as it doesn't delay the release of D 1.0 (indefinitely ?),
I don't have a problem with it having a kickass standard library :-)

But if it does, I would rather have some simple stuff in D 1.0 and
save the rest of it for D 2.0 instead ? It'll probably change, too.

In my original post I was saying that the "D language specification 1.0" is nearly ready. And the "D 1.0 reference compiler" is close. And that when those are released, D is still not commercially viable.
Even if this means that the Template Library and Widget Toolkit
has to wait. There's still the C stdlib, and 3rd party libraries ?

All languages have 3rd party libraries, but successful ones (in the 2000s) have a big standard library. You can alwais add 3rd party libraries, if you want.
Just thought it better to finalize the D language specification and
fix the compiler bugs, and worry about the libraries once that's done.

That's good for me. It's only that I still can't use D at work. Ciao
Mar 04 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Roberto Mariottini wrote:

Just thought it better to finalize the D language specification and
fix the compiler bugs, and worry about the libraries once that's done.

That's good for me. It's only that I still can't use D at work.

Me neither. Then again, had I bothered about that I'd be coding Visual Basic by now. Or, more likely, doing something else... Fishing, perhaps ? :-)
 I could have been anything. I could have been a fisherman.
 Fishermen, they get up in the morning, they fish, they sell fish,
 they smell fish. Reminds me of a girl I used to go with, Yvonne.
 She smelled like fish.

Nah, D will do... I'm just using it to stay off the C++, anyway. Otherwise I'm using C or Java. But mostly Perl and sh, actually. --anders
Mar 04 2005
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d06p3m$2c55$1 digitaldaemon.com>, Stewart Gordon says...
Anders F Björklund wrote:
 Roberto Mariottini wrote:

 I'm still convinced that the big Java success was due to a standard 
 library and a standard GUI. This was the boost that converted a 
 little language to do web pages to one of the most used programming 
 language in the world.


How did Java "do web pages" before it had a "standard GUI"?

I was somewhat unclear, I mean that since it had a standard library and a standard GUI from the beginning, after having been used to do web pages (and showed to be useful) it has been used to do serious development. Ciao
Mar 04 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Roberto Mariottini wrote:
 In article <d06p3m$2c55$1 digitaldaemon.com>, Stewart Gordon says...

 How did Java "do web pages" before it had a "standard GUI"?

I was somewhat unclear, I mean that since it had a standard library and a standard GUI from the beginning, after having been used to do web pages (and showed to be useful) it has been used to do serious development.

Do you mean it enabled it to be taken up by purists who like to use only the 'standard' aspects of a language, and not depend on any third-party or proprietary libraries? There are other contributing factors, such as its being designed to write cross-platform apps (hence the importance of standard GUI features) and its being a relatively powerful and robust OO language. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 04 2005
prev sibling parent "Nick Sabalausky" <z a.a> writes:
 What? An IDE and a GUI. Do them yourself, let's do them all toghether, 
 find a
 company that will do them, but do something.

Many IDEs can be "persuaded" into supporting D, as well as C/C++/etc. And this with out redoing a full development environment from scratch? http://www.algonet.se/~afb/d/xcode/

could still use a little work, but looks promising: http://www.dsource.org/projects/dcoder/
Mar 03 2005
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Walter wrote:

 I've found myself wondering over the last few months what "1.0" actually is.
 Since D will undergo continuous improvement regardless, why don't we just
 drive a stake in the ground and call what we have "1.0"?
 

I think the most important component to woo C++/Java developers is Phobos. I have spoken with people who have shown an interest in D, but without a standard library that offers what they have come to take for granted most of them are hesitant to take the plunge. For the C++ types, I think an STL equivalent is the big thing. To this end, I really believe either DTL or MinTL needs to be integrated into core Phobos as part of a 1.0 release. This will make people in both camps happy (Java developers love their Collections). In addition, I think Phobos needs an examination to work out wrinkles (missing functionality, bugs) and provide a more consistent interface. A good example of this is the publicly exposed bool and boolean aliases - the former being a bit and the latter, declared in std.loader, being an int (I understand the bit vs. int issue, but Phobos needs consistency). Finally, any external dependencies Phobos brings in need to be handled transparently - such as the requirements for libdl on linux when using std.loader, or ws2_32.lib on Windows when using the socket modules. It seems like such a minor point, but that's exactly the sort of thing people nitpick about ("It's the friggin core library, why do I need to link in anything else to use it?"). Language features and syntax are quite persuasive, but for many Phobos is going to be the maker or breaker. It needs to be solid, bug free, consistent, and provide enough functionality that people will feel comfortable saying goodbye to the STL and the Java API. Relying on 3rd party libs to provide a large portion of that is not the way to go, IMO.
Mar 03 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Mike Parker wrote:

 I think the most important component to woo C++/Java developers is 
 Phobos. I have spoken with people who have shown an interest in D, but 
 without a standard library that offers what they have come to take for 
 granted most of them are hesitant to take the plunge.
 
 For the C++ types, I think an STL equivalent is the big thing. To this 
 end, I really believe either DTL or MinTL needs to be integrated into 
 core Phobos as part of a 1.0 release. This will make people in both 
 camps happy (Java developers love their Collections).

Forgive my ignorance, but wasn't both of STL and Collections added long after the initial releases of those two languages ? Phobos does need some work, though. And updated documentation. But waiting until it has a full TL (template library) and a full WT (Widget Toolkit), until D 1.0 can be released/frozen ? Just afraid it would delay D's release for another 5 years... --anders
Mar 03 2005
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <d07f6a$3pt$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Forgive my ignorance, but wasn't both of STL and Collections
added long after the initial releases of those two languages ?

It doesn't matter. What counts it's what D is up against now, not some years ago. Ant
Mar 03 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ant wrote:

Forgive my ignorance, but wasn't both of STL and Collections
added long after the initial releases of those two languages ?

It doesn't matter. What counts it's what D is up against now, not some years ago.

OK. I actually don't think MinTL and MinWin are all that bad, for inclusion into the standard library / download... ? http://home.comcast.net/~benhinkle/mintl/ http://home.comcast.net/~benhinkle/minwin/ Mango and DUI are both great add-on libraries, as well. (but a bit too big and "different" for Phobos, perhaps?) Too bad that none of them really works OK on Mac OS X, or I could probably be of more help with them... Although I pondered helping Ben with the Carbon version of MinWin, and in porting the Locks library to work better on BSD. --anders
Mar 03 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:
 Ant wrote:
 
 Forgive my ignorance, but wasn't both of STL and Collections
 added long after the initial releases of those two languages ?

It doesn't matter. What counts it's what D is up against now, not some years ago.

OK. I actually don't think MinTL and MinWin are all that bad, for inclusion into the standard library / download... ? http://home.comcast.net/~benhinkle/mintl/ http://home.comcast.net/~benhinkle/minwin/ Mango and DUI are both great add-on libraries, as well. (but a bit too big and "different" for Phobos, perhaps?) Too bad that none of them really works OK on Mac OS X, or I could probably be of more help with them... Although I pondered helping Ben with the Carbon version of MinWin, and in porting the Locks library to work better on BSD. --anders

Do you know what's preventing DUI from working on the mac at the moment? Is GTK supported on the mac, currently? -JJR
Mar 03 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 Do you know what's preventing DUI from working on the mac at the moment? 

There was some minor build issues, but now it's at "crash at startup" ? Unlike Mango, which is still stuck at "fails to compile" unfortunately.
 Is GTK supported on the mac, currently?

The new GTK+ 2.x Ant is using is only supported under X11, on Mac OS X. http://gtk-osx.sourceforge.net/ (supports GTK 1.x) --anders
Mar 03 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
[snip]
 I actually don't think MinTL and MinWin are all that bad,
 for inclusion into the standard library / download... ?

 http://home.comcast.net/~benhinkle/mintl/
 http://home.comcast.net/~benhinkle/minwin/

thanks! [snip]
 Too bad that none of them really works OK on Mac OS X,

I just need to get off my butt and work that out. I think you sent me some ideas on what I need to change to get it working on the mac. Just the other day I started compiling gdc on a mac at work but I haven't gotten to the point of trying out my stuff. Thanks for reminding me to get that done. Without reminders it's too easy to let it slide.
 or I could probably be of more help with them... Although
 I pondered helping Ben with the Carbon version of MinWin,
 and in porting the Locks library to work better on BSD.

Any help would be appreciated!
 --anders

Mar 03 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

Too bad that none of them really works OK on Mac OS X,

I just need to get off my butt and work that out. I think you sent me some ideas on what I need to change to get it working on the mac. Just the other day I started compiling gdc on a mac at work but I haven't gotten to the point of trying out my stuff. Thanks for reminding me to get that done. Without reminders it's too easy to let it slide.

Actually none of MinTL, MinWin, Mango nor DUI works right now. :-( But with more eyes looking at it, there's better chances of fixing it. And it does get a fair share of compiler segfaults and "thunk not defined" and other compiler errors, so there's probably a few bug reports on DMD waiting to be sent in too... I just updated the Mac GDC installer, so now it's a lot smaller than what it used to be and C and C++ are separate RPM packages. But I really don't have a good place to host it, at the moment ? (the packages are around 20 MB, and the source code around 20 MB)* Meta-package: http://www.algonet.se/~afb/d/gdc-installer.png --anders * Breakdown of binary package:
 2.9M    gdc-0.10-6.ppc.rpm
 4.5M    gdc-c-0.10-6.ppc.rpm
  12M    gdc-c++-0.10-6.ppc.rpm

* Breakdown of source code:
  20K    gdc-0.10-6.nosrc.rpm
 736K    gdc-0.10.tar.bz2
  12M    gcc-core-3.4.3.tar.bz2
 2.4M    gcc-g++-3.4.3.tar.bz2
 4.5M    gcc-java-3.4.3.tar.bz2

Source RPM: http://www.algonet.se/~afb/d/gdc-0.10-6.nosrc.rpm
Mar 03 2005
prev sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
Ant wrote:
 In article <d07f6a$3pt$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
 
 
Forgive my ignorance, but wasn't both of STL and Collections
added long after the initial releases of those two languages ?

It doesn't matter. What counts it's what D is up against now, not some years ago. Ant

I agree. _______________________ Carlos Santander Bernal
Mar 03 2005
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Anders F Björklund wrote:
 Mike Parker wrote:

 But waiting until it has a full TL (template library) and a
 full WT (Widget Toolkit), until D 1.0 can be released/frozen ?
 
 Just afraid it would delay D's release for another 5 years...

While a widget/GUI toolkit would be a nice addition to Phobos, I agree that it isn't feasible for a 1.0 release. And really, that's the sort of thing that can likely work well as a 3rd party lib. Collections, be they templatized like DTL or not, are a *must* for Phobos, IMO.
Mar 03 2005
prev sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d07f6a$3pt$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Mike Parker wrote:

 I think the most important component to woo C++/Java developers is 
 Phobos. I have spoken with people who have shown an interest in D, but 
 without a standard library that offers what they have come to take for 
 granted most of them are hesitant to take the plunge.
 
 For the C++ types, I think an STL equivalent is the big thing. To this 
 end, I really believe either DTL or MinTL needs to be integrated into 
 core Phobos as part of a 1.0 release. This will make people in both 
 camps happy (Java developers love their Collections).

Forgive my ignorance, but wasn't both of STL and Collections added long after the initial releases of those two languages ?

True, but the fact is that it was 10 years ago. Ciao
Mar 04 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message
news:d07dbj$24e$1 digitaldaemon.com...
 For the C++ types, I think an STL equivalent is the big thing. To this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.
Mar 03 2005
next sibling parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Walter wrote:
 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...
 
For the C++ types, I think an STL equivalent is the big thing. To this
end, I really believe either DTL or MinTL needs to be integrated into
core Phobos as part of a 1.0 release. This will make people in both
camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on. 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions. 3. It provides a consistent way to access functions that work on strings. There are probably more things that a string class could provide. Some of the functions can be just global functions, but I think a lot of people are used access them as methods. Here an example: D right now: char[] s; s.length <- property toUTF32(s) <- global function D with a standardized string class string s; s.length() <- method s.toUTF32() <- method This is much more consistent. Since strings are so fundamental, there should be a single standardized string interface. It needs to be powerful enough so that there is no reason for anyone to develop a second string class for purpose x. Jan-Eric
Mar 03 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden <jeduden whisset.com>  
wrote:
 Walter wrote:
 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...

 For the C++ types, I think an STL equivalent is the big thing. To this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on. 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions. 3. It provides a consistent way to access functions that work on strings. There are probably more things that a string class could provide. Some of the functions can be just global functions, but I think a lot of people are used access them as methods. Here an example: D right now: char[] s; s.length <- property toUTF32(s) <- global function D with a standardized string class string s; s.length() <- method s.toUTF32() <- method This is much more consistent.

You can already use the syntax above. D allows you to call a function which takes an array as it's first parameter as if it was a method/property of the array. eg. char[] s,p; p = s.toTUF32();
 Since strings are so fundamental, there should be a single standardized
 string interface. It needs to be powerful enough so that there is no  
 reason for anyone to develop a second string class for purpose x.

I reckon what we have in D is better than a class, it's extensible, you can pretty much write your own 'methods' for the char[] type. Regan
Mar 03 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Regan Heath wrote:
 On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden 
 <jeduden whisset.com>  wrote:
 
 Walter wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...

 For the C++ types, I think an STL equivalent is the big thing. To this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on. 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions. 3. It provides a consistent way to access functions that work on strings. There are probably more things that a string class could provide. Some of the functions can be just global functions, but I think a lot of people are used access them as methods. Here an example: D right now: char[] s; s.length <- property toUTF32(s) <- global function D with a standardized string class string s; s.length() <- method s.toUTF32() <- method This is much more consistent.

You can already use the syntax above. D allows you to call a function which takes an array as it's first parameter as if it was a method/property of the array. eg. char[] s,p; p = s.toTUF32();
 Since strings are so fundamental, there should be a single standardized
 string interface. It needs to be powerful enough so that there is no  
 reason for anyone to develop a second string class for purpose x.

I reckon what we have in D is better than a class, it's extensible, you can pretty much write your own 'methods' for the char[] type. Regan

But if you want to abstact from the encoding you need a class, or there is another D feature, that helps with that? :>
Mar 04 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 04 Mar 2005 09:26:29 +0100, Jan-Eric Duden <jeduden whisset.com>  
wrote:
 Regan Heath wrote:
 On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden  
 <jeduden whisset.com>  wrote:

 Walter wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...

 For the C++ types, I think an STL equivalent is the big thing. To  
 this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on. 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions. 3. It provides a consistent way to access functions that work on strings. There are probably more things that a string class could provide. Some of the functions can be just global functions, but I think a lot of people are used access them as methods. Here an example: D right now: char[] s; s.length <- property toUTF32(s) <- global function D with a standardized string class string s; s.length() <- method s.toUTF32() <- method This is much more consistent.

function which takes an array as it's first parameter as if it was a method/property of the array. eg. char[] s,p; p = s.toTUF32();
 Since strings are so fundamental, there should be a single standardized
 string interface. It needs to be powerful enough so that there is no   
 reason for anyone to develop a second string class for purpose x.

you can pretty much write your own 'methods' for the char[] type. Regan

But if you want to abstact from the encoding you need a class, or there is another D feature, that helps with that? :>

Why do you want to abstract the encoding? Can you give me an example where it's useful? Regan
Mar 04 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Regan Heath wrote:
 On Fri, 04 Mar 2005 09:26:29 +0100, Jan-Eric Duden 
 <jeduden whisset.com>  wrote:
 
 Regan Heath wrote:

 On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden  
 <jeduden whisset.com>  wrote:

 Walter wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...

 For the C++ types, I think an STL equivalent is the big thing. To  
 this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on. 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions. 3. It provides a consistent way to access functions that work on strings. There are probably more things that a string class could provide. Some of the functions can be just global functions, but I think a lot of people are used access them as methods. Here an example: D right now: char[] s; s.length <- property toUTF32(s) <- global function D with a standardized string class string s; s.length() <- method s.toUTF32() <- method This is much more consistent.

You can already use the syntax above. D allows you to call a function which takes an array as it's first parameter as if it was a method/property of the array. eg. char[] s,p; p = s.toTUF32();
 Since strings are so fundamental, there should be a single standardized
 string interface. It needs to be powerful enough so that there is 
 no   reason for anyone to develop a second string class for purpose x.

I reckon what we have in D is better than a class, it's extensible, you can pretty much write your own 'methods' for the char[] type. Regan

But if you want to abstact from the encoding you need a class, or there is another D feature, that helps with that? :>

Why do you want to abstract the encoding? Can you give me an example where it's useful? Regan

You have a library A that works utf8 characters and you have a library B that works utf16 characters. And you are writing a program using A and B, then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries. A string class can help here. Furthermore a string class can help implementing the concept "copy only if changes are made". This is pretty important since D doesn't support the keyword const. Otherwise every single class that wants to store a string needs to copy the string!
Mar 04 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden <jeduden whisset.com>  
wrote:
 But if you want to abstact from the encoding you need a class,
 or there is another D feature, that helps with that? :>

where it's useful? Regan

You have a library A that works utf8 characters and you have a library B that works utf16 characters. And you are writing a program using A and B, then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries.

Correct. But, all you'd be achieving is shorter code which hides the fact that it's converting strings all the time. Ideally we should only convert on input and output. Ideally we use the most efficient format (depends on our task) internally. Of course things seldom happen that way and I guess if efficiency isn't that important then a string class might be nice, but it's not essential. Question, I believe opCast can only be overloaded for one type, so, how you return char[], wchar[] and dchar[] without using method calls?
 Furthermore a string class can help implementing the concept "copy only  
 if changes are made".

"Copy On Write"
 This is pretty important since D doesn't support the keyword const.

I think the need for const is obviated somewhat by in, out and inout. It would be obviated further if constness was enforced when 'in' was used. eg. If you see: void foo(inout char[] a), you know foo will/might modify 'a' If you see: void foo(char[] a), you know foo won't modify 'a' (not actually true*) *foo can modify the data but not the reference, eg. void foo(char[] a) { a[0] = '1'; } will modify the first char of a. I think the constness of 'in' idea is very important, it gives us some assurances and allows us to implement "Copy On Write" more confidently.
 Otherwise every single class that wants to store a string needs to copy  
 the string!

Correction, every single class that wants "to modify" a string *it has stored* needs to copy the string. In other words "Copy On Write". Regan
Mar 04 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Regan Heath wrote:
 On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden 
 <jeduden whisset.com>  wrote:
 
 But if you want to abstact from the encoding you need a class,
 or there is another D feature, that helps with that? :>

Why do you want to abstract the encoding? Can you give me an example where it's useful? Regan

For example: You have a library A that works utf8 characters and you have a library B that works utf16 characters. And you are writing a program using A and B, then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries.

Correct. But, all you'd be achieving is shorter code which hides the fact that it's converting strings all the time. Ideally we should only convert on input and output. Ideally we use the most efficient format (depends on our task) internally. Of course things seldom happen that way and I guess if efficiency isn't that important then a string class might be nice, but it's not essential. Question, I believe opCast can only be overloaded for one type, so, how you return char[], wchar[] and dchar[] without using method calls?
 Furthermore a string class can help implementing the concept "copy 
 only  if changes are made".

"Copy On Write"
 This is pretty important since D doesn't support the keyword const.

I think the need for const is obviated somewhat by in, out and inout. It would be obviated further if constness was enforced when 'in' was used. eg. If you see: void foo(inout char[] a), you know foo will/might modify 'a' If you see: void foo(char[] a), you know foo won't modify 'a' (not actually true*) *foo can modify the data but not the reference, eg. void foo(char[] a) { a[0] = '1'; } will modify the first char of a.

If you pass a string you don't want anyone to change the contents of the string.
 
 I think the constness of 'in' idea is very important, it gives us some  
 assurances and allows us to implement "Copy On Write" more confidently.
 
 Otherwise every single class that wants to store a string needs to 
 copy  the string!

Correction, every single class that wants "to modify" a string *it has stored* needs to copy the string. In other words "Copy On Write". Regan

But this is cannot be enforced by the char array.
Mar 04 2005
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 04 Mar 2005 11:44:36 +0100, Jan-Eric Duden <jeduden whisset.com> 
wrote:
 Regan Heath wrote:
 On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden 
 <jeduden whisset.com>  wrote:

 But if you want to abstact from the encoding you need a class,
 or there is another D feature, that helps with that? :>

Why do you want to abstract the encoding? Can you give me an example where it's useful? Regan

For example: You have a library A that works utf8 characters and you have a library B that works utf16 characters. And you are writing a program using A and B, then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries.

Correct. But, all you'd be achieving is shorter code which hides the fact that it's converting strings all the time. Ideally we should only convert on input and output. Ideally we use the most efficient format (depends on our task) internally. Of course things seldom happen that way and I guess if efficiency isn't that important then a string class might be nice, but it's not essential. Question, I believe opCast can only be overloaded for one type, so, how you return char[], wchar[] and dchar[] without using method calls?
 Furthermore a string class can help implementing the concept "copy 
 only  if changes are made".

"Copy On Write"
 This is pretty important since D doesn't support the keyword const.

I think the need for const is obviated somewhat by in, out and inout. It would be obviated further if constness was enforced when 'in' was used. eg. If you see: void foo(inout char[] a), you know foo will/might modify 'a' If you see: void foo(char[] a), you know foo won't modify 'a' (not actually true*) *foo can modify the data but not the reference, eg. void foo(char[] a) { a[0] = '1'; } will modify the first char of a.


Not in this case.
 If you pass a string you don't want anyone to change the contents of the 
 string.

Unless that's the point of the function.
 I think the constness of 'in' idea is very important, it gives us some  
 assurances and allows us to implement "Copy On Write" more confidently.

 Otherwise every single class that wants to store a string needs to 
 copy  the string!

Correction, every single class that wants "to modify" a string *it has stored* needs to copy the string. In other words "Copy On Write". Regan

But this is cannot be enforced by the char array.

True, but it's not intended to. Regan
Mar 04 2005
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Jan-Eric Duden wrote:

 "Copy On Write"
 void foo(char[] a) {
   a[0] = '1';
 }

 will modify the first char of a.

And that what you don't want. If you pass a string you don't want anyone to change the contents of the string.

Strings in D are protected from overwriting by the Honor Systemâ„¢... If you touch someone elses strings, you get to stand in the corner. :-) Or in case of string literals, you just might trigger a segfault. (depending on whether or not string literals are stored read-only) Enforcing Copy-on-Write, is a D issue that is remaining to be solved. (it needs to be able to separate between read-only and read-write ?) Hopefully it can be done without a 'String' class (like in Java), and without the 'const' type modifier (like in C/C++). Or done at all... Meanwhile, we all need to be nice little children and CoW as told ? (note that being an equally bad boy in C is only a cast away, too) Maybe Walter has an ace up the sleeve? (I'm thinking "in" vs. "out" ?) Solving this one, and the "out variadic" problem, would be very nice! --anders
Mar 04 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Anders F Björklund wrote:
 Jan-Eric Duden wrote:
 
 "Copy On Write"
 void foo(char[] a) {
   a[0] = '1';
 }

 will modify the first char of a.

And that what you don't want. If you pass a string you don't want anyone to change the contents of the string.

Strings in D are protected from overwriting by the Honor Systemâ„¢... If you touch someone elses strings, you get to stand in the corner. :-) Or in case of string literals, you just might trigger a segfault. (depending on whether or not string literals are stored read-only)

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge. D has everything it needs to make strings fast and safe- why does Walter not want a standardized string interface? Is it that difficult to understand that either const or a string class is needed to support secure programming?
Mar 04 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor Systemâ„¢...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

Copy-on-Write and immutable strings have a great advantage over deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.
Mar 04 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Anders F Björklund wrote:
 Jan-Eric Duden wrote:
 
 Strings in D are protected from overwriting by the Honor Systemâ„¢...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

Copy-on-Write and immutable strings have a great advantage over deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

I wonder how this can be implemented without one of these concepts?
Mar 04 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com>  
wrote:
 Anders F Björklund wrote:
 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor Systemâ„¢...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced. Regan
Mar 04 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsm4wt1uo23k2f5 ally...
 On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com> 
 wrote:
 Anders F Björklund wrote:
 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor SystemT...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced. Regan

Changing the semantics of "in" to also apply to references would be a huge change and it would go against the default semantics of C. A (slightly) more practical proposal is to have parameters explicitly declared as "in" be read-only but even then it would be a big change and we'd have to think about how the read-only-ness would be represented in the type and passed along to other variables. Basically I think the only real way to add this to D if it ever gets added is to have another type attribute like C/C++'s const. Note that there really isn't anything special about strings, too. Any type with reference semantics is at the mercy of the functions it gets passed to. Class objects, arrays in general, etc. They all rely on implicit contracts that the functions do what they say they do.
Mar 04 2005
parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 4 Mar 2005 17:48:45 -0500, Ben Hinkle <bhinkle mathworks.com> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsm4wt1uo23k2f5 ally...
 On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com>
 wrote:
 Anders F Björklund wrote:
 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor SystemT...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

happy.:) I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced. Regan

Changing the semantics of "in" to also apply to references would be a huge change and it would go against the default semantics of C.

True.
 A (slightly) more
 practical proposal is to have parameters explicitly declared as "in" be
 read-only but even then it would be a big change and we'd have to think
 about how the read-only-ness would be represented in the type and passed
 along to other variables.

I dislike this. I think by default variables should be 'read-only' or 'const', the programmer should have to specifically denote the ones they want to modify (using out, inout), not the other way around.
 Basically I think the only real way to add this to D if it ever gets 
 added is to have another type attribute like C/C++'s
 const.

 Note that there really isn't anything special about strings, too. Any 
 type with reference semantics is at the mercy of the functions it gets 
 passed to.

Exactly. The concept/contract I want is "I am only going to read from this variable", and I want it enforced. Using the reference to write to the data it refers to is a write operation, and should be denied.
 Class objects, arrays in general, etc. They all rely on implicit 
 contracts that the functions do what they say they do.

If the contract was enforced, then you could be more sure/safe using "Copy On Write". Regan
Mar 04 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 On Fri, 4 Mar 2005 17:48:45 -0500, Ben Hinkle <bhinkle mathworks.com> 
 wrote:
 
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsm4wt1uo23k2f5 ally...

 On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com>
 wrote:

 Anders F Björklund wrote:

 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor SystemT...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

Copy-on-Write and immutable strings have a great advantage over deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

If i can get immutable string without a class and const, I'd be happy.:) I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced. Regan

Changing the semantics of "in" to also apply to references would be a huge change and it would go against the default semantics of C.

True.
 A (slightly) more
 practical proposal is to have parameters explicitly declared as "in" be
 read-only but even then it would be a big change and we'd have to think
 about how the read-only-ness would be represented in the type and passed
 along to other variables.

I dislike this. I think by default variables should be 'read-only' or 'const', the programmer should have to specifically denote the ones they want to modify (using out, inout), not the other way around.
 Basically I think the only real way to add this to D if it ever gets 
 added is to have another type attribute like C/C++'s
 const.

 Note that there really isn't anything special about strings, too. Any 
 type with reference semantics is at the mercy of the functions it gets 
 passed to.

Exactly. The concept/contract I want is "I am only going to read from this variable", and I want it enforced. Using the reference to write to the data it refers to is a write operation, and should be denied.
 Class objects, arrays in general, etc. They all rely on implicit 
 contracts that the functions do what they say they do.

If the contract was enforced, then you could be more sure/safe using "Copy On Write".

I've always felt this is an, at best, diffuse subject. I'd like to clarify (at least for myself :-) ) what we are discussing. I see so many different ways to look at it. - COW may either be - enforced totally by the compiler/language - either totally (definitely not D here) - enforce, but with back doors ("if you really want") - make it easy to do and support it - just give opportunities and some help - or - not stand in the way if someone tries to follow it - not give a damn, let programmer do the cows by himself - make it hard (by implicit cow somewhere and not when you expect) What is the consensus (or is there) on where we - are now - would like to be? On another plane, who's responsible for cow? Should it be entirely the programmer or entirely the compiler/language? Where do we want to be, or should want to be, on this scale? Part of my problem lies with not having done so much Java &co that I'd have become immersed or dependent on this. When I programmed in Pascal, it was your call all the way. Or, rather, one never thought about it. Why make things grander and more compicated. (I've got automatic indoor temperature in my car. It meticulously measures temperature here and there, and tries to reach some level it believes I want. Well, my wants depend on so many things, like what I'm wearing, whether I walked quickly to the car, whatever. My old car only had three knobs: where, fan speed, and heat. They reacted instantly, and I knew what to turn and when, without thinking.) Pascal had in, inout, and out parameters. Could it be that this is the level that gives the optimum between coding speed, reliability, practicality -- vs -- complicity of compiler as well as usage, or conceptual intractability. Or at least an increased need to resort to documentation?
Mar 07 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
(removed .dtl group from this reply.. why are we posting to both groups??)

On Mon, 07 Mar 2005 14:03:21 +0200, Georg Wrede <georg.wrede nospam.org>  
wrote:
 I've always felt this is an, at best, diffuse subject. I'd like to  
 clarify (at least for myself :-)  ) what we are discussing. I see so  
 many different ways to look at it.

 - COW may either be
    - enforced totally by the compiler/language
      - either totally (definitely not D here)
      - enforce, but with back doors ("if you really want")
    - make it easy to do and support it
    - just give opportunities and some help
 - or
    - not stand in the way if someone tries to follow it
    - not give a damn, let programmer do the cows by himself
    - make it hard (by implicit cow somewhere and not when you expect)

 What is the consensus (or is there)

I doubt it :)
 on where we
    - are now

"not stand in the way if someone tries to follow it"
    - would like to be?

"make it easy to do and support it"
 On another plane, who's responsible for cow? Should it be entirely the  
 programmer or entirely the compiler/language?

Neither.
 Where do we want to be, or should want to be, on this scale?

I think the programmer is responsible for it, they choose where/when to use it, and where/when not to use it. At the same time the language should not make it difficult to use, it should attempt to prevent 'bad code' from breaking COW.
 Part of my problem lies with not having done so much Java &co that I'd  
 have become immersed or dependent on this. When I programmed in Pascal,  
 it was your call all the way. Or, rather, one never thought about it.  
 Why make things grander and more compicated.

 (I've got automatic indoor temperature in my car. It meticulously  
 measures temperature here and there, and tries to reach some level it  
 believes I want. Well, my wants depend on so many things, like what I'm  
 wearing, whether I walked quickly to the car, whatever. My old car only  
 had three knobs: where, fan speed, and heat. They reacted instantly, and  
 I knew what to turn and when, without thinking.)

 Pascal had in, inout, and out parameters. Could it be that this is the  
 level that gives the optimum between coding speed, reliability,  
 practicality -- vs -- complicity of compiler as well as usage, or  
 conceptual intractability. Or at least an increased need to resort to  
 documentation?

How did pascal implement in, inout and out? Did it enforce read-only on 'in'? or.. Regan
Mar 07 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 05 Mar 2005 11:31:03 +1300, Regan Heath wrote:

 On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com>  
 wrote:
 Anders F Björklund wrote:
 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor Systemâ„¢...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced.

It is enforced - 'a' itself is not modified. However, whatever 'a' refers to may be modified. import std.stdio; void foo(char[] a, inout char[] b) { a = "abc"; b = "def"; } void main() { char[] X = "123"; char[] Y = "456"; writefln("before X=%s, Y=%s", X, Y); foo(X, Y); writefln(" after X=%s, Y=%s", X, Y); } So what we need to be able to express, is a way to tell the compiler that the data referred to is not to be modified, and not just the referrer. -- Derek Parnell Melbourne, Australia 5/03/2005 10:09:41 AM
Mar 04 2005
parent Regan Heath <regan netwin.co.nz> writes:
On Sat, 5 Mar 2005 10:14:52 +1100, Derek Parnell <derek psych.ward> wrote:
 On Sat, 05 Mar 2005 11:31:03 +1300, Regan Heath wrote:

 On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden whisset.com>
 wrote:
 Anders F Björklund wrote:
 Jan-Eric Duden wrote:

 Strings in D are protected from overwriting by the Honor Systemâ„¢...

How can a D coder know if it is safe to store just the reference or if he needs to make a copy. Right now, to be on the safe side - he actually needs to make a copy. Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

deep copying and mutable strings, both when it comes to performance and when it comes to thread-safety (avoiding locks is also performance) Along with slices and garbage collection, it gives D great speed... What is needed is a method in the language to make sure that this is enforced, when passing arrays to other modules and functions ? Without it, as you say, strings *could* be modified by the method. But I'm still hoping that it can be done without const / class... --anders PS. See also the "immutable strings" thread, and others like it.

happy.:) I wonder how this can be implemented without one of these concepts?

I think the first step is enforcing 'constness' on 'in' parameters. That will basically say, for this function: void foo(char[] a, inout char[] b); a will not be modified, b might be modified. It's a contract. It needs to be enforced.

It is enforced - 'a' itself is not modified.

No, 'technically' it's not enforced. If it were enforced the compiler would give an error when you modifed the 'reference' itself (not shown in my example), it doesn't. It only _seems_ to enforce it because it makes a copy of the reference for the function call. Is the fact that it makes a copy specified or simply what happens in this compiler?
 However, whatever 'a' refers
 to may be modified.

True. There is a distinction.
 import std.stdio;
 void foo(char[] a, inout char[] b) { a = "abc"; b = "def"; }
 void main()
 {
   char[] X = "123";
   char[] Y = "456";
   writefln("before X=%s, Y=%s", X, Y);
   foo(X, Y);
   writefln(" after X=%s, Y=%s", X, Y);
 }

 So what we need to be able to express, is a way to tell the compiler that
 the data referred to is not to be modified, and not just the referrer.

Sure, but, the concept I'm really after is simply "I am _only_ going to read from this variable", for that to be true/expressed the only operation permissable on the variable would be a read operation, not a write operation. If this concpet can be realised then "Copy On Write" can be done much more surely/safely. Regan
Mar 04 2005
prev sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jan-Eric Duden wrote:

 I reckon what we have in D is better than a class, it's extensible, 
 you  can pretty much write your own 'methods' for the char[] type.

But if you want to abstact from the encoding you need a class, or there is another D feature, that helps with that? :>

D isn't all that keen on "abstraction", from what I've seen. It prefers the boolean variables implemented as integers and the strings as dynamic arrays of unicode code units... Otherwise some critical performance issue might be hidden from the programmer, such as choosing the correct one of the various available: bool/wbool/dbool and str/wstr/dstr (bit/byte/int and char[]/wchar[]/dchar[] without aliases) Perhaps you were thinking of a coffee-flavored language ? :-P --anders
Mar 04 2005
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Anders F Björklund wrote:
 Jan-Eric Duden wrote:
 
 I reckon what we have in D is better than a class, it's extensible, 
 you  can pretty much write your own 'methods' for the char[] type.

But if you want to abstact from the encoding you need a class, or there is another D feature, that helps with that? :>

D isn't all that keen on "abstraction", from what I've seen. It prefers the boolean variables implemented as integers and the strings as dynamic arrays of unicode code units... Otherwise some critical performance issue might be hidden from the programmer, such as choosing the correct one of the various available: bool/wbool/dbool and str/wstr/dstr (bit/byte/int and char[]/wchar[]/dchar[] without aliases) Perhaps you were thinking of a coffee-flavored language ? :-P --anders

Eventhough java is not the slowest language ever anymore, it still has a lot of drawbacks. Who wants to ship the whole JRE to their customers? That only works well in controlled environments. MS makes the same mistake with their .NET framework binaries... That's why I like D.
Mar 04 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jan-Eric Duden wrote:

 Who wants to ship the whole JRE to their customers?
 That only works well in controlled environments.

Actually, I only ship the .jar file these days. Most people know where to get the Java runtime, if they all haven't got it installed already ? And those .jar's are actually really small:
  12K    hello_c
 Hello, World!
         0.04 real         0.00 user         0.01 sys
 
 368K    hello_cpp
 Hello, World!
         0.06 real         0.00 user         0.03 sys
 
 104K    hello_d
 Hello, World!
         0.05 real         0.00 user         0.01 sys
 
 4.0K    hello.jar
 Hello, World!
         0.67 real         0.31 user         0.16 sys

Especially with the built-in compression. The JVM startup is not that fun, though. (as can be seen from the runtimes above)
 That's why I like D.

Me too. :-) We've started a page to help going from Java to D: http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD If you can help with filling it out, it'd be great. There's also the "Molt" project on Dsource: http://www.dsource.org/projects/molt/ (although I can't get the XSLT working here) --anders
Mar 04 2005
parent Mike Parker <aldacron71 yahoo.com> writes:
Anders F Björklund wrote:
 Jan-Eric Duden wrote:
 

 Actually, I only ship the .jar file these days.
 Most people know where to get the Java runtime,
 if they all haven't got it installed already ?

That wholly depends on your user base. The reason I am so hung up on D right now is precisely because of the difficulties of distributing Java games to the general public online. PuppyGames (http://www.puppygames.com/) is a pioneer in this area, and has seen dismal failures when distributing both via WebStart and without on Windows and Linux (the Mac market has proven to be the perfect environment for Java applications - Java support is integrated with the OS these days). I can point you to a thread where other independent game developers, people you who are quite tech-savy (but otherwise non-Java users), had quite some difficulty testing PuppyGames' most recent release - until they opted to ship the game with a stripped down VM (which violates the Sun license agreement big time) in order to avoid shipping the whole JRE. Now it works right out of the box. In this respect, D is as close to a Holy Grail as you can get. It's the perfect answer for any Java developer who has faced support issues related to JRE penetration in the Windows world (which Sun has been overly optimistic about, apparently). That's why I think Phobos is so important to bring these people in - without a solid library akin to the one they have become accustomed to, many will be reluctant to make the switch in spite of the easier distribution.
Mar 04 2005
prev sibling next sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
I very much dislike choice of having JAVA-like functionNames... That might
even come to turning back to D. :( I thought pretty much about resons
behind using that naming convention and there was none good reason i could
come to. Seriously.
Someone pointed out that people use it to distinct from class-names. Well,
if i have dot (".") before it, it cannot be the class! :)
Anyway it's up to D developers and they made their decision - this is just a
personal note.
I prefer MethodNames() or method_names() . methodNames() are unacceptable
for my projects. :)
IMHO it would be good if D doesn't make difference between those somehow. :)

Kind regards

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Mar 03 2005
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I agree, but it's a standard, and it's better to have a standard than 
not.

There are some aspects of the current naming scheme that works nicely 
with properties. But then properties have problems all their own at the 
moment ...

"Dejan Lekic" <leka entropy.tmok.com> wrote in message 
news:d086f9$2kbb$1 digitaldaemon.com...
 I very much dislike choice of having JAVA-like functionNames... That 
 might
 even come to turning back to D. :( I thought pretty much about resons
 behind using that naming convention and there was none good reason i 
 could
 come to. Seriously.
 Someone pointed out that people use it to distinct from class-names. 
 Well,
 if i have dot (".") before it, it cannot be the class! :)
 Anyway it's up to D developers and they made their decision - this is 
 just a
 personal note.
 I prefer MethodNames() or method_names() . methodNames() are 
 unacceptable
 for my projects. :)
 IMHO it would be good if D doesn't make difference between those 
 somehow. :)

 Kind regards

 -- 
 ...........
 Dejan Lekic
  http://dejan.lekic.org
 

Mar 03 2005
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:d086f9$2kbb$1 digitaldaemon.com...
 I very much dislike choice of having JAVA-like functionNames... That might
 even come to turning back to D. :( I thought pretty much about resons
 behind using that naming convention and there was none good reason i could
 come to. Seriously.
 Someone pointed out that people use it to distinct from class-names. Well,
 if i have dot (".") before it, it cannot be the class! :)
 Anyway it's up to D developers and they made their decision - this is just

 personal note.
 I prefer MethodNames() or method_names() . methodNames() are unacceptable
 for my projects. :)
 IMHO it would be good if D doesn't make difference between those somehow.

D, the language, does not prescribe naming conventions. Feel free to use whatever makes sense for your project. For purely stylistic reasons, however, it's a good idea for the standard library for D to follow some sort of convention. One convention is as good as another, it's consistency that matters. For better or worse, the current Phobos convention is what it is, there's too much water under that bridge.
Mar 03 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d086f9$2kbb$1 digitaldaemon.com>, Dejan Lekic says...
I very much dislike choice of having JAVA-like functionNames... That might
even come to turning back to D. :( I thought pretty much about resons
behind using that naming convention and there was none good reason i could
come to. Seriously.
Someone pointed out that people use it to distinct from class-names. Well,
if i have dot (".") before it, it cannot be the class! :)

Many believe that it's important to distinguish type names from other symbols, and it's been shown that doing so increases readability. I don't think it matters what the convention is so long as it's consistent. Personally, I'm in the lowercase/underscore camp for C++ development (as it's the convention marginally established by the C/C++ standard libraries) but when in D... Sean
Mar 04 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"I very much dislike choice of having JAVA-like functionNames"

I am with you, Dejan :)

But notation style is always a subject of holy wars.
Language itself should be agnostic to that matter and this is it.

<lyrics>
Anyone is free to write by right hand or by left hand.
In the Middle East they use even "wrong direction" and nobody
complain about that (except of designers of HTML
engines of course :)
</lyrics>

Andrew Fedoniouk.
http://terrainformatica.com




"Dejan Lekic" <leka entropy.tmok.com> wrote in message 
news:d086f9$2kbb$1 digitaldaemon.com...
 I very much dislike choice of having JAVA-like functionNames... That might
 even come to turning back to D. :( I thought pretty much about resons
 behind using that naming convention and there was none good reason i could
 come to. Seriously.
 Someone pointed out that people use it to distinct from class-names. Well,
 if i have dot (".") before it, it cannot be the class! :)
 Anyway it's up to D developers and they made their decision - this is just 
 a
 personal note.
 I prefer MethodNames() or method_names() . methodNames() are unacceptable
 for my projects. :)
 IMHO it would be good if D doesn't make difference between those somehow. 
 :)

 Kind regards

 -- 
 ...........
 Dejan Lekic
  http://dejan.lekic.org
 

Mar 05 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Since strings are so fundamental, there should be a single standardized
 string interface. It needs to be powerful enough so that there is no 
 reason for anyone to develop a second string class for purpose x.

In my HTML engines (latest is http://terrainformatica.com/hsmile/hsmilesdk.zip ) I am using two my own string classes: string and ustring (unicode string). For example HTML DOM element attribute name is string, its value is ustring. This is all about effectivnes and memory consumption. As more I am looking in D as more I am thinking that string as char[] or wchar[] (D automatic arrays) is a way to go. It is a best compromise what you can reach. Strings are dual in their nature: they are atomic (value) type and an object with many methods derived from vector + their specific methods. You can define "external methods" for e.g. wchar[] thus to build a string class for target task in most optimal way. E.g. something like: alias wchar[] string; bool like(string s, string pattern); to call it as: string mystr; if( mystr.like("foo*") ) .... It's a pitty that "external methods" works only for arrays. I would like to extend them for all basic types. At least to be able to write T.toString() in templates. int i = 23; string s = i.toString(); Andrew Fedoniouk. http://terrainformatica.com
Mar 05 2005
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d07ohk$f7d$1 digitaldaemon.com...
 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d07dbj$24e$1 digitaldaemon.com...
 For the C++ types, I think an STL equivalent is the big thing. To this
 end, I really believe either DTL or MinTL needs to be integrated into
 core Phobos as part of a 1.0 release. This will make people in both
 camps happy (Java developers love their Collections).

I understand that, but a DTL is probably going to be a D 2.0 feature. But part of the problem is a perception issue. D handles already, in the core language, much of the functionality of STL. (For an example, see www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder where the 'string class' is. It takes a bit more in depth look at D to realize that a string class for D would be redundant, as would be vector classes, slice classes, for_each kludges, hash collections, etc. One other large reason for the existence of STL is memory management. D does automatic memory management. DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

Do dynamic arrays in D do automatic resizing like std::vector in C++? If not, a vector template would be useful. -Craig
Mar 04 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Craig Black" <cblack ara.com> wrote in message
news:d0b1b7$2g4b$1 digitaldaemon.com...
 Do dynamic arrays in D do automatic resizing like std::vector in C++?

Yes.
 If  not, a vector template would be useful.

D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.
Mar 04 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 If  not, a vector template would be useful.

D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.

Walter, may I ask you: who wrote this: "Resizing a dynamic array is a relatively expensive operation."? IMO, std::vectors are all about this. BTW: There is std::vector::insert operation which is not covered in D yet. In fact I've made a poll among companies (9) which do C++ seriously (very). 4 of them do not use STL at all 1 uses their own clone of STL due to lack of some features in foundation. 1 uses STL in full and there STL is a must - at corporate policy level. 2 use STL just for std::vector and simple stuff like min/max. As a rule STL is used in projects with stream processing style systems. Sort of stdin -> stdout. UI dictates different policies - UI frameworks has their own CArray/CString, etc. optimized for the target. D does basic STL functionality in its core and this is extremely good, IMO. I was "totally sliced" by the D slicing first time. But second time I've got your point and learned word 'dup' :) BTW, gentlemen, I've attached extremely simple (thanks to D) class array(T) {...} implementation and would like to hear any comments/critics about it before diving any deeper. Andrew Fedoniouk. http://terrainformatica.com
Mar 05 2005
next sibling parent zwang <nehzgnaw gmail.com> writes:
Andrew Fedoniouk wrote:
 BTW, gentlemen, I've attached extremely simple (thanks to D)
 class array(T) {...} implementation
 and would like to hear any comments/critics about it before diving any 
 deeper.
 
 Andrew Fedoniouk.
 http://terrainformatica.com

One suggestion after a quick glance of your neat code: make the gc happy at line 69.
Mar 05 2005
prev sibling parent reply "Nick Sabalausky" <z a.a> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0e84a$2aie$1 digitaldaemon.com...
 If  not, a vector template would be useful.

D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.

Walter, may I ask you: who wrote this: "Resizing a dynamic array is a relatively expensive operation."? IMO, std::vectors are all about this. BTW: There is std::vector::insert operation which is not covered in D yet.

You can do: myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray [insertIndex..length].dup; // Not sure if I need the '.dup's I'm not sure how the performance compares to std::vector::insert though.
 In fact I've made a poll among companies (9) which do C++ seriously 
 (very).

 4 of them do not use STL at all
 1 uses their own clone of STL due to lack of some features in foundation.
 1 uses STL in full and there STL is a must - at corporate policy level.
 2 use STL just for std::vector and simple stuff like min/max.

 As a rule STL is used in projects with stream processing style systems.
 Sort of stdin -> stdout. UI dictates different policies - UI
 frameworks has their own CArray/CString, etc. optimized for the target.

 D does basic STL functionality in its core and this is extremely good, 
 IMO.

 I was "totally sliced" by the D slicing first time. But second time I've 
 got
 your point and learned word 'dup' :)

 BTW, gentlemen, I've attached extremely simple (thanks to D)
 class array(T) {...} implementation
 and would like to hear any comments/critics about it before diving any 
 deeper.

 Andrew Fedoniouk.
 http://terrainformatica.com






 

Mar 06 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Thanks, Nick, for your comments

I don't think that you need dups here if I understand this mechanics:

 myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray 
 [insertIndex..length].dup; // Not sure if I need the '.dup's

But in any case it will create brand new myArray each time. For use cases with frequent insertions this is non acceptable I think. Andrew.
Mar 06 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d0fi39$fsd$1 digitaldaemon.com...

 I don't think that you need dups here if I understand this mechanics:

 myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray
 [insertIndex..length].dup; // Not sure if I need the '.dup's


The .dup is unnecessary here.
 But in any case it will create brand new myArray each time.

No. It uses a heuristic to avoid doing this most of the time.
 For use cases with frequent insertions this is non acceptable I think.

Mar 07 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:d0fi39$fsd$1 digitaldaemon.com...
 
 I don't think that you need dups here if I understand this
 mechanics:
 
 myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray 
 [insertIndex..length].dup; // Not sure if I need the '.dup's


The .dup is unnecessary here.
 But in any case it will create brand new myArray each time.

No. It uses a heuristic to avoid doing this most of the time.
 For use cases with frequent insertions this is non acceptable I
 think.


This is one of two ways to insert in an array. The other is uint len = newElement.length; myArray.length = myArray.length + len; myArray[insertIndex+len..length] = myArray[insertIndex..length-len].dup; myArray[insertIndex..insertIndex+len] = newElement; Does DMD optimise the above to something like this? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0kji1$2pt6$1 digitaldaemon.com...
 This is one of two ways to insert in an array.  The other is

      uint len = newElement.length;
      myArray.length = myArray.length + len;
      myArray[insertIndex+len..length]
        = myArray[insertIndex..length-len].dup;
      myArray[insertIndex..insertIndex+len] = newElement;

 Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.
Mar 09 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 9 Mar 2005 16:07:09 -0800, Walter <newshound digitalmars.com>  
wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0kji1$2pt6$1 digitaldaemon.com...
 This is one of two ways to insert in an array.  The other is

      uint len = newElement.length;
      myArray.length = myArray.length + len;
      myArray[insertIndex+len..length]
        = myArray[insertIndex..length-len].dup;
      myArray[insertIndex..insertIndex+len] = newElement;

 Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.

I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg. array.reserve = 1,000,000; Which would essentially cause: len = array.length; array.length = 1,000,000; array.length = len; Allowing us to reserve space before doing a large number of concatentations (for example). Obviating the need for 3 lines of code and a temp var. It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified. Another question, does the 'allocated' size ever decrease? If so, when? Is it possible for it to decrease while 1/2 way thru a large number of concatentions. Regan
Mar 09 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <opsnejj4bk23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Wed, 9 Mar 2005 16:07:09 -0800, Walter <newshound digitalmars.com>  
wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0kji1$2pt6$1 digitaldaemon.com...
 This is one of two ways to insert in an array.  The other is

      uint len = newElement.length;
      myArray.length = myArray.length + len;
      myArray[insertIndex+len..length]
        = myArray[insertIndex..length-len].dup;
      myArray[insertIndex..insertIndex+len] = newElement;

 Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.

I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg. array.reserve = 1,000,000; Which would essentially cause: len = array.length; array.length = 1,000,000; array.length = len; Allowing us to reserve space before doing a large number of concatentations (for example). Obviating the need for 3 lines of code and a temp var. It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified. Another question, does the 'allocated' size ever decrease? If so, when? Is it possible for it to decrease while 1/2 way thru a large number of concatentions. Regan

It's funny you mention this. I was working on adding the attached "dynamic array with capacity" to mintl.array plus some other array helpers but since it came up I thought I'd post about it. Anyway, comments welcome, -Ben
Mar 09 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 10 Mar 2005 04:28:26 +0000 (UTC), Ben Hinkle  
<Ben_member pathlink.com> wrote:
 In article <opsnejj4bk23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 On Wed, 9 Mar 2005 16:07:09 -0800, Walter <newshound digitalmars.com>
 wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0kji1$2pt6$1 digitaldaemon.com...
 This is one of two ways to insert in an array.  The other is

      uint len = newElement.length;
      myArray.length = myArray.length + len;
      myArray[insertIndex+len..length]
        = myArray[insertIndex..length-len].dup;
      myArray[insertIndex..insertIndex+len] = newElement;

 Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.

I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg. array.reserve = 1,000,000; Which would essentially cause: len = array.length; array.length = 1,000,000; array.length = len; Allowing us to reserve space before doing a large number of concatentations (for example). Obviating the need for 3 lines of code and a temp var. It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified. Another question, does the 'allocated' size ever decrease? If so, when? Is it possible for it to decrease while 1/2 way thru a large number of concatentions. Regan

It's funny you mention this. I was working on adding the attached "dynamic array with capacity" to mintl.array plus some other array helpers but since it came up I thought I'd post about it. Anyway, comments welcome,

At first glance the only difference between this and a built in dynamic array is the "capacity" functionality, correct? Something I noticed, not a big deal really... An implementation difference I notice is that you allocate exactly the requested length, not a power of 2, as Walter has mentioned the built-in array does. I think it's safest to make no guarantee about this behaviour (which you haven't, yet) as that lets you optimise later on. I notice your unittest expects this behaviour, but your invariant doesn't. Regan
Mar 09 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
 It's funny you mention this. I was working on adding the attached  
 "dynamic array
 with capacity" to mintl.array plus some other array helpers but since it  
 came up
 I thought I'd post about it.
 Anyway, comments welcome,

At first glance the only difference between this and a built in dynamic array is the "capacity" functionality, correct?

yes - I was thinking of a couple extra tricks like backwards iteration etc but basically it's just a compiler-independent capacity-aware array.
Something I noticed, not a big deal really...

An implementation difference I notice is that you allocate exactly the  
requested length, not a power of 2, as Walter has mentioned the built-in  
array does.

Since my posted code uses arrays they grow by powers of 2 if the compiler does that under the hood.
I think it's safest to make no guarantee about this behaviour (which you  
haven't, yet) as that lets you optimise later on. I notice your unittest  
expects this behaviour, but your invariant doesn't.

I should change the unittest to not look like that, though, since that wasn't my intention. I was going to always obey the capacity and let the user worry about increasing capacity at whatever rate they want or let the compiler decide under the hood.
Regan

Mar 09 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsnejj4bk23k2f5 nrage.netwin.co.nz...
 I know this has been mentioned before, but... Can we get a 'reserve'
 method/property. eg.

    array.reserve = 1,000,000;

 Which would essentially cause:

    len = array.length;
    array.length = 1,000,000;
    array.length = len;

 Allowing us to reserve space before doing a large number of
 concatentations (for example).
 Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?
 It can still, and should still allocate in powers of 2, it just allocates
 to the power of 2 greater than the value specified.

 Another question, does the 'allocated' size ever decrease?
 If so, when?
 Is it possible for it to decrease while 1/2 way thru a large number of
 concatentions.

That's at the discretion of the implementation of the gc.
Mar 09 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d0ojih$154h$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsnejj4bk23k2f5 nrage.netwin.co.nz...
 I know this has been mentioned before, but... Can we get a 'reserve'
 method/property. eg.

    array.reserve = 1,000,000;

 Which would essentially cause:

    len = array.length;
    array.length = 1,000,000;
    array.length = len;

 Allowing us to reserve space before doing a large number of
 concatentations (for example).
 Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?

I agree. We should just have a standard library template to do it. In the pre-DTL 0.3 pottering I'd got something like: template arrayTemporaryReserve(T) { T[] arrayTemporaryReserve(T[] at, size_t len) { size_t oldLen = at.len; at.length = len; at.length = oldLen; return at; } } We probably need to start thinking of all these kinds of utility functions, and deciding which ones need to be in Phobos proper. Perhaps we can have std/utility.d??
Mar 09 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d0ok99$15st$1 digitaldaemon.com>, Matthew says...
"Walter" <newshound digitalmars.com> wrote in message
news:d0ojih$154h$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsnejj4bk23k2f5 nrage.netwin.co.nz...
 I know this has been mentioned before, but... Can we get a 'reserve'
 method/property. eg.

    array.reserve = 1,000,000;

 Which would essentially cause:

    len = array.length;
    array.length = 1,000,000;
    array.length = len;

 Allowing us to reserve space before doing a large number of
 concatentations (for example).
 Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?

I agree. We should just have a standard library template to do it. In the pre-DTL 0.3 pottering I'd got something like: template arrayTemporaryReserve(T) { T[] arrayTemporaryReserve(T[] at, size_t len) { size_t oldLen = at.len; at.length = len; at.length = oldLen; return at; } } We probably need to start thinking of all these kinds of utility functions, and deciding which ones need to be in Phobos proper. Perhaps we can have std/utility.d??

The version from MinTL also treat 0 length specially since setting the length of an array to 0 throws away the ptr part. Hence any reserve is useless if you start from 0. /** Reserve a capacity for a dynamic array. If the array already has * more elements or if the original length is zero it does nothing. * Compiler-dependent. * \param x the array to modify * \param n the requested capacity */ template reserve(Value : Value[]) { void reserve(inout Value[] x, uint n) { uint oldlen = x.length; if ((oldlen < n) && (oldlen > 0)) { x.length = n; x.length = oldlen; } } }
Mar 09 2005
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:d0om9f$1931$1 digitaldaemon.com...
 In article <d0ok99$15st$1 digitaldaemon.com>, Matthew says...
"Walter" <newshound digitalmars.com> wrote in message
news:d0ojih$154h$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsnejj4bk23k2f5 nrage.netwin.co.nz...
 I know this has been mentioned before, but... Can we get a
 'reserve'
 method/property. eg.

    array.reserve = 1,000,000;

 Which would essentially cause:

    len = array.length;
    array.length = 1,000,000;
    array.length = len;

 Allowing us to reserve space before doing a large number of
 concatentations (for example).
 Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?

I agree. We should just have a standard library template to do it. In the pre-DTL 0.3 pottering I'd got something like: template arrayTemporaryReserve(T) { T[] arrayTemporaryReserve(T[] at, size_t len) { size_t oldLen = at.len; at.length = len; at.length = oldLen; return at; } } We probably need to start thinking of all these kinds of utility functions, and deciding which ones need to be in Phobos proper. Perhaps we can have std/utility.d??

The version from MinTL also treat 0 length specially since setting the length of an array to 0 throws away the ptr part. Hence any reserve is useless if you start from 0. /** Reserve a capacity for a dynamic array. If the array already has * more elements or if the original length is zero it does nothing. * Compiler-dependent. * \param x the array to modify * \param n the requested capacity */ template reserve(Value : Value[]) { void reserve(inout Value[] x, uint n) { uint oldlen = x.length; if ((oldlen < n) && (oldlen > 0)) { x.length = n; x.length = oldlen; } } }

Good point! I'll borrow that. :-)
Mar 09 2005
prev sibling parent reply Vathix <vathix dprogramming.com> writes:
 The version from MinTL also treat 0 length specially since setting the  
 length of
 an array to 0 throws away the ptr part. Hence any reserve is useless if  
 you
 start from 0.

I don't think it is special when using slice syntax; and slice syntax is probably faster since it doesn't have to look up the pointer in the GC table (or whatever) to see if the new length is smaller or bigger. char[] reserve(inout char[] buf, size_t len) { if(buf.length < len) { size_t prevLen; prevLen = buf.length; buf.length = len; buf = buf[0 .. prevLen]; } return buf; }
Mar 09 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <opsnep5qlhkcck4r esi>, Vathix says...
 The version from MinTL also treat 0 length specially since setting the  
 length of
 an array to 0 throws away the ptr part. Hence any reserve is useless if  
 you
 start from 0.

I don't think it is special when using slice syntax; and slice syntax is probably faster since it doesn't have to look up the pointer in the GC table (or whatever) to see if the new length is smaller or bigger. char[] reserve(inout char[] buf, size_t len) { if(buf.length < len) { size_t prevLen; prevLen = buf.length; buf.length = len; buf = buf[0 .. prevLen]; } return buf; }

The ptr is also thrown away when resizing from 0 as well. I think the only way to resize an array from 0 without throwing away the ptr is to cast the array to a pointer and then slice an arbitrary amount - though this isn't very safe since there are no checks for capacity.
Mar 10 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 9 Mar 2005 20:39:19 -0800, Walter <newshound digitalmars.com>  
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsnejj4bk23k2f5 nrage.netwin.co.nz...
 I know this has been mentioned before, but... Can we get a 'reserve'
 method/property. eg.

    array.reserve = 1,000,000;

 Which would essentially cause:

    len = array.length;
    array.length = 1,000,000;
    array.length = len;

 Allowing us to reserve space before doing a large number of
 concatentations (for example).
 Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?

True. template(T) { void reserve(T[] array, size_t size) { int osize = array.length; array.length = size; array.length = osize; }} but it doesn't look as nice, eg. char[] a; reserve!(char)(a,10); cos I can't write it as: char[] a; a.reserve(10); but, that would be possible if: - We had implicit instantiation - I could use the array/method feature with templates eg. char[] a; void foo(char[] a){} a.foo();
 It can still, and should still allocate in powers of 2, it just  
 allocates
 to the power of 2 greater than the value specified.

 Another question, does the 'allocated' size ever decrease?
 If so, when?
 Is it possible for it to decrease while 1/2 way thru a large number of
 concatentions.

That's at the discretion of the implementation of the gc.

So, no guarantess then. The current GC only does a pass when you allocate memory, so presuming you don't allocate it during the concatenation, it should be safe, right? Regan
Mar 09 2005
parent "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsnen9alz23k2f5 nrage.netwin.co.nz...
 So, no guarantess then. The current GC only does a pass when you allocate
 memory, so presuming you don't allocate it during the concatenation, it
 should be safe, right?

Yes.
Mar 14 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0kji1$2pt6$1 digitaldaemon.com...
 
This is one of two ways to insert in an array.  The other is

     uint len = newElement.length;
     myArray.length = myArray.length + len;
     myArray[insertIndex+len..length]
       = myArray[insertIndex..length-len].dup;
     myArray[insertIndex..insertIndex+len] = newElement;

Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>,

Seems obvious to me. It extends the array to accommodate the data to be added, then shifts data forward to make room for the insertion in the right place, and then inserts it.
 but all the D runtime does
 is have an 'allocated' size for each array, which is >= the .length. The
 allocated size goes up by powers of 2. The array doesn't need to be
 reallocated if there is enough space in the allocated size to handle the
 increase.

I'd got that far. But that doesn't tell me anything about how exactly it goes about optimising Nick's snippet, considering the specification that concatenation always creates a new array. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 10 2005
prev sibling parent reply brad domain.invalid writes:
Walter wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0kji1$2pt6$1 digitaldaemon.com...
 
This is one of two ways to insert in an array.  The other is

     uint len = newElement.length;
     myArray.length = myArray.length + len;
     myArray[insertIndex+len..length]
       = myArray[insertIndex..length-len].dup;
     myArray[insertIndex..insertIndex+len] = newElement;

Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.

dynamic arrays in D have an underlying length that is not equal to their actual length? And that this underlying allocated size increases with powers of two? If so, I think that there is a serious lack of documentation about a fundamental D data structure. The online docs specifically mention that increasing the size of an array by one at a time will be expensive - in my mind this implies that the .length is the actual size. If there is an underlying allocation size, it should be exposed as a properly and be allowed to be changed. I'm confused! :) Brad
Mar 10 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
brad domain.invalid wrote:
<snip>
 Sorry if I am being completely stupid here, but are you saying that 
 dynamic arrays in D have an underlying length that is not equal to their 
 actual length?  And that this underlying allocated size increases with 
 powers of two? 

In my experiments a while back, I found that it increases by powers of 2 up to 2 KB, and then by multiples of 2 KB.
 If so, I think that there is a serious lack of 
 documentation about a fundamental D data structure.  The online docs 
 specifically mention that increasing the size of an array by one at a 
 time will be expensive - in my mind this implies that the .length is the 
 actual size. 

It's not as expensive as that. But an array can still be reallocated more than once if .length is repeatedly increased. For example, this int[] qwert; for (int i = 0; i < 256; i++) { qwert ~= i*i; } would cause up to nine allocations, of sizes 1, 2, 4, 8, 16, 32, 64, 128 and then 256. Whereas if the length had been set to 256 in the first place, it would only need to allocate once. However, I don't see how the "more practical approach" given here http://www.digitalmars.com/d/arrays.html#resize is better than int[] array = new int[100]; array.length = 0; int c; while ((c = getinput()) != 0) { array ~= c; } nor why not improve matters by selecting an initial guess that's a power of 2.
 If there is an underlying allocation size, it should be 
 exposed as a properly and be allowed to be changed.

It seems that the underlying allocation size is a property of the heap-allocated block of memory, rather than of the array itself. But yes, it could be exposed as a property of the array - it would look up the array's starting address in the heap allocation table (or whatever it is) to find the length, in the same way the length setter does. As for setting the allocation size, I guess it would force a reallocation? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 11 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>
 It seems that the underlying allocation size is a property of the 
 heap-allocated block of memory, rather than of the array itself.  But 
 yes, it could be exposed as a property of the array - it would look up 
 the array's starting address in the heap allocation table (or whatever 
 it is) to find the length, in the same way the length setter does.  As 
 for setting the allocation size, I guess it would force a reallocation?

And for what isn't at the beginning of a heap block (slices not beginning at 0, static arrays viewed as dynamic, array views of static/stack data, stuff allocated by malloc or an external API) I guess that the allocation size would be reported as zero, representing that any increase of length will cause reallocation. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 11 2005
prev sibling parent florian <florian_member pathlink.com> writes:
I understand that, but a DTL is probably going to be a D 2.0 feature. But
part of the problem is a perception issue. D handles already, in the core
language, much of the functionality of STL. (For an example, see
www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder
where the 'string class' is. It takes a bit more in depth look at D to
realize that a string class for D would be redundant, as would be vector
classes, slice classes, for_each kludges, hash collections, etc.

Agreed. except that unless i missed something, core language does not handle lists, stacks, and queues. Having strings, vectors, hashmaps, and foreach IS nice, but I'd also like to see the other three basic containers I just mentioned in a 1.0 version. To me, as far as templates are concerned, every thing else can wait. (But of course, I won't complain if more is included.)
Mar 06 2005
prev sibling parent "Charlie Patterson" <charliep1 excite.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:d07dbj$24e$1 digitaldaemon.com...
 Walter wrote:
 I think the most important component to woo C++/Java developers is Phobos. 
 I have spoken with people who have shown an interest in D, but without a 
 standard library that offers what they have come to take for granted most 
 of them are hesitant to take the plunge.

This is my point, too. However, I'm sitting on the fence between a Java library rip-off and something truly wonderful. I was a bit disappointed when I looked through the Java libraries which were just the same old SmallTalk libraries. No templates, no generics, not even any speed/memory trade-off possibilities. I used to work in 3D graphics, so I could just have any old container without controlling it a bit algorithmically. So would it be best to have a simple Java-like set of containers and libs? Or a cleaned-up STL with all it's power and then some? Possibly it could be STL like in one layer, then have some quick and dirty "containers" written on top of that for rapid app development.
Mar 04 2005
prev sibling parent Mark T <Mark_member pathlink.com> writes:
In article <d04p7a$550$1 digitaldaemon.com>, Walter says...
"Jason Mills" <jmills cs.mun.ca> wrote in message
news:d04ccv$2nh7$1 digitaldaemon.com...
 I have been reading this newsgroup for several years. Although I post
 rarely I do read it every day. Early on I was so enthusiastic about D I
 could barely contain myself. I could not wait to use D at work,
 replacing C++ and Java. I'm still patiently waiting for that day. With
 C++/CLI soon a reality, improvements to C++ coming, together with
 existing versions of C# and Java, all with huge libraries ready to use
 out of the box, will D every be able to compete?

I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

absolutely, make sure there no major bugs then ship it. By the way I guess I am really referring to DMD 1.0. D Language standard itself could use the year or something else to stamp it. Hopefully the "D Language standard" won't change every 3 months.
Mar 04 2005
prev sibling next sibling parent jicman <jicman_member pathlink.com> writes:
In article <d04ccv$2nh7$1 digitaldaemon.com>, Jason Mills says...
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 
C++/CLI soon a reality, improvements to C++ coming, together with 
existing versions of C# and Java, all with huge libraries ready to use 
out of the box, will D every be able to compete?

Jason

I've already done more programs in d for tasks and for utilities than java and c. (I don't do much c++). Perl and Python, well, they are easy to script and to throw together so I've written more on those languages. But, d is here and here to stay, my friend. To me is already ready. It may need adjustments here and there, and it may still be lacking certain maturity, but I love the sense of just sending someone an executable file that does a task without having to install JRE or python or perl. D is here and it's only going to get better. Start using it. :-) jic
Mar 02 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Jason Mills wrote:
 I have been reading this newsgroup for several years. Although I post 
 rarely I do read it every day. Early on I was so enthusiastic about D I 
 could barely contain myself. I could not wait to use D at work, 
 replacing C++ and Java. I'm still patiently waiting for that day. With 
 C++/CLI soon a reality, improvements to C++ coming, together with 
 existing versions of C# and Java, all with huge libraries ready to use 
 out of the box, will D every be able to compete?

Hmm. A few thoughts: How bug free is DMD right now? Is it true that "average programs" (i.e. what anyone would write using Pascal, regular C, or the _average_ programmer using C++) can now be programmed without any fear of compiler bugs or the binary doing unexpedted things? How would you (= Walter, Kris, Matthew, and the others who've done a lot of D coding) rate D now, say, against "the average C++ compilers of today"? I'm not talking about rating as in the recent thread, just reliability. And I'm _not_ talking about libraries, not even Phobos. Just the compiler itself. And _no_ templates, delegates or other Fine stuff -- just Regular Programming related.
Mar 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4226033D.4030604 nospam.org...
 How would you (= Walter, Kris, Matthew, and the others who've done a lot
 of D coding) rate D now, say, against "the average C++ compilers of

 I'm not talking about rating as in the recent thread, just reliability.

 And I'm _not_ talking about libraries, not even Phobos. Just the
 compiler itself. And _no_ templates, delegates or other Fine stuff -- 
 just Regular Programming related.

Good question. I was fortunate, in doing D, to have available for ready use the optimizer and code generator from DMC++. This is very solid, as I've been maintaining it and improving it for 20+ years. It's very unusual for someone to find a bug in the code generator or optimizer, in either C++ or D. There's a very extensive test suite on it, essentially every fixed bug for the last 20 years is represented in the suite. I have a lot of confidence in that part of the compiler. Garbage collectors tend to be a rich source of bugs. But I've gone through that learning curve years ago on other projects. D's gc is not cutting edge gc technology, but it is a good, solid, reliable implementation. It works. Regular expressions are another potential problem area. But in poking around the internet I've found enough test vectors for it that I'm confident it works right. The thread module is problematic, because I don't understand threads very well. The rest of Phobos seems to be working well and is relatively trouble free. That leaves the front end. The basics of the language - expression evaluation, statements, functions, classes, variables, all work well. The problems frequently come from things like poor error recovery after reporting a syntax error, and combinations of newer features I hadn't expected. The good news is that every bug that gets fixed gets represented in the test suite that gets run on every build. This has the effect that the compiler ratchets forward constantly, and problems that are fixed stay fixed. When I built DMDScript in D, which is a fairly large chunk of code, revealed really only a couple bugs in DMD (which got fixed). Is D useable for serious development now? Yes. Can I guarantee that there won't be any changes to the language that will break existing code? No. But I am very sensitive to this issue, I am extremely reluctant to introduce changes that will require more than minor editting to adapt to, and as much as possible there will be 'transition' versions of the compiler that will highlight what needs to be changed. An example of this is the switch from the (type)expr casting syntax to cast(type)expr. Both are allowed now, but the former generates a 'deprecated' error message.
Mar 02 2005
parent reply "Zz" <Zz Zz.com> writes:
 Is D useable for serious development now? Yes.

commercial development I will surely say not yet. Once we see tools that can help in development e.g. IDE's with integrated debuggers it will be getting somewhere. I use D for pet projects and even for prototyping sometimes, but some people I work with will not even look at it until some tools are available for it. Zz
Mar 02 2005
parent Jason Mills <jmills cs.mun.ca> writes:
Zz wrote:
Is D useable for serious development now? Yes.

It really depends on what serious development means, if you are referring to commercial development I will surely say not yet. Once we see tools that can help in development e.g. IDE's with integrated debuggers it will be getting somewhere. I use D for pet projects and even for prototyping sometimes, but some people I work with will not even look at it until some tools are available for it. Zz

Exactly!
Mar 02 2005
prev sibling next sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
Jason Mills wrote:
 I have been reading this newsgroup for several years. Although I post 
 rarely I do read it every day. Early on I was so enthusiastic about D I 
 could barely contain myself. I could not wait to use D at work, 
 replacing C++ and Java. I'm still patiently waiting for that day. With 
 C++/CLI soon a reality, improvements to C++ coming, together with 
 existing versions of C# and Java, all with huge libraries ready to use 
 out of the box, will D every be able to compete?
 
 Jason

Don't get discouraged because it isn't officially 1.0. As Anders recently said, version numbers don't mean that much nowadays. Also, as Walter said, what we have right now is basically a (decreasingly) buggy 1.0, because there won't be major changes. So I'll say the same others have: just use D. If you can use it without experiencing problems, great. If you find bugs, just post them, and eventually/hopefully they'll be fixed. Usually there're work-arounds for the bugs. Summing up, everything you do in D right now, will help D. _______________________ Carlos Santander Bernal
Mar 02 2005
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <d04ccv$2nh7$1 digitaldaemon.com>, Jason Mills says...
I have been reading this newsgroup for several years. Although I post 
rarely I do read it every day. Early on I was so enthusiastic about D I 
could barely contain myself. I could not wait to use D at work, 
replacing C++ and Java. I'm still patiently waiting for that day. With 

Don't have time to read every reply so for. But many of us can't use beta products at work for real projects. D needs to get to 1.0 sooner then later. Believe it or not, it would also be helpful if Walter sells a $25-50 CD version (to cover production costs) so the suits think they have actually bought something. They allow us to get our updates via the net. I agree with Stewart about the library stuff, phobos is good enough for version 1.0.
Mar 04 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Mark T wrote:
<snip>
 I agree with Stewart about the library stuff, phobos is good enough for version
 1.0.

Are these two clauses supposed to be related in any way? If so, I can't see it. And have you evaluated its every module for completeness? For example, what about the issues here? http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 04 2005