The English language is full of some wonderful words. One of my favourites is
triskaidekaphobia: an abnormal fear of the number thirteen
According to the grapevine, having recently completed Office 12 Microsoft are now in the envisioning stage for Office 14. 14? What happened to Office 13? Are those Redmond folk looking a long way in to the future or is this an example of corporate triskaidekaphobia?
del.ico.us | 
Digg It | 
Technorati | 
StumbleUpon | 
Furl | 
reddit
Last night I was installing some software on our servers and it got me round to thinking why I choose C# over Java. The software I was installing was some log file analysing software written in Perl - what on earth has that got to do with either C# or Java I hear you ask?! Hang on, let me explain....
When I have my consultant's hat on and people ask why I choose C#/.NET over Java, there are three primary reasons I give
- It's faster to develop code using C#/.NET. Our own empirical evidence suggests it is up to 20% quicker to develop an application in C# than it is to develop the same aplication in Java. This is mainly due to the expressive nature of C# and the range of functionality built in to the .NET framework.
- Platform integration. Most of the software I write targets the Windows platform in one variety or another. If your goal is writing software that will run solely on Windows then this really is a no-brainer. .NET provides significantly better integration with the Windows platform than Java does - period.
- Deployment. The .NET deployment story is the clincher in my book. Visual Studio is the de facto development environment for .NET applications and it provides several great options for deploying applications to desktop, server and mobile platforms, including MSI installer packages and Click Once. These capabilities are built right into the development environment and allow me to build sophisticated installation routines. We never use any third party installer software - Visual Studio and a great little library of routines for building custom actions (which I might shortly release under an Open Source licence) meets 99% of all our deployment needs. With this we can easily copy files to and configure all manner of aspects of the target machine, enabling us to provide a great automated installation experience for the user.
The Java deployment story is not so sweet. As well as file copying there's all manner of messing around with classpaths and other such nonsense and a whole bunch of additional configuration which is just plain harder to do and not natively supported by (my) Java develoment tools. If I want an nice automated installation experience for my Java application then I really do need to rely on third-party installers.
So what does all this have to do with Perl? The Perl application I was installing came with a two page document telling me how to install it - copy these files here, place this directory there, alter some environment variables, set up a scheduled task via the Control Panel, etc. This really was a manual install process requiring a good understanding of system administration and it reminded me very much of some of my deployment experiences back in the early days of Java. Admittedly I haven't used Java in anger for any application development for over three years now and things may have moved on from where they were when I last built Java applications, but I think my observations still apply.
Maybe I'm odd, but when I start on a new application one of the first things I build is the installer. I firmly believe that the installation process shouldn't be an afterthough and is a key part of the develoment cycle. Now if somebody could just come up with some sensible installation and configuration story for Perl and other scripting languages life would be so much easier.... preferably a free solution so that the developers of the great freeware/Open Source scripted applications out there could make use of it and make the installation process easier for their users.
del.ico.us | Digg It | Technorati | StumbleUpon | Furl | reddit