My office runs on a hodgepodge of Visual Basic, Python, C, and FoxPro. Since we’re a small company with few programmers, this hasn’t been a problem. Each of us simply chose the language that best met our needs for a given project. However, the seemingly exponential growth in the size of those projects, plus the addition of a few new programmers, means that our idyllic little world is coming to an end. We need to standardize on a common development platform before the proliferation of languages and framework libraries makes progress impossible.
So, the obvious next step is to pick a system that we can all live with, even if it’s not our favorite. I’ve been advocating Python, but my coworkers don’t seem entirely sold on the idea. We’ve summarily rejected FoxPro for reasons too numerous to list. We tossed Java around, but its old reputation of slowness still carries a stigma among the powers that be.
Our final remaining option was .NET. Although it first appeared like an ideal solution—cross platform, free of charge, and the heir apparent for Microsoft-based development—we decided against it for reasons I don’t mind listing.
First, despite the content-free hype of a few years ago, .NET is basically a Java clone. That is, it includes a virtual machine, some languages that compile into bytecode that runs on that virtual machine, and an extensive library of classes to accomplish various tasks. The biggest single difference between Java and .NET is that Sun wrote the former and Microsoft wrote the latter.
The second biggest difference is that while Java is truly cross-platform, .NET tries to be but falls short in important areas. The most glaring example is that the Windows.Forms class (which is used for almost all .NET GUI development) is only available on Windows itself. In other words, forget writing graphical programs that run on Linux, FreeBSD, or Mac OS X. Although a replacement of that class is being developed for Mono, the free software implementation of .NET, such code treads upon a software patent minefield. You see, although Microsoft explicitly granted permission to the Mono team to their patented methods to write the core language itself, all the nice extras you’d actually want to use are still firmly locked in Microsoft’s patent portfolio.
Next is the fact that .NET brings little new to the table. It’s certainly no more cross platform than other popular languages like Java or Python. It’s class library doesn’t compare in extent with Java’s enormous depth and breadth. It doesn’t cost less, it’s not more popular, and it doesn’t work any better than its competition. Unless you want to develop Windows-only projects, it offers few or no clear advantages over other languages.
Despite all that, .NET and its associated languages, like Visual Basic .NET and C#, aren’t inherently bad. They’re pleasant to use by all accounts, and generally well regarded. The danger behind adopting them, though, is that .NET is inherently single-vendor and its continued existence and development is solely at Microsoft’s whim. Should they decide that its return on investment is too low, that’s effectively the end of it. Think that will never happen? Ask the legions of Visual Basic 6 and FoxPro developers how unlikely that is.
My boss trusts me to make decisions in his company’s best interest. Despite the advertising and breathless endorsements from IT management magazine, there are just not enough compelling reasons for me to recommend .NET technology over the other established alternatives. The approach we’ll probably take instead is to build a core library in a common language, then use connector technologies like SOAP and COM (on Windows) to access it from projects written in other languages.
And if that fails, there’s always Lisp.
Comments
.Net - Author Does Not Understand .Net's Purpose!
It appears Kirk does not understand that Java and .Net have two opposite/unrelated goals.
.Net is a framework designed for one purpose: allowing programmers to code the same Windows project using any popular language of their choosing. For example, it does not matter that Kirk prefers using Python and his coworker prefers C++ for working on the same Windows project. They each can use what they want and .Net will assemble the variety of code into working code. .Net's goals do not involve generating cross-platform code - it is solely focused on allowing a wide variety of languages to compile together to generate Windows code. Does .Net accomplish this goal? Absolutely.
Java, on the other hand, has a completely different goal. Java's main goal is to code cross-platform. Does Java accomplish this goal? Absolutely.
How is it that so many smart and experienced programmers just don't understand or know the purpose of .Net? Maybe its just anti-Microsoft bias.
In sum, comparing .Net to Java is analogous to comparing apples to oranges. A more valid/interesting comparison is to examine the pros and cons of Java vs. C#, or Java vs. C++. But of course, the results of such comparrisons depend on the project.
Author understands it quite well
I'm sure they have many orthogonal goals, but that doesn't address the ends they do share. kfrench does not understand that goals and other irrelevant issues aside, .NET and Java are nearly identical animals. Both are intended to be cross-platform - unless you thought Microsoft submitted all those documents to ECMA just for giggles. Both VMs support multiple non-"native" languages - compare Jython for Java and IronPython for .NET.
Sure, there are minor differences here and there, but it's misleading to claim that they're inherently divergent.
Python is more cross-platform than either
In my experience, if you can rely on pure-python packages to do most of your work , and make reasonable choices for GUI toolkits, etc, Python is a better bet for cross-platform ability.
I develop exclusively on Linux, but my Python code seems to run without effort on FreeBSD, Windows, Mac, and I've even heard a report from a user using an embedded system. I never gave any serious consideration to the cross-platform issue. I just write stuff, and it seems to be portable merely by virtue of being in Python. Admittedly, I'm not seriously pushing the envelope -- I've mostly written Zope product code and some less demanding non-GUI stuff.
There are obvious limits of course -- some GUI toolkits aren't cross platform, and all are written in a lower-level language.
That's true of Java too, though. You have to stick to pure-Java stuff if you want the cross-platform advantages, and that often means slow, rather unresponsive GUIs, and so on.
The real problem with Java, of course, is that the end-user must install the JRE. Usually, they have to do this themselves because Sun's peculiar licensing has made it awkward for free software OSs to bundle it (they've recently made improvements, but from what I've heard, it's still an issue and Java is just about 50/50 on being kicked right back out of Debian 'non-free'. Nevermind about its chances of getting into 'main').
Of course, Sun may finally come clean and release all of Java under a free license, but after all this time, do you really want to go with Sun? What about all that effort on Kaffe and the other free Java/JRE clones? And even if Sun does become the standard, there's still all those others out there.
Sun's "write once, run anywhere" marketing promise is badly implemented, simply because of the decision to keep the source proprietary. If they'd just gone the ISO route instead, they'd be ahead of the game, and Java probably would've swept the field. Instead, it's limped along as a "language only pointed-haired-bosses like", failing to take the lead away from C++ (which really deserves to be toppled). Community-derived languages like Perl, Python, and Ruby are filling the niche instead.
So at this point, Java's looking pretty limited. Sure there are lots of libraries, but most are proprietary and there is lots of duplication of function. There's more scope to the libraries available for Perl or Python, and the bulk of them are free software, so they become the standards. Sure Java is still the suit-programmer favorite, because the PHBs like it, as mentioned above. But that's measuring the marketing, not the product.
The biggest problem with Java is that its ideas are outmoded. The Java language is too heavily rooted in the classical object-oriented paradigm and the so-called "bondage and discipline" approach to programming. The result is bloated, oversized and under-flexible code, resulting in less code reuse and more re-writing of the same old ideas (of course, that's a plus if you're paid by the hour). This means that Java is both too low-level (like C++) and too highly-interpreted (means "slow"), so that it's really a "worst of both worlds" language).
Python has the "slow" problem, but it makes up for it by being a "very high level language" and therefore really, really rapid to develop in. Like Java, it has a strong OOP focus, but without all the baggage.
ISTM that Java's opportunity came and went: Sun missed it because they didn't open the code and set the standard.
If I were you, I'd stick to my guns and advocate Python -- or at least a free software platform. Single vendor is bad, bad, bad.
Hmm
Your analysis echoes the rest of your opinons: pretty short sighted.
Not sure how a free software zealot like yourself wouldn't include ruby on your short list. Duh. Mention a functional language though, get some of your street cred back.
In the end, it's all the same crap. Execution is everything and you can build perfectly useful, maintainable applications in very nearly any technology.
Most folks would actually get more done if they had less technology religion in their lives, *either* direction, mind you.
Python's a great choice for certain types of application needs. A nice ws tier written in ruby or python seems like a good choice, WinForms would make wiring up to this tier easier than pie for GUIs, you can use rails or django for web presentation tiers.
The weakness I see imposed by your blinders is that building a disconected smart client to consume ws is orders of magnitude easier using WinForms. Go do it in python + widgets, but you owe it to your boss to quantify how much more he's paying for that specific choice. Unless you're just paying lipservice to his trust.
Additionally, your characterization of the CLR == JVM is a fairly large oversimplification. Likewise, you've glossed over the entire IL->JIT/NGen->native compilation cycle when saying both "compile into bytecode". It gets worse when you go on to refer to IronPython as non-"native" (it's not, the CLR is language agnostic, maybe read some of the ECMA docs?). Frankly, I read this and I see "small-time developer/zealot has an opinion" but I can't put much weight on it because you don't even go into a cogent analysis of the oss options, let along the fact that you don't seem informed enough about the non-oss to make decisions I would view as informed.
I'd rather see your team use shell scripts, it would give me something to laugh about regularly.
Purely pragmatic
I haven't used Ruby. Nothing personal against it; I just haven't had the time.
We use Zope extensively already, so we'd probably take advantage of that codebase rather than starting over with RoR (especially since no one here already knows Ruby).
We've actually considered using XUL, either via XULRunner or inside Firefox/Mozilla for frontend client development, or possibly even good ol' HTML. I'd have to say the latter looks far more interesting for its maintenance benefits - clients are only a page reload away from seeing a new interface at any given time - but it's still an open issue. We could even use VB.NET or similar, as long as it were constrained to the interface and our core infrastructure didn't depend on it.
IronPython is non-"native" in the sense that it doesn't ship with Visual Studio. No more, no less.
We're simply not very interested in the non-OSS options. We have too much at stake to risk our business logic on someone else's convenience. We know they exist, and we have plenty of people in-house who are familiar with a variety of them (VB.NET, C#, etc. included). It's just that we've made the conscious decision to retain control over our own codebase, and OSS lets us do that. I'm not sure why you paint that as a "religious" decision when it was based solely on practical issues.