The old “best tool for the job” line.

A comment on this article by Ole Eichhorn about Longhorn, and how it's about making code easier to write and not necessarily about making code run better.

This is an issue I've thought about a fair bit over the last few months.  I like the idea of making my job easier, but most innovations to make development easier come at the expense of higher hardware requirements or poorer performance.

The StarChoice Navigo 305 set-top box that I have runs an Interactive Program Guide application that, I understand, is written in Java.  It's performance is terrible!  It takes a long time to bring up the guide to see what's on TV, something that I expect to be instantaneous.

But on the other hand, you can't expect every application to be written in hand-tuned assembler.  There's a tradeoff somewhere.  Higher level languages generally enable faster development at the expense of slower execution.

And the line at which something goes from ?too slow? to ?not too slow? keeps moving.  Years ago you couldn't write in C because it was ?too slow?, obviously those days are long gone.  Today, you can't really write an end user application for .NET without having to deal with the fact that it's going to take longer to start up, take more memory, and possibly run slower than a native application - but by the time Longhorn rolls around, this will likely not be an issue. 

On the other hand, ease of development can have a huge impact on the quality of product that a small company can deliver.  It's much easier to write a .NET app than a Win32 app. 

Developers should use the tool that will let them deliver a good quality product that meets their needs when it comes to performance, stability, maintainability and whatever other criteria they determine, with the lowest cost to them.  Lowest cost to them probably means quickest development time, which probably means that if Java or .NET can meet the other criteria, then it's the best tool for the job.  If it can't (as in the case of my crummy set top box), then it's not the best tool for the job.