I’m a big supporter of teaching programming in schools. Initiatives like Code Club and tech like the Raspberry Pi shifting the emphasis in IT lessons from how to use software to the fundamentals of how that software is built has always made sense to me. Why teach kids to use a computer program that could be obsolete within a few years rather than teach them the fundamentals, setting them up to build their own software further down the line?

But a couple of things have made me have a harder think about this position recently.

Evolutionary lineage

A statement about my aforementioned stance on the subject of IT lessons at the Christmas lunch table led to the family tradition of a debate. My dad compared computing languages to evolutionary lineage. Just as I argued kids shouldn’t learn software that could become obsolete, he raised the idea that any programming language could find itself outside of an evolutionary lineage.

Have we taken a path with programming languages that now will not be diversified from? Are there any programming languages that are like alligator eyes, or the fact that we have two legs? Have they taken a certain path destined never to fundamentally change?

I’d suggest there’s a very strong argument with many languages that they are on a line like this, more than enough for them to take up a good few hours in a weekly school curriculum. HTML, for instance, is still evolving. But the possibilities of HTML5 show that this language is not going to go away for a good while yet.

However, a post I read today took the whole thought process another step.

The programmer toolbox

The evolution idea was more a contrary position that made me think a bit, the kind my dad likes to take in debates to force a bit of discussion. But Swedish designer Rasmus Andersson makes the point that the fundamentals of the programming languages we still use today are now over 50 years old, and argues that: 

“Our current toolbox for software creation has an inherent limitation at its very foundation: low bandwidth. One-dimensional, sequential text utilises only our sense of sight, and is interpreted by a small section of our brains, forming a “bridge” or “proxy” for meaning and expression.”

The way we interact with technology in every other area of our lives is constantly being simplified for us. When software (or even hardware) is built, a good engineer and design team will be concentrating on achieving something that has all of the functionality the user wants with the optimal ease of use. But what about the interface the software engineers have to work with themselves?

The argument Rasmus makes is that this is long overdue an overhaul. And I have to agree that there is a very good case for making programming easier, adding a simplifying layer in there somewhere between lines of code and the finished product. The strongest being the creativity this could enable. At the moment, being a software developer means being part creative and part engineer, the more ‘creative’ types tend to work on the front end, but they still need the capacity to deal with long strings of code and logic.

There are tools out there, the WYSWIG HTML editors and Adobe’s Creative Suite are among those for web development for example, but so much software development still requires a mathematical, logical, problem solving brain. This means that so many creative, artistic minds, minds that could create some of the most fantastic technology, are coming up against a very early barrier for entry because they don’t have the capacity to work with one dimensional lines of text.

So, the future of programming?

I’ve no idea what that all means for how the future of programming should look, but it is some great food for thought. I still don’t think we should be teaching kids to interact with front-end software, but we do need to think carefully about the languages we do teach to our children. Maybe one of them will build the software design and development platform of the future.