Thursday, May 25, 2006

Why do we write computer programs?

Ok, so beyond the core "because it's my job, and I get paid for it", I was thinking about why we write computer programs. (Yeah, ok, so "we" is used in a very loose sense).
The reason I could see was that they did something more efficiently that doing it by hand. Before you shout out "But I can write a letter with a pen and paper faster than I can load up Word and type it in", think about what the end result is. If you wanted the same output as Word produces, you'd have to either spend a long type with some old school type setting equipment, or learn to do caligraphy well. Neither would be faster than loading up Word and typing it in.
So, if programs are time saving devices, this puts them in the "tool" category. Sure, they're more complex than a hammer, but then they do more than a hammer does. (You could always go and look at the guys at 37signals, who think that computer programs should be a lot more focused). I digress...
Surely, then, we should be writing more computer programs, either to help us write computer programs, or to help us do something else that takes a long time.
An example of one of these programs is a SPAM filter - such as SPAMBayes. This has saved me loads of time in the past. Rather than having to spend hours (and I do mean hours - never publish your email address on the internet) trawling through emails, picking out the good ones, I set it up, show it some stuff that I already think is SPAM, and off it goes. Brilliant. Yes, it needs a little bit of help now and then, when my brother sends me a "forward this to 10,000,000 of your friends" email, but I think that's fair enough.
Back to the point - why is it so hard to write programs that automate existing programs? If you try programming any of the Office products using the macros, it gets really hard once you're past the "make this text bold" stage - mind you, getting the text to make bold in the first place is hard enough. Add to that the fact it forces you down the path of writing in a language which you might not be used to (VB sometimes makes me want to rip my own eyes out!), it leaves a bitter taste. Similarly, if you want to program Visual Studio.Net using macros, it's an uphill struggle, and some things that you think should be easy - such as finding out the function you're in, become very hard.
I suppose the problem here is that it's exposing the complexity of the underlying program. Sure, making a simpler wrapping on top of this would only increase the complexity, but when people like JetBrains (who write the amazing ReSharper) have to write their own C# parser, there's something very wrong.
Perhaps it'll get easier. Programming Google Maps is a doodle, once you get past the initial WTF. Similarly, programming Flickr is quite easy (especially if you use one of the already developed language specific libraries). As more and more programs/services expose APIs, perhaps we'll get better at writing them. Perhaps we'll need a common standard for APIs.
Anyway, this was going to be a rant about how, perhaps, we should be developing programs as though we were developing an API, and then write our front end on top of that. Certainly, that's not an original thought. But, perhaps, at the same time, we should be striving to write APIs that other people can use. Sure, there'll be a bit of learning to do for any API, but this should also be an understand of the problem domain, and the code behind the API should handle all the unnecessary detail.
I know I'm not there yet, but I'll keep on trying.

No comments: