C++, C# or Java.

[Dimitri Maziuk]

Roedy Green sez:
....

Java is scalable. If you out grow your server, your same code will
work on hundreds of much larger machines.

I don't think "scalable" means what you think it means.

Dima

 

[Scott Ellsworth]

Which one is best?

Java is slow but can be ran on every machine.

Actually, I find it quite fast, especially with the server VM. When
needed, you can link in C or C++ modules, or run other optimized goodies
via either System.exec or JNI. I did one project that linked to an
optimized LAPACK library over JNI, and got quite acceptable speed, but
that was partially because they were n^3 algorithms, so data size was
not a big issue.

C# kicks the crap out of MFC but can only be run on M$ platforms.

Unless you use the Mono project's subset of C# that runs on Linux and
MacOS X. Still, I tend to consider C# an MS-only language for now.

C++ is class but is harder work so ultimately makes you better.

C++ has a lot of classes, and it is harder work. I would argue whether
it ultimately makes you better. I did C++ for seven years, and enjoy
Java more. Still, it has its place, and is worth knowing.

If someone wanted to learn an oop based language which one would you
choose????

Remember - the language you learn will probably not be your only
language. You should expect to learn another one every few years, if
only to know whether it is worth getting good at.

I would probably learn either Java or Ruby, depending on what I wanted
to do. Java produces cross platform UIs, which Ruby currently does not.
I hear tell that there are projects to do Cocoa in Ruby, so I could
generate a native MacOS X UI in Ruby, at least in theory. Were I
working on a server, my 'ui' is HTML and AJAX, so it really comes down
to maturity and tool availability.

Scott

 

[zero]

zero coughed up:


And keeps you clear of many horrid notions that only impede learning,
(such as MI, operator overloading, pointer arithmetic, and doing your
own garbage collection.)

Personally I love operator overloading, and having more control over memory
usage. But especially operator overloading. I think Java has been growing
up with the generics (templates) in 1.5. Now if it had operator
overloading it would be completely matured.

Judge for yourself, what's more intuitive:

String s1 = "hello";
String s2 = "hello";

if(s1 != s2)
System.out.printf("%s != %s", hello, hello);

giving the output "hello != hello"

or:

string s1 = "hello";
string s2 = "hello";

if(s1 == s2)
printf("%s == %s", hello, hello);

giving "hello == hello"

 

[zero]

There seem to be four factors that account for the "slow" reputation,
in no particular order:

1. Poor programmers
2. Garbage collection
3. Memory/locality issues
4. Pure object model

What about the extra layer? Java has to be interpreted by the JVM, which
then passes it on to the OS. Or am I talking nonsense here?

 

[Thomas Hawtin]

Judge for yourself, what's more intuitive:

String s1 = "hello";
String s2 = "hello";

if(s1 != s2)
System.out.printf("%s != %s", hello, hello);

giving the output "hello != hello"

Only it doesn't.

If you know Java, then the use of the strange symbols == and != on
objects should tell you something distinctly unusual is going on.

Tom Hawtin

 

[zero]

Only it doesn't.

If you know Java, then the use of the strange symbols == and != on
objects should tell you something distinctly unusual is going on.

Tom Hawtin

Ok bad example, been too long since I've used Java for anything but basic
stuff. In the code fragment, change String to MyString. In C++ you won't
even have to change the assignments, and the comparison will be correct -
provided you code the MyString class correctly of course.

Point being, with operator overloading you can use == (or any other
operator) on any object and actually compare the objects the way you want
them to be compared.

 

[Roedy Green]

Judge for yourself, what's more intuitive:

The catch is that with so few operators to overload even Stroustrup
overloaded << for i/o.

 

[Roedy Green]

What about the extra layer? Java has to be interpreted by the JVM, which
then passes it on to the OS. Or am I talking nonsense here?

You are a bit behind the times. JITting and AOTing has been going on
since the 90s. Interpreting is only for tiny machines.

See http://mindprod.com/jgloss/compiler.html
for the various ways java is run.

 

[Roedy Green]

I think 2 gigs also happens to be a limit on the amount of RAM that can
be access by most 32 bit architectures, so we could say at that point, it
becomes a "hardware" issue rather than a "Can your language do this?" issue.

Java runs on 64 bit architectures as well. Further you could simulate
a 64 bit address space on a 32 bit machine using multiple memory
mapped backup files. The crucial limit is the size of int.

BBL/Abundance was written in the DOS days of 16 bit addressing and
registers. It simulates a 32 bit address space and 32 bit stack with
some 64 bit operations. You could do the same sort of thing today
with Java if you wanted. There is no limit on address space in the
Java language. I don't think it will happen given the availability of
64 bit processors.

 

[Roedy Green]

I don't think "scalable" means what you think it means.

I think it means you can handle much larger loads simply by increasing
the speed and capacity of the hardware, or the number of cpus, or
expense of the container software and database engine, without a
fundamental rewrite of the code.

What do you think it means?

 

[zero]

You are a bit behind the times. JITting and AOTing has been going on
since the 90s. Interpreting is only for tiny machines.

See http://mindprod.com/jgloss/compiler.html
for the various ways java is run.

Aha, didn't know that. Interesting read, thanks. That does explain why,
when running a newly compiled program, it takes a while before it kicks in.

 

[Chris Smith]

What about the extra layer? Java has to be interpreted by the JVM, which
then passes it on to the OS. Or am I talking nonsense here?

Not nonsense, but I don't think that really makes the top five. Having
done some performance tuning on a JVM in the past, I find that a
decently intelligent JIT compiler contributes nothing but signal noise
after the initial startup time for the VM is done. It does have
indirect effects (the extra space and occasional use worsens cache
locality, for example). Interpreting in the naive sense is only done
for bits of code that are rarely executed, and the interpreter (versus
the JIT compiler) has negligible impact on performance.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

Aha, didn't know that. Interesting read, thanks. That does explain why,
when running a newly compiled program, it takes a while before it kicks in.

Yes, and also the initial program load of some many classes and the
initial set up. The effect is even stronger with -server which trades
start up time for eventual run speed.

I have been trying to talk Sun into gespenstering Java.exe so it can
come up instantly with a large number of standard classes preloaded,
and maybe even the app too.

see http://mindprod.com/projects/gespenster.html

 

[Thomas G. Marshall]

zero coughed up:

Ok bad example, been too long since I've used Java for anything but
basic stuff. In the code fragment, change String to MyString. In
C++ you won't even have to change the assignments, and the comparison
will be correct - provided you code the MyString class correctly of
course.

Point being, with operator overloading you can use == (or any other
operator) on any object and actually compare the objects the way you
want them to be compared.

Of course. And you're missing the point. Just because a language has a
certain feature/functionality doesn't mean that it is a good thing to have!

This topic has been discussed at enormous length and too many times.

 

[Thomas Hawtin]

The catch is that with so few operators to overload even Stroustrup
overloaded << for i/o.

I think it's better to look at it that C++ overloads the stream
operators for obscure bit shifting operations.

The fact that C++ is derived from (K&R) C is historical baggage. C99 and
C++0x are heading in divergent directions.

Tom Hawtin

 

[Roedy Green]

Of course. And you're missing the point. Just because a language has a
certain feature/functionality doesn't mean that it is a good thing to have!

This topic has been discussed at enormous length and too many times.

The problem boils down to this . The advantages for me to use the
feature correctly are overwhelmed by the disadvantages of others using
the feature to write obscure code.

I would go for user-defined operators, but no overloading of the
primitives. If you want an additive operator, use one of the many
possible Unicode symbols. Hands off +. It has too many meanings
already.

 

[Wibble]

Not nonsense, but I don't think that really makes the top five. Having
done some performance tuning on a JVM in the past, I find that a
decently intelligent JIT compiler contributes nothing but signal noise
after the initial startup time for the VM is done. It does have
indirect effects (the extra space and occasional use worsens cache
locality, for example). Interpreting in the naive sense is only done
for bits of code that are rarely executed, and the interpreter (versus
the JIT compiler) has negligible impact on performance.

A main point of slowness is that everything in Java is on the heap. C++
works really hard to let you put things on the stack so that nothing has
to be malloc'ed or released and its generally faster to reference the stack.

Java also has to do index checking on array access except under some
optimizations with limitted applicability.

Neither of these can be JIT'ed away, or at least not currently.

C# lets you do some more stack tricks but the compiler sucks enough that
its still really slow.

 

[Thomas Hawtin]

A main point of slowness is that everything in Java is on the heap. C++
works really hard to let you put things on the stack so that nothing has
to be malloc'ed or released and its generally faster to reference the
stack.

The result of C++ generosity is to make the programmer work really hard...

Java also has to do index checking on array access except under some
optimizations with limitted applicability.

Neither of these can be JIT'ed away, or at least not currently.

I believe JRockit does those optimisations to some extent. Escape
analysis seems to be moving into Mustang (Java SE 6). Even so, we're not
talking huge gains here.

Tom Hawtin

 

[Roedy Green]

A main point of slowness is that everything in Java is on the heap.

AOT compilers put some Java objects on the stack. This happens
automatically. In C++ you manually make the decision which objects are
allocated on the stack.

 

[Brendan Guild]

Chris Smith wrote in

Because Java's microbenchmark improvements have come at the cost of
memory usage, Java processes are often larger than native processes.
They maintain two copies of a lot of the code (native and bytecode),
and they lack the use of shared libraries so that memory becomes even
more scarce when multiple virtual machines are running. They also
maintain a lot more information at runtime than a typical C or C++
application, for the purpose of providing powerful features like OO
dynamic linking/loading and reflection. The result is a higher
likelihood of paging and of cache misses, both of which slow things
down.

How big of an issue is reflection in all of that? I never use reflection
and I've often thought it seems like an awful waste to have it available
all the time and use it only rarely. I imagine that classes would be a
lot smaller in memory without it.

Is there some way to eliminate the cost of reflection when it's not
wanted?