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


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.


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


and

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


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


Well I need 32-bit floats for digital audio processing. :)
Feb 05 2004
prev sibling next sibling parent reply "C" <dont respond.com> writes:
 2) Education


I agree , we need more tutorials, especially on the D templates ( looks
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


Isnt that why people like them ( I just got ATL 3.0 workshop , and reading
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?


I've created a Deque class that does autmoatic array resizing , but besides
that little catch the built in dynamic arrays cover just about everything
else.


 - Unit Testing: is porting JUnit to D a good idea?


Ive never used JUnit , but seeing as its built into the language I think
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:


WYSIWYG strings ?  if so we have those with ` ` ( backticks )


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


you can use any name u want , but Ive run into a couple problems with
properties , im not exactly sure how they work ( or are supposed to work )
:S.


 - Readonly: readonly properties would go a long way


I always liked this idea :D.


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


You mean 'is' ?
if ( x is null  ) fail();


 - Global identifier: the identifier for global is ugly.  Writing


I never knew that was a global identifier lol , I mostly use aliases , but i
kind of like the . notation ( to each his own ;) )


 - Operator !==:


D has it , u can also use  if ( ! (d is null ) )


 - Concatenation:


D has it , the ~ is concatentation.


 - Templates:


I think a nicer template function syntax could be had , but for the class
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


 Isnt that why people like them ( I just got ATL 3.0 workshop , and reading
 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?


 I've created a Deque class that does autmoatic array resizing , but


besides

 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:


 WYSIWYG strings ?  if so we have those with ` ` ( backticks )


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


 you can use any name u want , but Ive run into a couple problems with
 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


 You mean 'is' ?
 if ( x is null  ) fail();


Is there a "is" operator in D?


 - Concatenation:


 D has it , the ~ is concatentation.


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.


There is a bit , which is aliased to bool somewhere in phobos.


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


Ahh i see what u mean.


 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.


you cant name members the same as methods no , but this isnt a restritcion
on properties , but overall.


 Is there a "is" operator in D?


yes.


 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


 Isnt that why people like them ( I just got ATL 3.0 workshop , and




reading

 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?


 I've created a Deque class that does autmoatic array resizing , but


 besides

 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:


 WYSIWYG strings ?  if so we have those with ` ` ( backticks )


 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


 you can use any name u want , but Ive run into a couple problems with
 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


 You mean 'is' ?
 if ( x is null  ) fail();


 Is there a "is" operator in D?


 - Concatenation:


 D has it , the ~ is concatentation.


 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:


 D has it , the ~ is concatentation.


 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.


I never got that, too.



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


Hm, I prefer STL over Javas collections. 



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


You're kidding, aren't you?



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


Yes, that would be nice (, but I'm not sure if D already has it, too).



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


This is something we should think about.



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


You got my vote.



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


"((B) a)" is the old cast-synthax. You should use the new one: "(cast(B) a)".

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.


That's exactly my opinion, but many others like it the way it is :(



- 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