To the original poster:
1. You build your statement on a false assumption that languages are only tools. Computer languages are not tools. Compilers, debuggers, IDEs, editors are tools. Language is a different kind of beast - because language becomes part of the project you build with it. Language is more like building material, not tool. It affects lots more aspects than your tools. It affects not only the toolchain, but also the required skills of the coders on your team, the architecture of the application, available sets of libraries etc. It is like the whole building technology. Building from bricks is much different than building from concrete frame H.
|So when should I use java: If this wasnt an impartial article I'd say never and leave it at that. BUT this is supposed to be neutral so Java is great for server based applications, as well as client based web apps. It's fast and great with databases, while at the same time having some over head. |
This is a pile of unjustified FUD. There is no such thing like inherent "overhead of Java". Java is slower at doing some things than C++, C++ is also slower at doing some other things than Java.
My biggest problem with java is it's not that great of a language, in fact it's pretty bad. But thats what people get for trying to turn a language designed to teach students computer science and OOP into an industry standard. It was never meant to be what it is today.
Even more FUD. Java as a language has some defficiencies (like primitive types and boxing or generic type erasure), but:
a) these deficiencies are not severe enough to justify writing a book "Exceptional Java" or "Java FQA" like we have "Exceptional C++" or "C++ FQA"
b) it was designed to be a simple language, not an unstructured, unorthogonal feature-bag like C++
c) it was designed to fix problems of C++ as an application programming language, and although it does not fix all the things it could do, it does enough well that most application programming moved from C++ to Java (or C# - a MS Java ripoff ).
how bout functional paradigm languages like F#: you want to use languages that are functional when you need more platform independence. Functional languages make it easier to process your algorithm, method, function, etc independent of thread of CPU. It's great for multiple platforms, and multiple threading. This is also why scala excels at these things
First learn functional programming, then make verdicts on it, not the other way round. Functional style has nothing to do with platform independence or multithreading. These are just features you get "by the way". The whole thing is about handling **state**. Actually also the different treating of state is what differentiates OOP from structural paradigms, and not presence/absence of inheritance and virtual calls (contrary to what many programmers think).
So anyone who tells you "use java/C#/Scala/etc for you're Kernel/game engine/generic time and resource critical application" because they think you'll get it done faster, and thus make more money because of it, knows nothing about computer science nor economics.
We build EDA software engine in Java/Scala. This is extremely time and resource critical thing, involving lots of numerical computations. Somehow our prototype outperforms PSPICE written in... pure C. Why? Because we could used more complex, better algorithms, based on symbolic manipulation (which is pretty hard to do in C). The raw performance of our matrix inversion algorithm is probably lower than that of PSPICE, but for circuits that PSPICE builds a matrix 10x10, our software has to solve a matrix of size 2x2 - which is an order of magnitude faster. :P