Right Tool, Right Job (?)
Any rational programmer will agree that different situations need different solutions. If you’re trying to write a blazing-fast and lightweight *nix process monitor, you wouldn’t use something like Ruby instead of C – Ruby’s just too slow. If you’re trying to write a tool which almost any programmer can easily read and modify, you wouldn’t use Haskell instead of Java – Haskell’s just too different. Up until now, I hadn’t even thought about the ‘right-tool-right-job’ tenet of my programming beliefs – but yesterday I did, and I came to a frightening conclusion.
Information technology is the fastest-changing industry in the world. New problems and solutions shift faster than you can blink; it’s almost every day I hear something about Nice or Groovy or some other language about which I know nothing. With such a massive shift of problems, solutions, and tools, it’s inevitable that some of them are going to be isolated.
Take XMLHttpRequest. (Please. *badum-shish*) Until Ajax came out, it was a solution in search of a problem; it’s pretty astounding to think that it took 6 years (XHR was developed by Microsoft in 2000) for such a brilliant solution to find a problem to solve. (The question of whether XHR is solving that problem, or if that problem actually exists, is another matter entirely.)
Now take Perl. Back in the early days of the web, it was indispensable – CGI was crucial for everything – and there was almost no other tool that could solve such a huge problem as how to glue together all the components that make up the Web. But now PHP, Python and Ruby have muscled in on the domain that Perl used to rule unchallenged; it seems as though this tool has lost its problem. If I were to develop a new, radical application Perl would be the last thing I’d choose – it’s old, not particularly fast, impossible to maintain, and Perl 6 is still far, far off.
What I’m saying is that if there’s one thing which your pet language does really well, then diversify. If, like Perl, you rest on your laurels, the problem you fix might be fixed by someone else. Sure, you should always pick the right tool for the right job – but if you’ve got a great tool which solves no problems, you’re never going to get anywhere.
I came to this conclusion after looking at REALBasic. Though I loathe everything that Basic and its progeny stand for (I have justification for this; I once had to write a 60-page tutorial on Microsoft Access & VB), I have to admit its crossplatform nature, especially for OS X widgets, is nearly flawless. After looking at the page, I mused on how much better Cocoa is than VB – and then it hit me like a lightning bolt:
What if REALBasic published something that could emulate the iLife window look?
How would new Mac programmers feel if they had to choose between a harder language /API that only works on Macs (yes, I know about GnuStep) and an easier language that works crossplatform and allows one to make slicker-looking applications than the other choice?
Yeah, there are fantastic third-party libraries that do the iLife thing for Cocoa, but what if REALBasic had it as part of the standard package?
Unless Apple gets their act together soon, their niche of native-looking, great application design might be invaded by REALBasic. Don’t let Cocoa fall into the trap of ‘good tool, no job’.
Entry filed under: code.