Christopher Smith wrote:
You described Java. :D
Not really. He described something more like Lisp or Erlang that is compiled down to machine code and has an FFI.
Java lacks from that list: 1) overloaded operators
I'm torn. On one hand they are sometimes useful. On the other hand, unless you have actual access to the abstract syntax tree, they tend to be suboptimal.
See the discussions about why you should *NEVER* overload && and || in C++.
2) access to platform specific features (yes, you can use JNI but at that point you aren't using Java)
Agreed. Java should have a better FFI. I should not have to create a thin C layer to get from Java to C. I should be able to do that completely in Java.
3) destructors, and lexically scoped resource management in general
Sorry. Unless you are doing embedded software, this is bad. It is the source of 80+% of all bugs in C/C++ programs.
I might concede this if you threw around a lot of sockets. However, I tend to throw around a lot of sockets in Java and have yet to bump into a time when I ran into a limit because the garbage collection wasn't efficient enough.
Garbage collection is good. Try it ... you'll like it ... ;)
4) multiple inheritence
Toss-up. I find that the more programming experience I get, the less I use inheritance, period. IsA generally isn't.
I have the same opinion about the Collections interface in Java. I use the concrete interface rather than the Collection interface. Use the richest interface that makes sense.
I do find the fact that I can't create a default action for interfaces in Java to be annoying.
5) fairly well defined performance costs
Unless you are in embedded, I find this to be a red herring. In fact, the last couple of Java programs I wrote outperformed their C++ counterparts by a good margin. The memory allocator in Java 1.5 is quite good and does a nice job of balancing against small vs. big objects and maintaining memory pools. If malloc() matters, Java is going to kick C/C++ all over the room.
Most programmers are not that good at manually managing resources.
On top of that, it's support for generic programming is limited enough that it's hard to use it effectively outside the context of collections.
That I might agree with. However, have the new generics in 1.5 addressed this for you?
The only problem I have is that generics are the tip of the dark side that leads to templates. The hacks to make them work have started.
-a -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
