Mashed Articles

Although I’m not a great programmer, I do enjoy programming. To be a great programmer I’d need more talent, a better understanding of maths and the time to work on code all day, every day. I barely manage to get a few hours a month to indulge and I have a hard time getting my head around generics, but I love the challenge.

It’s like the ultimate text adventure game, where there’s no set solution and only your own logic (or lack of it) to rely on. Results can feel quick and dirty, or refined and sublime. Either way, the satisfaction you get from seeing an idea through from a potential solution in your head to a prototype that works is difficult to beat.

I’m like the boy in the Big Ball of String book by Marion Holland: “I jumped into bed, with my string in a ball. With my string. With my string, I can do ANYTHING.” It makes me wish I’d left school at 16 to follow Andrew Braybrook and Mike Singleton into the bedroom programmer sunset before games companies started to need teams of 200 people and a budget bigger than Avatar’s.

But if you’d asked me 20 years ago what the average programming language would look like in 2011, I would have guessed at one feature that’s never going to appear. I’d expect application development to be as easy as using a word processor – perhaps easier. But it’s not, and in many ways it’s getting more complicated. If PCs were like programming languages, we’d still be looking at green screens and a text interface.

Languages just don’t seem to have adapted to the processing power revolution. Instead of becoming magnitudes easier to use, they seem to have become magnitudes more complex. The limited capacity of older machines meant there was only so much a compiler could squeeze into memory, whereas in the 21st century, while interpreted languages like JavaScript and Python can be very easy to use, extensions make them spiral quickly into complexity.

Programming now has more to do with the APIs and platform you’re using. Building a GTK application with Python doesn’t remove the complexity of GTK, it just makes it more terrifyingly accessible. That’s because it’s hard. Despite more people describing themselves as developers, from website creators to game designers, the average programming language still requires a good working knowledge of the syntax, a mastery of whatever APIs you need to use and the pragmatic ability to piece all these pieces together with the toolchain.

In many ways, Ada Lovelace had it easy. She may have had to wind the cogs of Babbage’s analytical engine herself, but she’d need only to memorise the syntax of three care types – operation, variable and memory, to convert her mathematical functions into steampunk. Less used to be more.

I spoke to Rob Pike recently. He was one of the original members of the Unix team at Bell Labs, and currently creates languages at Google. His latest language, Go, was designed to make programming concurrency as easy and as accessible because, I suppose, Google is made of server farms. The language is also open source and available for Linux, OS X and now Windows. With Go, you can spread the processing load of a task across different threads as easily as you can print characters to the screen, and it compiles in a fraction of the time a C project would.

It’s a language built for a specific niche, and Rob told me he thinks that’s why there’s no single, easy to use language or environment. There are just too many niches that require specific languages. That may be why there’s been a renaissance in languages like Ruby and Scheme, and not Visual Basic. Rob also said that he thought it was still vitally important that computer science students are still taught the fundamentals of logical programming like registers, pointers, addresses and memory allocation to be an effective programmer. I argued that it shouldn’t be necessary unless you’re a low-level hardware developer, but I now realise Rob is right.

Even today, to make your code as efficient as possible, you need to be aware of exactly the same low-level reasoning as you did 30 years ago. That’s not because you’ve only got 2kB of storage – it’s because your code is likely to be run millions of times a second, on multiple CPUs, as your application is accessed by the world through a website. Writing a string comparison function in assembler could save you billions of instructions, as well as heat and energy units. It seems that the revolution of semi-conductor design has been offset by the number of people who are using it. Performance breeds complexity.