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

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.

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.

>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

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

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.

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

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

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.

"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