www.digitalmars.com         C & C++   DMDScript  

D - About "D vs. C/C##/C#/Java"

reply Matthias Becker <Matthias_member pathlink.com> writes:
About the compairison table:

especialy about Java:

Resizeable arrays:
Java has resizeable arrays in java.util.* you have one. Now you could say it's
part of the library not of the language, but where do you draw the line between
language and library in Java? Is java.lang.Object Part of the language or part
of the library? All classes implicitly inherit from it, so I guess it is part of
the language. But if the package java.lang.* is part of the language why isn't
java.util.*?
At least there should be a note, but I would prefer a "Yes".

Associative arrays:
Same as above.

Templates:
Make a note about Java, that 1.5 will have generic types.

Compatibility -> direct access to C:
What about JNI? This should become a Yes.


Compatiblity -> Use existing debuggers:
Why should I want to use "existing" debuggers to debug Java oder C# code?




And than I miss some points in your table:
under Features:
Documentation in the sourcecode:
D: No
C: No
C++: No
C#: No
Java: Yes

don't know where, maybe arrays, as there are your strong typedefs:
system independet floatinpoint arithmetic:
D: No
C: No
C++: No
C#: No
Java: Yes (strictfp)

don't know where, maybe arrays, as there are your strong typedefs:
unsigned types:
D: Yes
C: Yes
C++: Yes
C#: Yes
Java: No

under Arrays:
Covariant arrays:
D: No
C: No
C++: No
C#: Yes
Java: No

under OOP:
Reflection:
D: VERY limited (if this stays a yes/no-table No)
C: No
C++: No
C#: Yes
Java: Yes

under Performance (below Templates <- sould be called generic types)
Automatic type deduction:
D: No
C: No
C++: Yes
C#: No
Java: No

under Other:
Container/Collections:
D: No
C: No
C++: Yes
C#: Yes
Java: Yes

under Other:
GUI, Grafic routines, Internet (sokets, ...)
D: No
C: No
C++: No
C#: No
Java: Yes

under Other:
Object serialising:
D: No
C: No
C++: No
C#: No
Java: Yes

under Other:
Remote Procedure Call:
D: No
C: No
C++: No
C#: Yes
Java: Yes


These points might help to choose, which language is the right one for the task
you have to do.
Dec 21 2003
next sibling parent "Charles" <sanders-consulting comcast.net> writes:
This assesment sounds very Java biased, I disagree with alot of these ,
especially Java and C# have RPC ?!?!?!  RPC has been on unix with C
forever.. , and we have graphic and internet routrines, have you seen the
socket and opengl modules ?

no , no , no  ... nothing about this adds up at all!

C
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bs4jkq$rv4$1 digitaldaemon.com...
 About the compairison table:

 especialy about Java:

 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one. Now you could say

 part of the library not of the language, but where do you draw the line

 language and library in Java? Is java.lang.Object Part of the language or

 of the library? All classes implicitly inherit from it, so I guess it is

 the language. But if the package java.lang.* is part of the language why

 java.util.*?
 At least there should be a note, but I would prefer a "Yes".

 Associative arrays:
 Same as above.

 Templates:
 Make a note about Java, that 1.5 will have generic types.

 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.


 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C# code?




 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes
 C#: Yes
 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes


 These points might help to choose, which language is the right one for the

 you have to do.

Dec 21 2003
prev sibling next sibling parent reply "Charles" <sanders-consulting comcast.net> writes:
Actually I cant help myself I have to flame here.

Java sucks.  Almost all applications that use Java on my machine are
un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
RAM!  No other application runs that slowly , not even games.

And the dependence on such a huge virtual machine is a big hit to the
language, especially to mimamlist progammers as myself ( D's toolkit fits on
a floppy ).

What is it about Java that you like ?

C

"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bs4jkq$rv4$1 digitaldaemon.com...
 About the compairison table:

 especialy about Java:

 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one. Now you could say

 part of the library not of the language, but where do you draw the line

 language and library in Java? Is java.lang.Object Part of the language or

 of the library? All classes implicitly inherit from it, so I guess it is

 the language. But if the package java.lang.* is part of the language why

 java.util.*?
 At least there should be a note, but I would prefer a "Yes".

 Associative arrays:
 Same as above.

 Templates:
 Make a note about Java, that 1.5 will have generic types.

 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.


 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C# code?




 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes
 C#: Yes
 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes


 These points might help to choose, which language is the right one for the

 you have to do.

Dec 21 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...
Actually I cant help myself I have to flame here.

Java sucks.  Almost all applications that use Java on my machine are
un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
RAM!  No other application runs that slowly , not even games.

And the dependence on such a huge virtual machine is a big hit to the
language, especially to mimamlist progammers as myself ( D's toolkit fits on
a floppy ).

I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...
Dec 21 2003
parent reply "Charles" <sanders-consulting comcast.net> writes:
hehe, sorry Mhz :P

C
"Ant" <Ant_member pathlink.com> wrote in message
news:bs4o9o$1320$1 digitaldaemon.com...
 In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...
Actually I cant help myself I have to flame here.

Java sucks.  Almost all applications that use Java on my machine are
un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
RAM!  No other application runs that slowly , not even games.

And the dependence on such a huge virtual machine is a big hit to the
language, especially to mimamlist progammers as myself ( D's toolkit fits


a floppy ).

I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...

Dec 21 2003
parent John Reimer <John_member pathlink.com> writes:
JOKE: I can see java running slow on either 2.4 mHz or 2.4 MHz. ;-)


In article <bs4tcr$1ahc$1 digitaldaemon.com>, Charles says...
hehe, sorry Mhz :P

C
"Ant" <Ant_member pathlink.com> wrote in message
news:bs4o9o$1320$1 digitaldaemon.com...
 In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...
Actually I cant help myself I have to flame here.

Java sucks.  Almost all applications that use Java on my machine are
un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
RAM!  No other application runs that slowly , not even games.

And the dependence on such a huge virtual machine is a big hit to the
language, especially to mimamlist progammers as myself ( D's toolkit fits


a floppy ).

I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...


Dec 21 2003
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Charles wrote:
 Java sucks.  Almost all applications that use Java on my machine are
 un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
 RAM!  No other application runs that slowly , not even games.

Hmmmm..... I think you have too much RAM. Thus it takes it too long between collection phases, which then last too long. Wanna share some? I think 128 Kilobytes RAM would be a more than generous match for a 2,4 _MHz_ can ;>>>>>>> And i think my 233 and 600 MHz computers would manage it much better. That's what i would call social equality. ;> Also, be sure to use either IBM Java 1.3.1, or SUN Java 1.4.2 - these are much faster than the others.
 And the dependence on such a huge virtual machine is a big hit to the
 language, especially to mimamlist progammers as myself ( D's toolkit fits on
 a floppy ).

Cubistic minimalistic. Floppyistic.
 What is it about Java that you like ?

Well, everyone has a VM installed anyway. ;) Compiling foereign applications for one or another platform was never my favorite job. OTOH, i with my slow computers am pretty happy when i don't need to run any of these monsters. -eye
Dec 21 2003
prev sibling parent "Phill" <phill pacific.net.au> writes:
I admit Java does lag a bit but:
I think it depends who writes the Java program
as to how it performs. I know that I have written an
Email application(not a small one) in Java which can appear as fast as
outlook express, and never "locks the system".
I have 256 megs of ram and a Athlon 2100(not that that
matters because they are both on the same machine.)
One of Java's greatest advantages is that it is
very very easy to find info and tutorials when you
are learning, and everyone is pleased to help.
Finding a decent tutorial on MFC for example, is
like trying to find a virgin over the age of twelve.

Phill.



"Charles" <sanders-consulting comcast.net> wrote in message
news:bs4m1m$vmh$1 digitaldaemon.com...
 Actually I cant help myself I have to flame here.

 Java sucks.  Almost all applications that use Java on my machine are
 un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+
 RAM!  No other application runs that slowly , not even games.

 And the dependence on such a huge virtual machine is a big hit to the
 language, especially to mimamlist progammers as myself ( D's toolkit fits

 a floppy ).

 What is it about Java that you like ?

 C

 "Matthias Becker" <Matthias_member pathlink.com> wrote in message
 news:bs4jkq$rv4$1 digitaldaemon.com...
 About the compairison table:

 especialy about Java:

 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one. Now you could


 it's
 part of the library not of the language, but where do you draw the line

 language and library in Java? Is java.lang.Object Part of the language


 part
 of the library? All classes implicitly inherit from it, so I guess it is

 the language. But if the package java.lang.* is part of the language why

 java.util.*?
 At least there should be a note, but I would prefer a "Yes".

 Associative arrays:
 Same as above.

 Templates:
 Make a note about Java, that 1.5 will have generic types.

 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.


 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C#


 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes
 C#: Yes
 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes


 These points might help to choose, which language is the right one for


 task
 you have to do.


Dec 24 2003
prev sibling next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Disclaimer -- I have worked, and still work, with Java for some 
purposes/projects, so I'm not anti-Java biased, although I do have a few 
issues with it.  But...

Sun maintains in the specs that 'java.lang.*' is part of the language, 
as well as its subpackages, but everything else is strictly libraries 
and subject at any second of the day to complete change.

I wouldn't call JNI direct access to C.  I've used JNI a couple of 
times, but I don't call having to write my own C wrapper, create and 
include header (thank goodness there's a tool for that!), etc as direct 
access.  D's direct access is just that.  I import std.c.*, or etc.c.*, 
or c.* and I'm done.  Naturally we don't really have a .* yet.  I want 
one, personally.  However I do agree it could be Yes with a note.

As to debuggers... I wouldn't want to either, but some people will. 
Just because its listed in the comparison does not mean we're pushing 
it, its just something that one of us thought of / requested.

 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

I'm not 100% sure in what sense you mean "documentation in the source code" here.
 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

That's being worked on. And actually, I believe there is a way of doing it in Java, but if I remember right its more of a hassle than its worth, hardly something that could be called 'automatic'. I'd have to double-check my claim though.
 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

Just.. eh?
 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

I think this goes back to what is or isn't part of the language. If you go by the standard (as I know it) then Java doesn't have any of this either. If you consider standard and readily-available libraries to be part of the language, then D, C#, and to an extent C++ are all Yes's.
 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes

I'm not sure it would really make sense as a language feature in a platform like D. Although, it wouldn't be /too/ difficult to implement using socket libs and delegates (maybe referenced via an assoc-array).
 These points might help to choose, which language is the right one for the task
 you have to do.

Hmm. -- C. Sauls -- Invironz
Dec 21 2003
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Matthias Becker wrote:
 About the compairison table:
 especialy about Java:

I can't see what you so particularly like about Java. That is, there are = one or two good points, but it's definately not the answer when looking=20 for an environment allowing to write fast, lightweight applications=20 conveniently. And hey, don't forget, th=EDs table is for advertising D, not Java! If yo= u=20 want to make Java the center of your world, don't tamper with our table. = Make your own.
 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one.=20

It's a complicated question. :(
 Associative arrays:
 Same as above.

Then you should say that about C++ as well.
 Templates:
 Make a note about Java, that 1.5 will have generic types.

We all know that. But they are not there yet. Besides, they are purely=20 syntactic, that is they only free of casts in Java. In static languages=20 like C++, D, and Sather, generics also vastly improve execution=20 efficiency. Because these all have value-semantics UDT.
 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.

No, this is not direct. It requieres C stubs. As opposed to that, you=20 can directly call C code from lanuguages like C++, Delphi and D. And=20 even Sather. This goes along with having constructs in the language=20 which correspond to those of C.
 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C# cod=

Valid point. You could also say that debuggers for Java and C# exist,=20 and are in fact commonly available, so you can use existing debuggers. ;)=
 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

I'm sorry, but it's not in the language. Compliler doesn't do anything=20 with documentation. It's just that there is a standard tool for=20 documenting Java in source. We will also have one.
 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

That's unfair. Normal floating point is catastrophically different on all platforms in=20 Java. And consider that in D and C++, you can roll your own strict FP=20 implementation, and it will have a native syntax.
 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

Why "no"? What is it anyway? Given an array of class objects, they can=20 be covatiant... I think i misunderstand something.
 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

Under a yes/no table, it stays YES. ;) 1. You can determine fields. 2. You can determine implemented interfaces. Then cast and use. what do you think you need more? Steal other peoples code? Sorry, we're=20 in a compiled world. And that for a reason.
 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

Why is this relevant to performance? And the way it is in C++ is too limited... hardly much different than in = D. I was proposing the type interence type or operator. ;)
 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

Why "no" for D? It will be a standard library feature. For now, library=20 features don't count in this table.
 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

may come. But again, library features.
 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

We had it in DLI. It might make it back into official D. But again: this = is a pure library feature.
 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes

Also library features? I don't know.
 These points might help to choose, which language is the right one for =

 you have to do.

You cannot choose a right language by using a checklist. Else OCaml=20 would beat it all. Yes, it is a good language, but... So, i'd say better let this table help choose the language which we feel = is right. ;) -eye
Dec 21 2003
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Templates:
 Make a note about Java, that 1.5 will have generic types.

Not true. It will have partial generics, as will .NET, neither of which will support any type of generic programming other than type-safe containers. No TMP for either of these lumbering technologies ... :(
 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.

Quite wrong. JNI makes Java about the furthest removed C-family language from the underlying architecture. Even Sun's own books concede that JNI is an inefficienct technology, and advise large quantisation of functionality in implementing JNI calls.
Dec 21 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Some interesting points!


"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bs4jkq$rv4$1 digitaldaemon.com...
 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one.

java.util.Vector
 Now you could say it's
 part of the library not of the language, but where do you draw the line

 language and library in Java?

Vector is a container class, and has nothing to do with the [] array syntax of Java. [] arrays in Java are not resizeable. Vectors can only contain Objects, not ints, longs, etc. Where I drew the line is if a feature is part of the so-called core language or not, i.e. if it is built in to the semantics of the compiler. The reason for this is that one can build libraries that do just about anything, as Microsoft's COM libraries for doing virtual function calls in C demonstrate. But few would argue that virtual function polymorphism is a feature of C, even though those C COM techniques *do* work.
 Is java.lang.Object Part of the language or part
 of the library? All classes implicitly inherit from it, so I guess it is

 the language. But if the package java.lang.* is part of the language why

 java.util.*?

If the compiler translated [] syntax into references to java.lang.Vector (as it does specially for java.lang.String) I would give it a "yes".
 Associative arrays:
 Same as above.

Same as above <g>.
 Templates:
 Make a note about Java, that 1.5 will have generic types.

There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.
 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.

JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.
 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C# code?

Because some vendors specialize in making debuggers or specialized products that work with the debug output, different debuggers have different strengths and weaknesses, and being free to choose among them is better.
 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

I don't agree. Java's convention of putting documentation in the source code is just that, a convention, not a language feature. Similar things have been done with C, C++, Matthew has done it with D.
 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

In my opinion and in the opinion of people who write serious numerics code, Java's requirement that intermediate results get truncated to 64 bits is a bug, not a feature. I suspect that is why no other language does it <g>.
 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes
 C#: Yes
 Java: No

I missed that.
 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

Not sure what covariant arrays are.
 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

I intend to improve this in D, but as yet it is, as you say, very limited.
 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

Do you mean for function templates?
 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.
 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

Library routines. I agree that Java, for example, has a very strong and extensive library.
 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

Library.
 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes

Library.
 These points might help to choose, which language is the right one for the

 you have to do.

Comparing libraries is important for determining suitability to task, but is not the purpose of the table.
Dec 21 2003
next sibling parent reply Ian Johnston <Ian_member pathlink.com> writes:
In article <bs5el9$25qq$1 digitaldaemon.com>, Walter says...

[...]

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

Not sure what covariant arrays are.

As far as I know, this means the ability to treat an array of subclasses as if it were an array of superclasses: class B { /* ... */ } class D : B { /* ... */ } class X { void f(B[] ba) { /* ... */ } void g() { D[] d = new D[]; d.length = 1; d[0] = new D; f(d); } } I believe that Java does in fact support this. The difficulty is that it can open a hole in the type system; imagine for example, that f() above added a new B onto the end of the array. Then in g(), the assumption that each element of the array is a D (or subclass of D) is broken. This is explicitly banned in C++ - you would get a syntax error. C# gets around this by checking in array element assignment that the assigned object is indeed a subclass of the actual type of array elements. I am not sure how Java treats this problem, if such a check is made in the element assignment. Ian
Dec 22 2003
parent "Walter" <walter digitalmars.com> writes:
"Ian Johnston" <Ian_member pathlink.com> wrote in message
news:bs779c$2cto$1 digitaldaemon.com...
 In article <bs5el9$25qq$1 digitaldaemon.com>, Walter says...

 [...]

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

Not sure what covariant arrays are.

As far as I know, this means the ability to treat an array of subclasses

 if it were an array of superclasses:

 class B { /* ... */ }
 class D : B { /* ... */ }

 class X
 {
 void f(B[] ba) { /* ... */ }

 void g()
 {
 D[] d = new D[];
 d.length = 1;
 d[0] = new D;
 f(d);
 }
 }

Ok, I see.
 I believe that Java does in fact support this. The difficulty is that it
 can open a hole in the type system; imagine for example, that f() above
 added a new B onto the end of the array. Then in g(), the assumption that
 each element of the array is a D (or subclass of D) is broken.

Yes. I had it implemented in D for a while, and took it out for just that reason.
 This is
 explicitly banned in C++ - you would get a syntax error. C# gets
 around this by checking in array element assignment that the assigned

 is indeed a subclass of the actual type of array elements. I am not sure
 how Java treats this problem, if such a check is made in the element

A runtime check would be necessary.
Dec 22 2003
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
 java.util.ArrayList
is resizable. However it cant contain primitives.
Although you can use the wrapper classes(Integer,
Double, Float etc)

Phill.

"Walter" <walter digitalmars.com> wrote in message
news:bs5el9$25qq$1 digitaldaemon.com...
 Some interesting points!


 "Matthias Becker" <Matthias_member pathlink.com> wrote in message
 news:bs4jkq$rv4$1 digitaldaemon.com...
 Resizeable arrays:
 Java has resizeable arrays in java.util.* you have one.

java.util.Vector
 Now you could say it's
 part of the library not of the language, but where do you draw the line

 language and library in Java?

Vector is a container class, and has nothing to do with the [] array

 of Java. [] arrays in Java are not resizeable. Vectors can only contain
 Objects, not ints, longs, etc. Where I drew the line is if a feature is

 of the so-called core language or not, i.e. if it is built in to the
 semantics of the compiler. The reason for this is that one can build
 libraries that do just about anything, as Microsoft's COM libraries for
 doing virtual function calls in C demonstrate. But few would argue that
 virtual function polymorphism is a feature of C, even though those C COM
 techniques *do* work.

 Is java.lang.Object Part of the language or part
 of the library? All classes implicitly inherit from it, so I guess it is

 the language. But if the package java.lang.* is part of the language why

 java.util.*?

If the compiler translated [] syntax into references to java.lang.Vector

 it does specially for java.lang.String) I would give it a "yes".

 Associative arrays:
 Same as above.

Same as above <g>.
 Templates:
 Make a note about Java, that 1.5 will have generic types.

There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.
 Compatibility -> direct access to C:
 What about JNI? This should become a Yes.

JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.
 Compatiblity -> Use existing debuggers:
 Why should I want to use "existing" debuggers to debug Java oder C#


 Because some vendors specialize in making debuggers or specialized

 that work with the debug output, different debuggers have different
 strengths and weaknesses, and being free to choose among them is better.

 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

I don't agree. Java's convention of putting documentation in the source

 is just that, a convention, not a language feature. Similar things have

 done with C, C++, Matthew has done it with D.

 don't know where, maybe arrays, as there are your strong typedefs:
 system independet floatinpoint arithmetic:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes (strictfp)

In my opinion and in the opinion of people who write serious numerics

 Java's requirement that intermediate results get truncated to 64 bits is a
 bug, not a feature. I suspect that is why no other language does it <g>.

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes
 C#: Yes
 Java: No

I missed that.
 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: No

Not sure what covariant arrays are.
 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No
 C#: Yes
 Java: Yes

I intend to improve this in D, but as yet it is, as you say, very limited.
 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes
 C#: No
 Java: No

Do you mean for function templates?
 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes
 C#: Yes
 Java: Yes

This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.
 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

Library routines. I agree that Java, for example, has a very strong and extensive library.
 under Other:
 Object serialising:
 D: No
 C: No
 C++: No
 C#: No
 Java: Yes

Library.
 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No
 C#: Yes
 Java: Yes

Library.
 These points might help to choose, which language is the right one for


 task
 you have to do.

Comparing libraries is important for determining suitability to task, but

 not the purpose of the table.

Dec 24 2003
parent Andy Friesen <andy ikagames.com> writes:
Phill wrote:
  java.util.ArrayList
 is resizable. However it cant contain primitives.
 Although you can use the wrapper classes(Integer,
 Double, Float etc)
 
 Phill.

Right, but doing so is about as convenient as using multiple inheritance from C. :) -- andy
Dec 24 2003