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.

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

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

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

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

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

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

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 for an environment allowing to write fast, lightweight applications conveniently.

And hey, don't forget, thís table is for advertising D, not Java! If you 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. 

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 syntactic, that is they only free of casts in Java. In static languages like C++, D, and Sather, generics also vastly improve execution 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 can directly call C code from lanuguages like C++, Delphi and D. And even Sather. This goes along with having constructs in the language which correspond to those of C.

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

Valid point. You could also say that debuggers for Java and C# exist, 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 with documentation. It's just that there is a standard tool for 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 Java. And consider that in D and C++, you can roll your own strict FP 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 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 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 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 the task
> you have to do.

You cannot choose a right language by using a checklist. Else OCaml 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

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

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