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 

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 

 out of the box, will D every be able to compete?




http://www.digitalmars.com/d/comparison.html

speaks for itself in this respect.


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 


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 

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 

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


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


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, 


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

 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




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




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


But how would the global scope resolution operator work? Something like this 
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?


 But how would the global scope resolution operator work? Something like  
 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?


 But how would the global scope resolution operator work? Something like 
 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?)


That makes sense for post-1.0 releases, but pre-1.0 should be able to break 
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 

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. 

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 

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. 

 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 

 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.

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 

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 

 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

 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

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 

Java), unless you think those languages arn't competitive to D and cater 

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

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 

Java), unless you think those languages arn't competitive to D and cater 

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 

 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 

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



 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 

 Java), unless you think those languages arn't competitive to D and cater 

 high level GUI type stuff).


Then again, theoretically, the sooner D goes out of the door, the better 

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, 



 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

 and cater to different markets. (D seems to be for low level 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++

 competitive with D and cater for different markets.  (D seems to be



 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

and cater to different markets. (D seems to be for low level 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++

competitive with D and cater for different markets.  (D seems to be




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


book

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


out

<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

 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?


There

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


want to

 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


it

 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




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)


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

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

 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

 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


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


strategy?

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


Walter: I'd love to see v1.0 before the end of this year, and even before the D
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:


<snip>

 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)


<snip>

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:


<snip>

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


<snip>

 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/


That looks nice for XCode.  Then for Visual Studio.NET there's DCoder, which 
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.
 
 


On the other hand, you still want to provide a standard string class.

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


   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.


 On the other hand, you still want to provide a standard string class.

 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.


 On the other hand, you still want to provide a standard string class.

 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.


 On the other hand, you still want to provide a standard string class.

 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



 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.


 On the other hand, you still want to provide a standard string class.

 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


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.

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


   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.

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.


And that what you don't want.
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.


 And that what you don't want.


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.


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?



 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.


   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



 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.


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


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

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.


   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.


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.


   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.


 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


I don't like coffee. :>
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


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.


:)

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






begin 666 darray.d






M=68[('T-" T*("  ("\O("YL96YG=&  <')O<&5R='D-"B  ("!U:6YT(&QE
M;F=T:" I('L <F5T=7)N('5S960[('T-"B  ("!V;VED(&QE;F=T:"AU:6YT



M("  ("  =6EN="!N97=?86QL;V-A=&5D(#T 8G5F+FQE;F=T:"HR.PT*"2  
M("  (&EF("AN(#X ;F5W7V%L;&]C871E9"D ;F5W7V%L;&]C871E9" ](&X[

M("  ("!U<V5D(#T

M*3L 8G5F6W1O<%T /2!V.PT*("  ('T-" T*("  ('9O:60 <'5S:"A46UT 

M:"AT;W  *R!V82YL96YG=& I.PT*"2  ("!B=69;=&]P+BYT;W  *R!V82YL
M96YG=&A=(#T



M=7-H*'8I.R!R971U<FX[('T-"B  ("  (&QE;F=T:"AU<V5D*S$I.PT*("  
M("  ;65M;6]V92 F8G5F6V%T*S%=+"9B=69;871=+"AU<V5D+6%T*2I4+G-I


M/2!U<V5D*2![('!U<V H=F$I.R!R971U<FX[('T-"B  ("  (&QE;F=T:"AU
M<V5D("L =F$N;&5N9W1H*3L-"B  ("  (&UE;6UO=F4H)F)U9EMA="MV82YL

M=69;870N+F%T*W9A+FQE;F=T:%T /2!V85LP+BYV82YL96YG=&A=.PT*("  
M('T-" T*("  (&)O;VP 96UP='DH*2![(')E='5R;B!U<V5D(#T


M"2  ("!A<W-E<G0H:2 \('5S960I.PT*"2  ("!R971U<FX 8G5F6VE=.PT*
M("  ('T-" T*("  (%0 ;W!);F1E>$%S<VEG;BA4('8L('5I;G0 :2D +R\ 
M;W9E<FQO861S(&%;:5T /2!V.PT*("  ('L-" D ("  87-S97)T*&D /"!U


M(2!D;VXG="!F;W)G970 =&\ 9'5P('1H92!R97-U;'0-"B  (" O+R  ("  
M(&EF('EO=2!N965D('1O('-T;W)E(&ET('-O;65W:&5R90T*("  ("\O("  
M("  ;7EH87-H6R)S<W,B72 ](&%;72YD=7 [( T*("  ('L-"B  ("  (')E

M:6YT(&PL('5I;G0 :"D)+R\ ;W9E<FQO861S(&%;:2 N+B!J70T*("  ('L-
M"B  ("  (&%S<V5R="AL(#P]('5S960I.PT*("  ("  87-S97)T*&  /#T 

M(&%R<F%Y(&]P0V%T07-S:6=N*%0 =BD >R!P=7-H*'8I.R!R971U<FX =&AI
M<SL ?2 O+R!O=F5R;&]A9', 87)R87D ?CT 5" -"B  ("!A<G)A>2!O<$-A
M=$%S<VEG;BA46UT =F$I('L <'5S:"AV82D[(')E='5R;B!T:&ES.R!]("\O

M('8I('L <'5S:"AV*3L <F5T=7)N('1H:7,[('T +R\ ;W9E<FQO861S(&%R
M<F%Y(#T
M<V H=F$I.R!R971U<FX =&AI<SL ?2 O+R!O=F5R;&]A9', 87)R87D /2!A


M?B!A<G)A>2 -"B  ("!A<G)A>2!O<$-A=%]R*%1;72!V82D >R!I;G-E<G0H
M,"QV82D[(')E='5R;B!T:&ES.R!]("\O(&]V97)L;V%D<R!A<G)A>2 ](%1;

`
end



 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


begin 0644 cda.d
M;6]D=6QE(&-D83L*"B\O('1H:7, 9FEL92!I<R!I;B!T:&4 <'5B;&EC(&1O
M;6%I; H*<W1R=6-T($-$02A4*2!["B` <')I=F%T92!46UT 9&%T83L*("!P
M<FEV871E('-I>F5?="!L96X[" H (&EN=F%R:6%N="!["B` ("!A<W-E<G0H
M(&QE;B`\/2!D871A+FQE;F=T:"`I.PH ('T*"B` +R\ 96YS=7)E(&%T(&QE
M87-T('1H:7, ;G5M8F5R(&]F(&%V86EL86)L92!L;V-A=&EO;G,*("`O+R!)
M9B!Y;W4 =V%N="!T;R!S:')I;FL =&AE(&-A<&%C:71Y(&UA:V4 82!N97< 
M0T1!"B` =F]I9"!C87!A8VET>2AS:7IE7W0 8V%P*2!["B` ("!I9B`H9&%T
M82YL96YG=&  /"!C87`I"B` ("` (&1A=&$N;&5N9W1H(#T 8V%P.PH ('T*
M"B` <VEZ95]T(&-A<&%C:71Y*"D >PH ("` <F5T=7)N(&1A=&$N;&5N9W1H
M.PH ('T*"B` <VEZ95]T(&QE;F=T:" I('L*("` (')E='5R;B!L96X["B` 
M?0H*("!V;VED(&QE;F=T:"AS:7IE7W0 ;F5W;&5N*2!["B` ("!C87!A8VET
M>2AN97=L96XI.PH ("` ;&5N(#T ;F5W;&5N.PH ('T*"B` 5%M=(&%R<F%Y
M*"D >PH ("` <F5T=7)N(&1A=&%;,"XN;&5N73L*("!]" H ($-$02!D=7`H


M("` (')E='5R;B!R97, ?CT >#L
M>PH ("` <F5T=7)N("IT:&ES('X >"YA<G)A>3L*("!]" H ($-$02!O<$-A
M=$%S<VEG;BA46UT >"D >PH ("` 8V%P86-I='DH>"YL96YG=& K;&5N*3L*
M("` (&1A=&%;;&5N("XN(&QE;BMX+FQE;F=T:%T /2!X6UT["B` ("!L96X 


M<F%Y.PH ('T*"B` 5%M=(&]P4VQI8V4H<VEZ95]T(&$L('-I>F5?="!B*2![
M"B` ("!R971U<FX 9&%T85MA("XN(&)=.PH ('T*"B` 5"!O<$EN9&5X*'-I
M>F5?="!I*2!["B` ("!I9B`H:2`^/2!L96XI"B` ("` ('1H<F]W(&YE=R!%
M>&-E<'1I;VXH(DEN9&5X(&]U="!O9B!B;W5N9',B*3L*("` (')E='5R;B!D
M871A6VE=.PH ('T*"B` 5"!O<$EN9&5X07-S:6=N*%0 =F%L+"!S:7IE7W0 
M:2D >PH ("` :68 *&D /CT ;&5N*0H ("` ("!T:')O=R!N97< 17AC97!T
M:6]N*"));F1E>"!O=70 ;V8 8F]U;F1S(BD["B` ("!R971U<FX 9&%T85MI
M72`]('9A;#L*("!]" H (%0J('!T<B I('L*("` (')E='5R;B!D871A+G!T
M<CL*("!]" H ($-$02!S;W)T*"D >PH ("` <F5T=7)N('1O0T1!(2A4*2AD
M871A6S`N+FQE;ETN<V]R="QL96XI.PH ('T*"B` 0T1!(')E=F5R<V4H*2![

M;BD["B` ?0H (`I]" IT96UP;&%T92!T;T-$02A4*2!["B` 0T1!(2A4*2!T
M;T-$02A46UT 9&%T82P <VEZ95]T(&QE;BD >PH ("` :68 *&QE;B`^(&1A

M>2!M=7-T(&)E(&QA<F=E<B!T:&%N(&QE;B(I.PH ("` 0T1!(2A4*2!R97,[
M"B` ("!R97,N9&%T82`](&1A=&$["B` ("!R97,N;&5N(#T ;&5N.PH ("` 
M<F5T=7)N(')E<SL*("!]"GT*" IU;FET=&5S="!["B` 0T1!(2AI;G0I(' [
M"B` >"YL96YG=&  /2`Q,#L*("!A<W-E<G0H(' N8V%P86-I='D /3T ,3` 
M*3L*("!X+F-A<&%C:71Y(#T ,C`["B` 87-S97)T*"!X+F-A<&%C:71Y(#T]

M,#L*("!A<W-E<G0H('A;-5T /3T ,3` *3L*"B` :6YT6UT >2`](&YE=R!I


M6S( +BX -5T *3L*"B` 87-S97)T*"!X+G!T<B`]/2!X+F%R<F%Y+G!T<B`I
M.PH (&%S<V5R="  >"YA<G)A>2YL96YG=&  /3T >"YL96YG=&  *3L*"B` 
M>"YL96YG=&  /2`U.PH ('  /2!X+G)E=F5R<V4["B` 87-S97)T*"!X6S!=
M(#T
0('A;-%T /3T ,"`I.PI]"F5R
`
end



 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.
 
 


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

 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 

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 

 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


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.


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.


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



 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 

 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