Why Java Will Always Be Suitable For Enterprise Development

You need to wake up and stop uttering ignorant clichés about .NET being only for drag and drop development. In case you haven't been bitten by it yet, .NET is eating away at Java in enterprises of all sizes. As the article says, .NET is considered by many/most enterprises to be more productive. That may not be correct, but it is still a perception problem. Deal with it instead of dismissing it.

The big deal with C# compared to Java is LINQ (to objects, to databases, to webservices, to anything), reified generics, automatic resource management, generators and (not least) much better support for tooling/codegen through partial classes/methods etc.

With C# 4 and VB10 .NET gained native support for dynamic typing. This improves interop with dynamic languages considerable, but perhaps more importantly it allows meta programming and dynamic DOM oriented programming like what you find in Ruby and Python.

The gap is set to widen considerably with C# 5 which will have new in-language support for asynchronous programming. One application of this is parallel programming where developers can still write loops, conditionals (if-else), throw and catch exceptions etc. across asynchronous continuations. The point is that you can convert an existing algorithm to async model with minimal effort. C# 5 will probably be released before Java 8 (late 2012). Java 8 will have a form of semi-closures. Yay!

These are all distinguishing factors which can make C# much more productive than Java. LINQ certainly is a big deal. It also makes C# more complex, so maybe C# will crumble under it own weight at some point. But for now the perception is that C#/.NET is much more productive than Java. And perception is important when decisions are made.

These are all distinguishing factors which can make C# much more productive than Java. LINQ certainly is a big deal. It also makes C# more complex, so maybe C# will crumble under it own weight at some point. But for now the perception is that C#/.NET is much more productive than Java. And perception is important when decisions are made.

Certainly LINQ is a very "sexy" feature.  Trouble is, the complexity often isn't worth it.  I was working on a market data system the other day, where the back end was written in Java.  We implemented the full query language in less than 10 classes (and, or, operators, bitemporality).

Anyway, they needed to be able to post-process the points returned from the back end in C# also. They wrote a LINQ provider and used expression trees.  The end result was over 5x the amount of code *and* the queries were uglier because the data we are mining doesn't have a fixed set of domain objects.  Yuck.

As for C# eating up Java's enterprise space, that's partially true, but it's not the whole story.  I've written a major server-side app in C# recently and it was a decent experience, but Java wins out still on the tunability of the VM, the maturity of the open source stuff in the space and far better caching options.  In practice, I felt the extra language features of C# really didn't impact the productivity too much.

And interestingly, the C# server system that I wrote at one point had to interface to XSLT2. We used the enterprise version of Saxonica (superb BTW) and curiously, we started getting Java stack traces out of it. Turns out they converted it to .Net using KVM and its libraries.  Basically, the .Net space is still playing major catch up on the enterprise libraries and will be for some time.

Finally, when we deployed the C# server side app, we at one point wanted to run it on bigger hardware. The bank only supported Linux on these, which would have been fine with Java. So, in the server space, the lack of platform options really does bite.

OO, was supposed to save us from the dreaded spaghetti code c could become, but the side effects inherent in imperative coding means that in Enterprise development, you see tonnes of crap code, that no one would EVER reuse. Everyone, if you want to elevate yourselves to real power, simply learn to use Clojure, who's power comes from being a Lisp dialect.

• Read this article: http://www.paulgraham.com/icad.html, to get a better understanding on the matter.
• Run Ubuntu, as your primary desktop/laptop OS,
• Yes, go back and work with Emacs.
• Go to this site to learn how to setup your Clojure system: http://riddell.us/ClojureSwankLeiningenWithEmacsOnLinux.html
• Learn how to program in Clojure from this site: http://java.ociweb.com/mark/clojure/article.html
• Here is my after install Ubuntu apt-get, that gets me most of the way too...works on Ubuntu 10.04: sudo apt-get install compiz compizconfig-settings-manager compiz-fusion-plugins-extra simple-ccsm sun-java6-jdk gnome-do gnome-do-plugins texlive-full emacs clisp slime latexdiff git-core git-gui gitosis gitweb ant maven2 pidgin meld apache2 auctex libtiff-tools openoffice.org transmission cups-pdf gimp xmlcopyeditor shutter

Do you any concrete evidence to back up this ridiculous claim?

I do, for Indian developers. But there are 2 reasons for having higher percentage of horrible developers:
1) Culture and caste system(witch is actually in full effect still) in india forces more people that don't like software development to be developers.
2) Little or no options of getting a good and stable job outside of IT related fields.

 As a result of the above 2 points, you get apathy and no interrest in professional development. In wealthier countries people can(and do) change their speciality and profession and still get a descent salary, in India that is not an option.

So yeah, based on that logic and personal experience there is a higher ration of horrible developers in India than in Europe and Americas.

Good article, James. Generally, I think people tend to deal way too much with questions like that. I mean, why bother? .NET is an interesting platform and surely has a bunch of features worth eventually being adopted, and, vice versa, Java as a platform, community, ecosystem has a bunch of advantages over .NET. From a technological point of view, I would consider this discussion pretty next to useless.

 But there's one valid point about it, nevertheless: Productivity of developers. I guess the original author has a valid point here, but to me, the solution here is not about creating new tools to quickly write more code, but rather to build more tools in order to do more development work rather than "just" writing code. In order to get a (business) problem solved and, thus, provide value to your customer, your company (and, subsequently, be "productive" from an economic point of view), maybe you generally want to work as "high-level" as possible, you eventually want to cut down the amount of boilerplate code and configuration files to be written, and you might want to drastically reduce all effort spent on bothering how and where to fit a piece of code into an existing application infrastructure. From that point of view, I think Eclipse people are on a track not completely wrong by providing a vast range of tools, frameworks, technologies to not just support writing code but to support software modeling. Maybe this is a way way more promising than any other "language" or "platform" dispute...