.NET & Bioinformatics

Eric Snowdeal recently posted an article about the use of .NET in bioinformatics, which is something that got me thinking. I used Visual Basic .NET a year or two ago to code up the front end to a simplified LIMS (every bioinformatician has to code at least one LIMS in their lifetime) and it was actually quite a pleasant experience. I chose Visual Basic, incidentally, because FOR...NEXT loops bring me back to halcyon days spent writing half-assed text adventures and trying to hack Granny's Garden to print out rude words.

(quick disclaimer: in theory .NET is platform independent and lots of different programming languages can use it. In reality when most people talk about .NET what they mean is Microsoft's implementation on Windows and one of their big three 'Visual' programming languages - Visual C++, Visual Basic and Visual C#. I'm no exception)

In case you haven't really been paying much attention to Windows programming, .NET is a strategy around which Microsoft has been busy recasting its APIs, programming languages and operating systems. Their web page about it has all the marketing crapola that you might expect but .NET basically boils down to: you write programs made up of components that can talk to one another, even over the network.

The .NET framework contains a lot of nice classes that handle XML and connecting to databases, and something like connecting to a web service and printing out a result is actually pretty simple. Visual Studio is the rapid application development (RAD) / code editor that comes with all of the Microsoft programming languages, and it makes designing graphical user interfaces quick and easy.

In the Sys-Con article that Eric links to (server was down when I last checked, Google cache version here though) the author - Christopher Frenz - anticipates a growing need for Windows desktop based bioinformatics applications and suggests that an open source library similar to Bioperl would help .NET programmers meet this need.

I can see an argument that for bioinformatics programs to be more widely used they have to be accessible, and "double click on setup.exe then run the program" is, I guess, a lot more accessible than installing ActiveState Perl and tackling the command line. It's also more inuitive and familiar for most users to press buttons and tick checkboxes than to write command line arguments.

But all that is window dressing (perhaps very useful window dressing, but none the less). I don't see any advantage in using .NET behind the scenes to do any actual analysis or data munging, while there are certainly obvious disadvantages: i.e. Perl, Python and Java are free, already have widespread support in the bioinformatics community and will run almost anywhere.

Why not keep the computation seperate from the presentation and leverage .NET's other strength - its compartmentalized, web service friendly architecture - to access existing scripts written in a more bioinformatician friendly language using SOAP? As an alternative or supplement to web based interfaces .NET applications have something to offer. Accessing a remote web service is literally a one line operation (well, one line after a few clicks). Adding buttons and text boxes is drag n' drop affair. User preferences can be stored in the registry rather than with a transient cookie.

Admittedly this relies on applications being suitable for web services. If there's a lot of computation involved maybe you don't want it all done on your server, especially if there's somebody at the other end of the connection blithely pressing the "Go" button again and again and wondering why nothing is happening...