OSNews

> Technically Java is flawed compared to .NET, before you
> disagree please read here.

Actually, you want to compare apples to apples, so you can compare Java to C# or "J2EE/J2ME/Open Source for Java/Proprietary frameworks for Java" to ".NET/Open Source for .NET/Proprietary frameworks for .NET".

Since you're talking about technical flaws in Java, I'm assuming that you're not talking about "J2EE/...." versus ".NET/....".

The Java philosophy (and the Python/PHP philosphy) is really just a refinement of the "Spirit of C" (See ISO/ANSI standard for description). Two key ideas things that pervade Java is "Keep the language small and simple." and "Provide only one way to do an operation.".

Another insight from C is that the library is far more important than the language, so Java (and Python/PHP) want to make learning the language simple so you can focus on using the library to make your life easy. "Write Once Run Anywhere" is core to building up a big library since it allows you to build up libraries that come from different platforms. Both C and Visual Basic are really poor languages compared to the alternatives. However, they had an enormous number of libraries so people were extremely productive. VB's libraries were so big because Microsoft made VB core to Windows. C had a huge library because C was core to Unix and POSIX and the libraries became more prevalent because of Unix's "Write Once Compile Anywhere (with a bit of tweaking)".

C#, OTOH, follows C++'s philosphy (and Perl's philosophy) which is "It's more important to make the language as powerful as possible than to have a lot of libraries. More doodads and syntactic sugar in the language cause more problems and more ambiguities and make the language harder to learn, but people are smart enough to limit themselves to the safe subset of the language that makes them the most productive".

I used to be very strongly in favour of the C++ swiss army-knife approach and was informally involved with the C++ standardization. I believe I have guru-level knowledge of C++. So what changed my opinion? Other people. It doesn't matter if it's trivial maintain and extend your own code indefinately. It doesn't matter how productive you are on your own. The simple fact is in the working world, you will be maintaining other people's code and you will be writing code that will be maintained by others. You will collaborate with others. If they don't understand the language as well as you do, you have two choices -- dumb down your programming style or spend (unpaid) time teaching them more about the language. I tried the mentoring route for a while, but the simple fact of the matter is, most people seem to be too busy to be mentored for longer than a few hours every few months. If you try to do anything advanced, it will cause your team mates problems because they won't understand (or worse, misunderstand) what the language features do. They can seriously butcher your code and make it unmaintainable.

The team members who are keen on learning (on their own or through being mentored) and make the time tend to overapply what they've learned. They use a feature of the language just because it's 'cool' or because they want to show off. This doodad-syndrome results in very unmaintainable and fragile code that even they can no longer maintain. Have you every tried to maintain bad C++? It can get really ugly (...especially on MS Windows. Have you seen C++ for .NET? There's no way I'll ever maintain someone's C++ for .NET code.).

So from my experience, when you're involved in teams, the best approach is to pick a good simple language with an adequate library that gives you room to grow and makes good design simple. It may sound bland and unsexy, but the teams I've been on have been most productive by using this simple rule. Java fits the bill most of the time. Python does also. PHP (with Fusebox) does also (if your team has Java or Python or good C++ experience or experience with some other OO language. There are no real gotchas in the language if you enable strict error checking, so it's possible to focus on simplicity of design -- which is much easier to enforce in a team with at least some minimal OO skills. If you don't have such a team, team-wise PHP coding can be a nightmare).

A very restricted subset of C#/C++ should also fit the bill, but without a way of enforcing the subset what tends to happen (in my experience) is that that subset gets larger and larger (because of something we have to do one time---"Honest") until you end up with a mess.