www.digitalmars.com         C & C++   DMDScript  

D - A week with D: impressions

reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
Hi, after having spent 3 or 4 days trying to port the collections
framework from Java to D as a way of learning D, I have some
thoughts and impressions that I would like to share with you.

I do not want this to seem like a rant, so I am also a volunteer
to help fix any of the things I describe here.  I am very interested
in a language like D take enough momentum to become
viable.  Everything I say here is from an ignorant angle, since
I have only spent little time on D, so please forgive me if I
say " D should have X"  and it turns out D has X.


1) General Ideas

I am most impressed with D.  I think the dessign hits right in
the sweet spot, and most of the goals set in the overview
document are achieved.  I am most impressed with the
economy of the syntax and how much it accomplishes.
For example, the no use of the "operator" construct,
the reuse of simple array syntax for both static and dynamic
arrays, and how this goes almost unnoticed for a beginner,
but how there is a lot of power behind most concepts.  In
general all the new features are introduced almost in
surreptitiously, in such a way that it seems a logical
thing to do. It's not like "I have to learn this new thing",
but, "I would like to do this, and surprise, it's suported
alerady".  It accomplishes what the GUI people call
"progressive disclosure" of complexity, even if there is
little complexity, really.


2) Education

I think the manual as it is if fine, but it's almost a description
of the grammar mixed with illustrating comments.  There is
the need for more comprehensive examples on the use of
the language.  Also a longer more complete FAQ, including
all the possibly important questions that are posed
again and again in the newsgroup: "why isn't there a
boolean type" (my own below). "why is there no inner
classes in D", etc, etc.  A nice tutorial.  I have seen other
people have tutorials in  their sites, but something in the
main site would be nice.

3) Community

Having a bugzilla system would be very nice.  You can
track not only bugs but also proposed enhacements, and
maybe manage votes as Sun does with Java, to know how
many people from the community want a certain feature.
It gives peoplem the impression they have a saying, even
if they dont ;-)

Also, how about a peer reviewed library site, something
like boost for the c++ world.  I remember they started very
slow, and now they are publishing books about it.  That
might be a way to go around the whole "library comittee"
thing.

Also, making the newsgroup searchable from the web.


4) Grammar

I believe having a simple grammar is a great idea as well.  I
have seen all the troubles the people from the Eclipse CDT
project have integrating C++ tools into the platform.  In the Java
tools you can immediatly see the syntax errors while you
type, and I imagine being a nightmare thrying to do the
same for C++.  I think doing something like that for D
would be somewhat easier.


5) Language Issues (small and big)

- Boolean: I think for a C person (and I was one, long time
ago) it might look natural to do a condition using integers,
but I believe it helps so much to the readibility of the
language to have a boolean type.  Just in the LinkedList
example I was reading I was confused by something
like:

if (list.length) { ... }

Isn't much nicer to read:

if (list.length == 0) { ... }

I realize this has probably been touched on many times, but
I thought I would give my 2 cents.

- Abstract Classes: why do you have to implement the
whole interface that you are trying to extend?  I sent a
message regarding this yesterday.  I do not know if it is
a bug or a feature.

- Is there the need for a Collections library?  I think one of
the things Java got right is its collection library.  Most of the
comments about the complexity of C++ also apply to STL.
Java has a nice, small and usable Collections library.  Someone
knows if it is legal to copy Sun's design for this?

- Types: why keep the "uint", "ulong", ... types around.  I
am of the idea that the fewer basic types you have, the better.
It would actually be nice if we got rid of "float", but maybe
that's because I am not a numerical programmer (and some
of them would want to kill me for suggesting this).  I see how
having a "uint" makes your code simpler (i.e. no need to check
wether an index is >= than zero), but I like the simplicity
of very few types.  What do we need short for?  If you need
to save space, then use bytes, otherwise just use int.  Am I
being too simplistic?  I am very ignorant in this aspect, so
please feel free to tell me that I am way wrong here.

- GUI: there has been also talk about this in the newsgroup.
I think even if it means having a small usable GUI library,
it will draw many people to D, making it gain momentum.
I thnk the SWT route is a good one, specially because it
is a very clean design and simple implementation.  As opposed
to Swing they decided to separate the MVC framework from
the widgets.  I think it's an excellent idea, because it allows
for (again) "incremental disclosure" of complexity.

- Unit Testing: is porting JUnit to D a good idea?  apart
from the "unitest" block in D, I don't see much support for
building test cases and running them separately.  This is
also an area the manual is lacking in, it mentions unit
testing, but there is no documentation on it.

- Arrays being Objects: I also initiated a discussion on
this on the newsgroup.  After seeing the answer I have
a practical final comment, aside from how hard or
easy it is implement.  Having something like this will
a) not break any exisiting code, and b) make life easier
for people porting stuff from Java.  So I cannot see
how this can be a bad thing, except for being hard
to implement, ot bringing efficiency down.

- Interned Strings: a nice feature in Java are interned
strings.  Coming from Lisp, it's a nice compromise
between symbols and strings.  They are useful in parsing
XML, in implementing Knowledge Bases, and in general
in doing symbolic programming.  I have no idea if this
is hard or easy to implement (or if D already has it
and I don't know).

- Properties: I don't like that D forces me to use an
ugly name (for me of course, uglyness is a personal quality)  like
"m_data" when I define a property.  In the example in the
manual:

struct Foo
	{
	    int data() { return m_data; }	// read property

	    int data(int value) { return m_data = value; } // write property

	  private:
	    int m_data;
	}

I rename "m_data" to "data" (the compiler wont let me) even
though the "m_data" field is private.  There might some ambiguity
inside the class, but there could be rules to avoid this (like
inside the class always use the private one).

- Friends: from a software engineering point of view, I find
declaring a class "friends" with some other class very useful.
Sometimes you are declaring a Class, and in your head you
say, "ok, this class can only be maniuplated from this type
of classes", and in order to achieve that you have to make it
accessible to a whole package (In D or Java).  This is a nice
feature of C++, although I can see why it is debatable.

- Readonly: readonly properties would go a long way
into implementing most of what you want from a property,
without going through the detour of defining "getter" and
"setter" functions.  They are more efficient or don't require
compiler inlining.  It seems like such an easy way out of
the "getter and getter" nightmare that I wonder if I am
missing something here (as to why nobody has done it,
not even lisp which is usually really good about this type
of stuff).

- Side effects: Accessing a property should not have side
effects, this seems conterintuitive.  Specifically I am talking
about things like "sort" in arrays.  I am willing to think that I
have been entrained by other languages, so please convince
me it is the right thing to do.

- Instanceof: doing "a instanceof B" is some much nicer
and readable than "((B) a)".  Why not have it in the language
as a synonym?

- Global identifier: the identifier for global is ugly.  Writing
".toString(2)" does not seem very nice, but I do not have any
suggestions as to how to make it better/nicer.  What I find
ugly about it, just to make myself clear is the fact that the
dot "." is being applied to anything.  I know C++ uses "::",
but even that seems a little more balance than a single dot.

- Operator !==: Is anoying to have to write !(a === b), when
I want to see if something is different than null.

- Concatenation: as someone suggested on the newgroup
recently, in Java it is very nice to be able to write "value: " ~ 2.
Is it possible to implement it in D?  Is one of those things that
don't seem very orthogonal with the rest of the language, but
that are very practical and useful.

- Templates: the templates part of the language seems to be
the weakest, with few examples and an akward syntax.  And I
am not talking about the Foo<int> vs Foo(int) issue.  I really don't
care about that, and if it keeps the grammar simpler, much better.
I am talking about writing a generic function for "max", which
is the "hello world" of templates.  It requires way too much code,
and before seeing some example in the newsgroup, I was
even wondering if it was possible.

- Reflection: It would be nive to support for reflection (query
the class for methods and such), aside from the runtime type
information.  Since I see how such a thing would make certain
things inneficient, maybe the compiler could have a switch to
either include or not the reflection information?  This is the least
informed of my suggestions/comments, since I have not even
tried what's available in D.


6) Conclusion

I am very excited about being able to work with language like
D, and I would like it to gain momentum.  I am here to help,
so please let me know how can I do that.  I have started writing
a Java -> D translator to port some of my code and play a little
more with D.  But as I said, I am very impressed with everything
I have seen.

Congratulations to everybody involved in this project, I think
you have achieved a lot.

Cheers,

Andres
Feb 04 2004
next sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
Java got many things wrong. One of them is their Collections package. It has
the following drawbacks:

1) they are not type safe.
2) they need to use casting (run-time casting, that is) to get the desired
object back.

And all this is because of lack of templates. Check out the following
examples of Nice:

http://nice.sourceforge.net/safety.html

D does not need inner classes. It would be much better if it had signals and
slots/events. They are much cleaner.

Although C++ can make syntax checking while typing a little bit more
difficult, it's entirely feasible. The CDT did not get it, it's their
problem. Checkout the following tool that does full error highlighting while
you type (Visual Assist for MSVC++):

http://www.wholetomato.com/

D does not need a boolean, D needs typed sets. If there were sets, we could
have the following code:

set int bool {
    false = 0,
    true
}

We would have introduced a strong type 'bool' which takes two values: false
and true. It would also have a size. One could do bitfield enums, a feature
which is highly visible in low level software, yet no language has it.

Unsigned types are a must. There is a lot of software that depends on
unsigned values. In my company, we have to use a datatype that is bigger
from the one that we need, because the unsigned type does not fit in the
signed type of equal size. Which means that objects get to be twice as big,
with big impact on the cache etc.

And float is widely used in many defense apps.

Arrays being objects is a no-no, as far as I am concerned. It's too much of
a waste.

D should have a parameterized attribute 'friend', which is parameterized on
the class that is friend to the defined name. Example (excuse me for C++isms
and Javisms!!!):

private friend<List> class Node {
    private friend<List> Node prev;
    private friend<List> Node next;
}

A better alternative of 'instanceof' is the word 'is'. Example

If (a is B) {
}

Reflection is needed for efficiently implementing development tools,
especially RAD ones.

Conclusion ? it beats me. Everybody has his own preferences regarding
languages.
Feb 04 2004
next sibling parent "Andres Rodriguez" <rodriguez ai.sri.com> writes:
Thanks for your answering my comments.  More comments below.

 Java got many things wrong. One of them is their Collections package. It

 the following drawbacks:

 1) they are not type safe.
 2) they need to use casting (run-time casting, that is) to get the desired
 object back.

Agreed. When I was talking about the design, I was thinking more the way the divide the interface from the implementation (as in List vs ArrayList or LinkedList). I think 1) and 2) have to do more with the language not having templates than with anything else. Java 1.5 will correct that (at least at the syntax level, internally the same flaws apply). So, modulo lack of templates, I believe it's a very good design (vs complex ) STL.
 And all this is because of lack of templates. Check out the following
 examples of Nice:

 http://nice.sourceforge.net/safety.html

Will do.
 D does not need inner classes. It would be much better if it had signals

 slots/events. They are much cleaner.

I do not see how inner classes can be harmful.
 Although C++ can make syntax checking while typing a little bit more
 difficult, it's entirely feasible. The CDT did not get it, it's their
 problem.

No, I think it's our problem, because we spend more time trying to build tools around a difficult grammar (with more potential for bugs). All I am saying, all other things equal, I prefer having a simpler grammar. But that does not have to be dirver.
 D does not need a boolean, D needs typed sets.

Sure, I can also do "alias int bool" (which is not the same you are proposing, I know, it's only for illustration purposes), but I am talking about language support, so that programmers agree, and readable code can be shared.
Feb 04 2004
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bvri3h$29sa$1 digitaldaemon.com>, Achilleas Margaritis says...
A better alternative of 'instanceof' is the word 'is'. Example

If (a is B) {
}

Why not isa? If foo is a Bar, then why not have the operator called that? if (a isa B) {}
Feb 05 2004
parent "Andres Rodriguez" <rodriguez ai.sri.com> writes:
A better alternative of 'instanceof' is the word 'is'. Example

If (a is B) {
}

Why not isa? If foo is a Bar, then why not have the operator called that? if (a isa B) {}

Actually, coming from an Knowledge Representation background, that is what people in Ontologies call this relationship. A good source of standard names for this kind of thing is OWL, the upcoming standard for the semantic wen: http://www.w3.org/TR/2003/PR-owl-features-20031215/
Feb 05 2004
prev sibling next sibling parent Mark T <Mark_member pathlink.com> writes:
5) Language Issues (small and big)

- Boolean: I think for a C person (and I was one, long time
ago) it might look natural to do a condition using integers,
but I believe it helps so much to the readibility of the
language to have a boolean type?

give up this thought now, many have tried and failed before you :(
- Types: why keep the "uint", "ulong", ... types around.  >

You don't do embedded eh. We need this stuff!
- Unit Testing: is porting JUnit to D a good idea>

sounds good, why not
I have started writing a Java -> D translator to port some of my code and play
>a little more with D.  

this would be a big plus, please share it with the D community
Feb 04 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
Comments embedded, quote trimmed.

Andres Rodriguez wrote:
 2) Education

 I think the manual as it is if fine, but it's almost a description
 of the grammar mixed with illustrating comments.  There is

I never saw it as a manual, because the name is "D Language Specification".
 the need for more comprehensive examples on the use of
 the language.  Also a longer more complete FAQ, including
 all the possibly important questions that are posed
 again and again in the newsgroup: "why isn't there a
 boolean type" (my own below). "why is there no inner

Check out the wiki: http://www.prowiki.org/wiki4d/ (that's it, right?)
 classes in D", etc, etc.  A nice tutorial.  I have seen other
 people have tutorials in  their sites, but something in the
 main site would be nice.

You're right there.
 - Unit Testing: is porting JUnit to D a good idea?  apart
 from the "unitest" block in D, I don't see much support for
 building test cases and running them separately.  This is
 also an area the manual is lacking in, it mentions unit
 testing, but there is no documentation on it.

Also right: I have been with D for like year and a half, and I never do unit tests because I don't know how to use them.
 - Interned Strings: a nice feature in Java are interned
 strings.  Coming from Lisp, it's a nice compromise
 between symbols and strings.  They are useful in parsing
 XML, in implementing Knowledge Bases, and in general
 in doing symbolic programming.  I have no idea if this
 is hard or easy to implement (or if D already has it
 and I don't know).

I don't know about interned strings, but from what you explain it seems like regular expressions can do the same. If I'm missing something, then just ignore what I said.
 - Properties: I don't like that D forces me to use an
 ugly name (for me of course, uglyness is a personal quality)  like
 "m_data" when I define a property.  In the example in the
 manual:

 struct Foo
 {
     int data() { return m_data; } // read property

     int data(int value) { return m_data = value; } // write property

   private:
     int m_data;
 }

 I rename "m_data" to "data" (the compiler wont let me) even
 though the "m_data" field is private.  There might some ambiguity
 inside the class, but there could be rules to avoid this (like
 inside the class always use the private one).

You can give it any name you want.
 - Readonly: readonly properties would go a long way
 into implementing most of what you want from a property,
 without going through the detour of defining "getter" and
 "setter" functions.  They are more efficient or don't require
 compiler inlining.  It seems like such an easy way out of
 the "getter and getter" nightmare that I wonder if I am
 missing something here (as to why nobody has done it,
 not even lisp which is usually really good about this type
 of stuff).

Then don't write a setter ;).
 - Operator !==: Is anoying to have to write !(a === b), when
 I want to see if something is different than null.

You can do a !== b.
 - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

What about: template max(T) { T max ( T a, T b ) { if (a>b) return a; return b; } } ? ----------------------- Carlos Santander Bernal
Feb 04 2004
next sibling parent Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
Carlos Santander B. wrote:
 Check out the wiki: http://www.prowiki.org/wiki4d/ (that's it, right?)

That did not work for me, but this does: http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage Bastiaan.
Feb 04 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Carlos Santander B. wrote:

 Comments embedded, quote trimmed.
 
 Andres Rodriguez wrote:
 
2) Education

I think the manual as it is if fine, but it's almost a description
of the grammar mixed with illustrating comments.  There is

I never saw it as a manual, because the name is "D Language Specification".
the need for more comprehensive examples on the use of
the language.  Also a longer more complete FAQ, including
all the possibly important questions that are posed
again and again in the newsgroup: "why isn't there a
boolean type" (my own below). "why is there no inner

Check out the wiki: http://www.prowiki.org/wiki4d/ (that's it, right?)

http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit The links at the bottom are to THREADS. There have probably been 100 or 150 messages regarding the (alleged) deficiencies of D's bit. Walter's still unconvinced. I think the status quo is going to win this one. -- Justin http://jcc_7.tripod.com/d/
Feb 04 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
 - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

What about: template max(T) { T max ( T a, T b ) { if (a>b) return a; return b; } } ?

To cite it again: "It requires way too much code". Your example doesn't change it.
Feb 05 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Christian_Sch=FCler?= <leichenzehrer alpenjodel.de> writes:
shorts (16-bit int)

They have their use for instance in digital audio where your samples are 
16-bit. If you want to fill a wave buffer, you need shorts.

floats (32-bit float)

They are needed for instance if you want to fill a buffer with 3D-data 
and upload them to your graphics card.


 - Types: why keep the "uint", "ulong", ... types around.  I
 am of the idea that the fewer basic types you have, the better.
 It would actually be nice if we got rid of "float", but maybe
 that's because I am not a numerical programmer (and some
 of them would want to kill me for suggesting this).  I see how
 having a "uint" makes your code simpler (i.e. no need to check
 wether an index is >= than zero), but I like the simplicity
 of very few types.  What do we need short for?  If you need
 to save space, then use bytes, otherwise just use int.  Am I
 being too simplistic?  I am very ignorant in this aspect, so
 please feel free to tell me that I am way wrong here.

Feb 04 2004
parent Matthias Becker <Matthias_member pathlink.com> writes:
shorts (16-bit int)

They have their use for instance in digital audio where your samples are 
16-bit. If you want to fill a wave buffer, you need shorts.

floats (32-bit float)

They are needed for instance if you want to fill a buffer with 3D-data 
and upload them to your graphics card.

Feb 05 2004
prev sibling next sibling parent reply "C" <dont respond.com> writes:
 2) Education

towards andy ).
 3) Community

 Having a bugzilla system would be very nice.  You can

Yea , Benji who seems AWOL now had plans to set this up , im going to start a SF project , I have some code from a previous project ill just plug in.
 - Boolean: I think for a C person (and I was one, long time

bit , bool ?
 - Abstract Classes: why do you have to implement the

up on interfaces as I have never used them before ) , they force you to override the functions ?
 - Is there the need for a Collections library?

that little catch the built in dynamic arrays cover just about everything else.
 - Unit Testing: is porting JUnit to D a good idea?

this might be a little overkill! module foo; class Foo () { int DoSomething() { return 2; } } unittest { with ( new Foo ) { assert(DoSomething() == 2 ); } } these unittests get tested when u provide the -unittest flag.
 - Interned Strings:

 - Properties: I don't like that D forces me to use an ugly name

properties , im not exactly sure how they work ( or are supposed to work ) :S.
 - Readonly: readonly properties would go a long way

 - Instanceof: doing "a instanceof B" is some much nicer

if ( x is null ) fail();
 - Global identifier: the identifier for global is ugly.  Writing

kind of like the . notation ( to each his own ;) )
 - Operator !==:

 - Concatenation:

 - Templates:

syntax I think its the best on the market. I think W will probably change this ( the function syntax )
 I am very excited about being able to work with language like
 D, and I would like it to gain momentum.

Glad to have you!
 I am here to help,
 so please let me know how can I do that.

I never use Java , but alot of people say the syntax , design is similar , having a Java to D would be very cool , the SWT project needs members also I think :) Welcome! C "Andres Rodriguez" <rodriguez ai.sri.com> wrote in message news:bvrf4r$2584$1 digitaldaemon.com...
 Hi, after having spent 3 or 4 days trying to port the collections
 framework from Java to D as a way of learning D, I have some
 thoughts and impressions that I would like to share with you.

 I do not want this to seem like a rant, so I am also a volunteer
 to help fix any of the things I describe here.  I am very interested
 in a language like D take enough momentum to become
 viable.  Everything I say here is from an ignorant angle, since
 I have only spent little time on D, so please forgive me if I
 say " D should have X"  and it turns out D has X.


 1) General Ideas

 I am most impressed with D.  I think the dessign hits right in
 the sweet spot, and most of the goals set in the overview
 document are achieved.  I am most impressed with the
 economy of the syntax and how much it accomplishes.
 For example, the no use of the "operator" construct,
 the reuse of simple array syntax for both static and dynamic
 arrays, and how this goes almost unnoticed for a beginner,
 but how there is a lot of power behind most concepts.  In
 general all the new features are introduced almost in
 surreptitiously, in such a way that it seems a logical
 thing to do. It's not like "I have to learn this new thing",
 but, "I would like to do this, and surprise, it's suported
 alerady".  It accomplishes what the GUI people call
 "progressive disclosure" of complexity, even if there is
 little complexity, really.


 2) Education

 I think the manual as it is if fine, but it's almost a description
 of the grammar mixed with illustrating comments.  There is
 the need for more comprehensive examples on the use of
 the language.  Also a longer more complete FAQ, including
 all the possibly important questions that are posed
 again and again in the newsgroup: "why isn't there a
 boolean type" (my own below). "why is there no inner
 classes in D", etc, etc.  A nice tutorial.  I have seen other
 people have tutorials in  their sites, but something in the
 main site would be nice.

 3) Community

 Having a bugzilla system would be very nice.  You can
 track not only bugs but also proposed enhacements, and
 maybe manage votes as Sun does with Java, to know how
 many people from the community want a certain feature.
 It gives peoplem the impression they have a saying, even
 if they dont ;-)

 Also, how about a peer reviewed library site, something
 like boost for the c++ world.  I remember they started very
 slow, and now they are publishing books about it.  That
 might be a way to go around the whole "library comittee"
 thing.

 Also, making the newsgroup searchable from the web.


 4) Grammar

 I believe having a simple grammar is a great idea as well.  I
 have seen all the troubles the people from the Eclipse CDT
 project have integrating C++ tools into the platform.  In the Java
 tools you can immediatly see the syntax errors while you
 type, and I imagine being a nightmare thrying to do the
 same for C++.  I think doing something like that for D
 would be somewhat easier.


 5) Language Issues (small and big)

 - Boolean: I think for a C person (and I was one, long time
 ago) it might look natural to do a condition using integers,
 but I believe it helps so much to the readibility of the
 language to have a boolean type.  Just in the LinkedList
 example I was reading I was confused by something
 like:

 if (list.length) { ... }

 Isn't much nicer to read:

 if (list.length == 0) { ... }

 I realize this has probably been touched on many times, but
 I thought I would give my 2 cents.

 - Abstract Classes: why do you have to implement the
 whole interface that you are trying to extend?  I sent a
 message regarding this yesterday.  I do not know if it is
 a bug or a feature.

 - Is there the need for a Collections library?  I think one of
 the things Java got right is its collection library.  Most of the
 comments about the complexity of C++ also apply to STL.
 Java has a nice, small and usable Collections library.  Someone
 knows if it is legal to copy Sun's design for this?

 - Types: why keep the "uint", "ulong", ... types around.  I
 am of the idea that the fewer basic types you have, the better.
 It would actually be nice if we got rid of "float", but maybe
 that's because I am not a numerical programmer (and some
 of them would want to kill me for suggesting this).  I see how
 having a "uint" makes your code simpler (i.e. no need to check
 wether an index is >= than zero), but I like the simplicity
 of very few types.  What do we need short for?  If you need
 to save space, then use bytes, otherwise just use int.  Am I
 being too simplistic?  I am very ignorant in this aspect, so
 please feel free to tell me that I am way wrong here.

 - GUI: there has been also talk about this in the newsgroup.
 I think even if it means having a small usable GUI library,
 it will draw many people to D, making it gain momentum.
 I thnk the SWT route is a good one, specially because it
 is a very clean design and simple implementation.  As opposed
 to Swing they decided to separate the MVC framework from
 the widgets.  I think it's an excellent idea, because it allows
 for (again) "incremental disclosure" of complexity.

 - Unit Testing: is porting JUnit to D a good idea?  apart
 from the "unitest" block in D, I don't see much support for
 building test cases and running them separately.  This is
 also an area the manual is lacking in, it mentions unit
 testing, but there is no documentation on it.

 - Arrays being Objects: I also initiated a discussion on
 this on the newsgroup.  After seeing the answer I have
 a practical final comment, aside from how hard or
 easy it is implement.  Having something like this will
 a) not break any exisiting code, and b) make life easier
 for people porting stuff from Java.  So I cannot see
 how this can be a bad thing, except for being hard
 to implement, ot bringing efficiency down.

 - Interned Strings: a nice feature in Java are interned
 strings.  Coming from Lisp, it's a nice compromise
 between symbols and strings.  They are useful in parsing
 XML, in implementing Knowledge Bases, and in general
 in doing symbolic programming.  I have no idea if this
 is hard or easy to implement (or if D already has it
 and I don't know).

 - Properties: I don't like that D forces me to use an
 ugly name (for me of course, uglyness is a personal quality)  like
 "m_data" when I define a property.  In the example in the
 manual:

 struct Foo
 {
     int data() { return m_data; } // read property

     int data(int value) { return m_data = value; } // write property

   private:
     int m_data;
 }

 I rename "m_data" to "data" (the compiler wont let me) even
 though the "m_data" field is private.  There might some ambiguity
 inside the class, but there could be rules to avoid this (like
 inside the class always use the private one).

 - Friends: from a software engineering point of view, I find
 declaring a class "friends" with some other class very useful.
 Sometimes you are declaring a Class, and in your head you
 say, "ok, this class can only be maniuplated from this type
 of classes", and in order to achieve that you have to make it
 accessible to a whole package (In D or Java).  This is a nice
 feature of C++, although I can see why it is debatable.

 - Readonly: readonly properties would go a long way
 into implementing most of what you want from a property,
 without going through the detour of defining "getter" and
 "setter" functions.  They are more efficient or don't require
 compiler inlining.  It seems like such an easy way out of
 the "getter and getter" nightmare that I wonder if I am
 missing something here (as to why nobody has done it,
 not even lisp which is usually really good about this type
 of stuff).

 - Side effects: Accessing a property should not have side
 effects, this seems conterintuitive.  Specifically I am talking
 about things like "sort" in arrays.  I am willing to think that I
 have been entrained by other languages, so please convince
 me it is the right thing to do.

 - Instanceof: doing "a instanceof B" is some much nicer
 and readable than "((B) a)".  Why not have it in the language
 as a synonym?

 - Global identifier: the identifier for global is ugly.  Writing
 ".toString(2)" does not seem very nice, but I do not have any
 suggestions as to how to make it better/nicer.  What I find
 ugly about it, just to make myself clear is the fact that the
 dot "." is being applied to anything.  I know C++ uses "::",
 but even that seems a little more balance than a single dot.

 - Operator !==: Is anoying to have to write !(a === b), when
 I want to see if something is different than null.

 - Concatenation: as someone suggested on the newgroup
 recently, in Java it is very nice to be able to write "value: " ~ 2.
 Is it possible to implement it in D?  Is one of those things that
 don't seem very orthogonal with the rest of the language, but
 that are very practical and useful.

 - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

 - Reflection: It would be nive to support for reflection (query
 the class for methods and such), aside from the runtime type
 information.  Since I see how such a thing would make certain
 things inneficient, maybe the compiler could have a switch to
 either include or not the reflection information?  This is the least
 informed of my suggestions/comments, since I have not even
 tried what's available in D.


 6) Conclusion

 I am very excited about being able to work with language like
 D, and I would like it to gain momentum.  I am here to help,
 so please let me know how can I do that.  I have started writing
 a Java -> D translator to port some of my code and play a little
 more with D.  But as I said, I am very impressed with everything
 I have seen.

 Congratulations to everybody involved in this project, I think
 you have achieved a lot.

 Cheers,

 Andres

Feb 04 2004
parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
C, comments on your comments below.  Thanks for your
answers.

 - Boolean: I think for a C person (and I was one, long time

bit , bool ?

Is there a bool type in D? It's not mentioned in the spec.
 - Abstract Classes: why do you have to implement the

up on interfaces as I have never used them before ) , they force you to override the functions ?

Well, a concrete class should indeed implement them, an abstract class not necessarily.
 - Is there the need for a Collections library?


 that little catch the built in dynamic arrays cover just about everything
 else.

I agree that a resizable array is 50% of what you need 80% of the time, but ... how about generic hash tables (like associative arrays for any type, not just strings), or sets, or graphs, or ...
 - Interned Strings:


Sorry for not making myself clear. Interned strings are strings that live in the constant pool, so the same string only has one representation, and indentity tests (instead of equality tests) always hold. I realize it's not very intuitive to understand the need until you use them or you program in lisp.
 - Properties: I don't like that D forces me to use an ugly name

properties , im not exactly sure how they work ( or are supposed to work )

Well, I can't name them however I want, because the compiler says there is an ambiguity if I name them the same as the function.
 - Instanceof: doing "a instanceof B" is some much nicer

if ( x is null ) fail();

Is there a "is" operator in D?
 - Concatenation:


But it does not auomatically concatenate strings and integers, that was my point. Cheers, Andres
Feb 04 2004
next sibling parent "C" <dont respond.com> writes:
 Is there a bool type in D?  It's not mentioned in the spec.

 Well, a concrete class should indeed implement them, an
 abstract class not necessarily.

 I agree that a resizable array is 50% of what you need 80% of
 the time, but ... how about generic hash tables (like associative
 arrays for any type, not just strings), or sets, or graphs, or ...

associatave , dynamic ( all ) arrays work for any type.
 Well, I can't name them however I want, because the compiler says
 there is an ambiguity if I name them the same as the function.

on properties , but overall.
 Is there a "is" operator in D?

 But it does not auomatically concatenate strings and integers,
 that was my point.

Autmoatically ? no char [] foo = "My string is " ~ toString(21) ~ " charaters long"; C "Andres Rodriguez" <rodriguez ai.sri.com> wrote in message news:bvrr0l$2oi4$1 digitaldaemon.com...
 C, comments on your comments below.  Thanks for your
 answers.

 - Boolean: I think for a C person (and I was one, long time

bit , bool ?

Is there a bool type in D? It's not mentioned in the spec.
 - Abstract Classes: why do you have to implement the



 up on interfaces as I have never used them before ) , they force you to
 override the functions ?

Well, a concrete class should indeed implement them, an abstract class not necessarily.
 - Is there the need for a Collections library?


 that little catch the built in dynamic arrays cover just about


 else.

I agree that a resizable array is 50% of what you need 80% of the time, but ... how about generic hash tables (like associative arrays for any type, not just strings), or sets, or graphs, or ...
 - Interned Strings:


Sorry for not making myself clear. Interned strings are strings that live in the constant pool, so the same string only has one representation, and indentity tests (instead of equality tests) always hold. I realize it's not very intuitive to understand the need until you use them or you program in lisp.
 - Properties: I don't like that D forces me to use an ugly name

properties , im not exactly sure how they work ( or are supposed to


 Well, I can't name them however I want, because the compiler says
 there is an ambiguity if I name them the same as the function.

 - Instanceof: doing "a instanceof B" is some much nicer

if ( x is null ) fail();

Is there a "is" operator in D?
 - Concatenation:


But it does not auomatically concatenate strings and integers, that was my point. Cheers, Andres

Feb 04 2004
prev sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
 - Concatenation:


But it does not auomatically concatenate strings and integers, that was my point.

Since ~ acts on any array, not just strings, would you expect it to try to automatically convert an integer to a "compatible" array and concatenate that? Would there be some special cases for strings? Personally I like keeping ~ simple and making the user turn non-array into arrays by hand. It isn't that much more to type and removes special cases. -Ben
Feb 04 2004
prev sibling next sibling parent reply Roel Mathys <roel.mathys yucom.be> writes:
Andres Rodriguez wrote:

  > - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.
 

did you ever read this article :-) http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/ bye, roel
Feb 04 2004
parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"Roel Mathys" <roel.mathys yucom.be> wrote in message
news:bvrp3h$2klp$1 digitaldaemon.com...
 Andres Rodriguez wrote:

   > - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

did you ever read this article :-) http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/ bye, roel

Scary. Especially scary is the punchline at the end: "It would all be so nice, but there's a little detail worth mentioning. Sadly, Min doesn't work with any compiler I have access to. In fairness, each compiler chokes on a different piece of code." -Ben
Feb 04 2004
prev sibling next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
- Boolean: I think for a C person (and I was one, long time
ago) it might look natural to do a condition using integers,
but I believe it helps so much to the readibility of the
language to have a boolean type.  Just in the LinkedList
example I was reading I was confused by something
like:

if (list.length) { ... }

Isn't much nicer to read:

if (list.length == 0) { ... }

I realize this has probably been touched on many times, but
I thought I would give my 2 cents.

There is a boolean type called bool. Anyway, you can still write if (list.length) { ... }
- Abstract Classes: why do you have to implement the
whole interface that you are trying to extend?  I sent a
message regarding this yesterday.  I do not know if it is
a bug or a feature.

- Is there the need for a Collections library?  I think one of
the things Java got right is its collection library.  Most of the
comments about the complexity of C++ also apply to STL.
Java has a nice, small and usable Collections library.  Someone
knows if it is legal to copy Sun's design for this?

- Types: why keep the "uint", "ulong", ... types around.  I
am of the idea that the fewer basic types you have, the better.
It would actually be nice if we got rid of "float", but maybe
that's because I am not a numerical programmer (and some
of them would want to kill me for suggesting this).  I see how
having a "uint" makes your code simpler (i.e. no need to check
wether an index is >= than zero), but I like the simplicity
of very few types.  What do we need short for?  If you need
to save space, then use bytes, otherwise just use int.  Am I
being too simplistic?  I am very ignorant in this aspect, so
please feel free to tell me that I am way wrong here.

- Interned Strings: a nice feature in Java are interned
strings.  Coming from Lisp, it's a nice compromise
between symbols and strings.  They are useful in parsing
XML, in implementing Knowledge Bases, and in general
in doing symbolic programming.  I have no idea if this
is hard or easy to implement (or if D already has it
and I don't know).

- Properties: I don't like that D forces me to use an
ugly name (for me of course, uglyness is a personal quality)  like
"m_data" when I define a property.  In the example in the
manual:

struct Foo
	{
	    int data() { return m_data; }	// read property

	    int data(int value) { return m_data = value; } // write property

	  private:
	    int m_data;
	}

I rename "m_data" to "data" (the compiler wont let me) even
though the "m_data" field is private.  There might some ambiguity
inside the class, but there could be rules to avoid this (like
inside the class always use the private one).

- Friends: from a software engineering point of view, I find
declaring a class "friends" with some other class very useful.
Sometimes you are declaring a Class, and in your head you
say, "ok, this class can only be maniuplated from this type
of classes", and in order to achieve that you have to make it
accessible to a whole package (In D or Java).  This is a nice
feature of C++, although I can see why it is debatable.

AFAIK all classes within a modul can access privat members of other class in the same modul. But I've never tested that.
- Readonly: readonly properties would go a long way
into implementing most of what you want from a property,
without going through the detour of defining "getter" and
"setter" functions.  They are more efficient or don't require
compiler inlining.  It seems like such an easy way out of
the "getter and getter" nightmare that I wonder if I am
missing something here (as to why nobody has done it,
not even lisp which is usually really good about this type
of stuff).

- Instanceof: doing "a instanceof B" is some much nicer
and readable than "((B) a)".  Why not have it in the language
as a synonym?

But why? if (a instanceof B) { B b = cast(B)a; .. } B b = cast(B)a; if (b !== null) { .. } The first versionwould have to check the type twice. When do you need it?
- Global identifier: the identifier for global is ugly.  Writing
".toString(2)" does not seem very nice, but I do not have any
suggestions as to how to make it better/nicer.  What I find
ugly about it, just to make myself clear is the fact that the
dot "." is being applied to anything.  I know C++ uses "::",
but even that seems a little more balance than a single dot.

- Concatenation: as someone suggested on the newgroup
recently, in Java it is very nice to be able to write "value: " ~ 2.
Is it possible to implement it in D?  Is one of those things that
don't seem very orthogonal with the rest of the language, but
that are very practical and useful.

what about Foo[] myArray; myArray ~ 2; // what happens here?
Feb 05 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Andres Rodriguez wrote:
 [...]
 
 5) Language Issues (small and big)
 
 - Boolean: I think for a C person (and I was one, long time
 ago) it might look natural to do a condition using integers,
 but I believe it helps so much to the readibility of the
 language to have a boolean type.  Just in the LinkedList
 example I was reading I was confused by something
 like:
 
 if (list.length) { ... }
 
 Isn't much nicer to read:
 
 if (list.length == 0) { ... }
 
 I realize this has probably been touched on many times, but
 I thought I would give my 2 cents.

I'd prefer that integers couldn't be implicitly converted to booleans, but you can't win them all, I guess.
 
 - Is there the need for a Collections library?  I think one of
 the things Java got right is its collection library.  Most of the
 comments about the complexity of C++ also apply to STL.
 Java has a nice, small and usable Collections library.  Someone
 knows if it is legal to copy Sun's design for this?

I'm pretty sure you can't own an interface. As long as you're not copying from source, I don't see why not.
 
 - Unit Testing: is porting JUnit to D a good idea?  apart
 from the "unitest" block in D, I don't see much support for
 building test cases and running them separately.  This is
 also an area the manual is lacking in, it mentions unit
 testing, but there is no documentation on it.

More D is a good thing.
 
 - Arrays being Objects: I also initiated a discussion on
 this on the newsgroup.  After seeing the answer I have
 a practical final comment, aside from how hard or
 easy it is implement.  Having something like this will
 a) not break any exisiting code, and b) make life easier
 for people porting stuff from Java.  So I cannot see
 how this can be a bad thing, except for being hard
 to implement, ot bringing efficiency down.

One of the main goals of D is that it be easy to compile. It's nice to be able to expect D compilers to work correctly. (unlike, say, C++) This also tends to have the side effect of making compilation quite fast.
 
 - Interned Strings: a nice feature in Java are interned
 strings.  Coming from Lisp, it's a nice compromise
 between symbols and strings.  They are useful in parsing
 XML, in implementing Knowledge Bases, and in general
 in doing symbolic programming.  I have no idea if this
 is hard or easy to implement (or if D already has it
 and I don't know).

I assume the compiler could handle this. Arrays (not just strings) can be compared with the == operator. I would think that checking identity before comparing elements would achieve this.
 
 - Properties: I don't like that D forces me to use an
 ugly name (for me of course, uglyness is a personal quality)  like
 "m_data" when I define a property.  In the example in the
 manual:
 
 struct Foo
 	{
 	    int data() { return m_data; }	// read property
 
 	    int data(int value) { return m_data = value; } // write property
 
 	  private:
 	    int m_data;
 	}
 
 I rename "m_data" to "data" (the compiler wont let me) even
 though the "m_data" field is private.  There might some ambiguity
 inside the class, but there could be rules to avoid this (like
 inside the class always use the private one).

Allowing that would mean that the compiler would have to guess what you mean. If it guesses wrong, you are in big trouble. :)
 
 - Friends: from a software engineering point of view, I find
 declaring a class "friends" with some other class very useful.
 Sometimes you are declaring a Class, and in your head you
 say, "ok, this class can only be maniuplated from this type
 of classes", and in order to achieve that you have to make it
 accessible to a whole package (In D or Java).  This is a nice
 feature of C++, although I can see why it is debatable.

Friends only extend to the module scope in D, not package.
 
 - Readonly: readonly properties would go a long way
 into implementing most of what you want from a property,
 without going through the detour of defining "getter" and
 "setter" functions.  They are more efficient or don't require
 compiler inlining.  It seems like such an easy way out of
 the "getter and getter" nightmare that I wonder if I am
 missing something here (as to why nobody has done it,
 not even lisp which is usually really good about this type
 of stuff).

In Ruby, attributes can be set to be read-only, unless a method has access to private scope. This would be nice.
 
 - Side effects: Accessing a property should not have side
 effects, this seems conterintuitive.  Specifically I am talking
 about things like "sort" in arrays.  I am willing to think that I
 have been entrained by other languages, so please convince
 me it is the right thing to do.

Semantically, I agree, but the demands of the hardware cannot be ignored. Sorting in-place is much more efficient, and is often what people want to accomplish anyway. myarray = myarray.sort would not be terribly efficient. :) If you want a sorted copy, you can say myarray.dup.sort
 
 - Global identifier: the identifier for global is ugly.  Writing
 ".toString(2)" does not seem very nice, but I do not have any
 suggestions as to how to make it better/nicer.  What I find
 ugly about it, just to make myself clear is the fact that the
 dot "." is being applied to anything.  I know C++ uses "::",
 but even that seems a little more balance than a single dot.

It's simple, and relatively consistent with how the dot operator works. In general, it doesn't see much use, except with the toString functions sitting in std.string.
 
 - Concatenation: as someone suggested on the newgroup
 recently, in Java it is very nice to be able to write "value: " ~ 2.
 Is it possible to implement it in D?  Is one of those things that
 don't seem very orthogonal with the rest of the language, but
 that are very practical and useful.

I wrote a formatter object thing that accomplishes nearly this.
 
 - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

I find them to be quite sufficient, and easier to work with than C++ templates, but I tend to use them to parameterize classes, not write higher-order functions and the like. (for which they're not so hot, as there is no type deduction)
 
 6) Conclusion
 
 I am very excited about being able to work with language like
 D, and I would like it to gain momentum.  I am here to help,
 so please let me know how can I do that.  I have started writing
 a Java -> D translator to port some of my code and play a little
 more with D.  But as I said, I am very impressed with everything
 I have seen.

As said, more D code is a good thing. :) -- andy
Feb 05 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 - Templates: the templates part of the language seems to be
 the weakest, with few examples and an akward syntax.  And I
 am not talking about the Foo<int> vs Foo(int) issue.  I really don't
 care about that, and if it keeps the grammar simpler, much better.
 I am talking about writing a generic function for "max", which
 is the "hello world" of templates.  It requires way too much code,
 and before seeing some example in the newsgroup, I was
 even wondering if it was possible.

I find them to be quite sufficient, and easier to work with than C++ templates, but I tend to use them to parameterize classes, not write higher-order functions and the like. (for which they're not so hot, as there is no type deduction)

You have typeof, so you can do typededuction. But it's still ugly.
Feb 05 2004
parent Roel Mathys <roel.mathys yucom.be> writes:
Matthias Becker wrote:
- Templates: the templates part of the language seems to be
the weakest, with few examples and an akward syntax.  And I
am not talking about the Foo<int> vs Foo(int) issue.  I really don't
care about that, and if it keeps the grammar simpler, much better.
I am talking about writing a generic function for "max", which
is the "hello world" of templates.  It requires way too much code,
and before seeing some example in the newsgroup, I was
even wondering if it was possible.

I find them to be quite sufficient, and easier to work with than C++ templates, but I tend to use them to parameterize classes, not write higher-order functions and the like. (for which they're not so hot, as there is no type deduction)

You have typeof, so you can do typededuction. But it's still ugly.

second on that, without the type deduction templates aren't as powerful as with it roel
Feb 05 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I just wanted to say thanks for your comments and compliments.  It's 
nice to hear about (even more) people who are discovering D, linking it, 
and yet have ideas to contribute to its development.

Welcome!
Feb 05 2004