EnglishChris Granger of LightTable fame has posted an insightful article on how better programming tools might come about.
He argues that ‘programming should be about solving problems‘ and that ideally ‘programming is our way of encoding thought such that the computer can help us with it‘ but along the way we – as programmers – somehow lost these notions and in our daily work we predominantly deal with marginal problems, problems which are incidental to the problem we were trying to solve in the first place. I suppose most software developers can relate to this idea: We consider ourselves to be designers, architects and problem-solvers while at the end of the day we’re mere plumbers. We write boilerplate code (or if we’re lucky enough we have an IDE write it for us) for connecting frameworks to interfaces and vice versa or as Chris so nicely puts it: We create ‘self licking ice cream cones‘.
I don’t want to reiterate his reasoning – you should read his article anyway – but his main points in my humble opinion are these:
- Programming is unobservable: Apart from clumsy debugging tools our programming efforts are for the most part unobservable. It’s code, compile, test, iterate … Programming today is still more or less a rigid, static discipline while it should be responsive and providing direct feedback.
- Programming is indirect: We’re mainly using string representations as symbols for programming. Why is there – more often than not – no iconic relation between the sequence of characters we use for coding and the concepts they encode? For instance, why is a summation operator usually represented as a for- or while-loop instead of concise mathematical notation? Incidentally, this particular argument is applicable the other way round, too: I still think that understanding that a summation operator is nothing else but a for-loop will get you through most ‘maths 101’ courses in university.
- The people’s programming: Programming should empower non-programmers to do what programming actually is about: ‘Programming is our way of encoding thought such that the computer can help us with it‘. As I mentioned in a previous article Microsoft Excel is a prime example of this since its results are observable, it’s direct and it hides concomitant complexity from the user. It achieves this feat by hiding complexity and making programming more palatable. This has garnered it a lot of disrespect from ‘real’ programmers but there’s no denying the fact it gets the job done to the extent that the world runs on Excel.