Programming in heaven ... and in hell

I'm currently writing a new A-level textbook on programming, and I'm writing it simultaneously for Python, VB, and C# - which is even more painful than it sounds! (BTW, each reader of the finished product will see only one of the three.) But it's also an educational process in itself. With each example I write, I am struck that it works better in one language than another – though different in each case. Sometimes the difference is small – the code is just a little more elegant and/or easier to read in one of the three languages. Other times the difference is startling.

I found my mind wandering back to a joke that I used to tell – back in the days when most people had a sense of humour – about the difference between heaven and hell. The joke now feels dated, even inappropriate, for multiple reasons - but it worked well last century:

Heaven is where the English are the policemen,
the French are the chefs,
the Germans are the engineers,
the Italians are the lovers,
and the Swiss organise everything.

Hell is where the English are the chefs,
the Germans are the policemen,
the French are the engineers,
the Swiss are the lovers,
and the Italians organise everything.

I started musing about a programming languages version of this joke. Not hard to write, but, at best, funny only to a rather narrow audience! More seriously, it would be quite easy to design a language that incorporated the best features of each of Python, VB, and C#, while eschewing the worst – and in a way that the supporters of each would recognise the roots in their own language. (No, it wouldn't look like 'pseudo code'.) Getting such a language implemented, and then adopted in schools, however, would obviously be a very different story.

There's also another reason not to attempt it. Because from an educational perspective all three languages belong in hell, for one specific reason, the same one for all three languages. And so does every other programming language I've used (I stopped counting some years ago) in my nearly 50 years of coding. The reason they all belong in hell is: error messages.

As I write the book, constant switching of languages causes me to make even more errors than I would normally. But in all three languages, many of the error messages are absolutely incomprehensible. I'm an experienced professional developer (well, in C#, anyway). How does a newbie cope with this? Nor are things getting better over time. Those of you teaching AQA A-level may recall your first experiments with Haskell. Absolutely wonderful language, when you get it right – but the error messages should send Haskell straight down to the ninth circle.

And let's be clear: just trying to write 'friendlier messages' isn't going to solve anything. Even when I do understand what the message means, they are often pointing at the wrong place in the code – the cause of the error lies elsewhere.

I find myself wanting to advice to pupils: 'Don't bother even trying to understand the error message, just recognise that there is an error and use [these techniques] to narrow down the cause…'

The most extraordinary thing is that this is all now unnecessary. It is perfectly feasible technically to now eliminate the possibility of coding errors. I am not talking about errors in your algorithm – called 'logic errors' in most textbooks, though I don't think that's a good term. I'm talking about errors that are recognised – whether at compile time or run time – by the language system. Not just syntax errors, token errors (names), and type errors, but null reference errors, range errors, division by zero errors.

The languages, or rather family of languages, that has most advanced the state of the art in this respect are the block-based languages such as Scratch. You can't create code that has syntax errors in Scratch – and that is a significant achievement. Some people argue that block-based languages will eventually displace text-based languages even in professional development contexts. I'm not sure about that:  the spatial overhead of the primary-coloured building blocks and the need to switch so frequently between the mouse and keyboard are not going to go down well there. Scratch and its cohort are also strongly oriented to procedural programming, and/or event driven programming - not (unless someone can tell me otherwise) modern, functional programming. There have been attempts to find hybrid models between blocks-based and text-based programming, but they haven't gotten very far.

However, it would be perfectly feasible to design a text editor that could work with any mainstream text-based programming language – that not only made it much easier to write error-free code (modern IDEs already do this increasingly) but made it impossible to enter code that would cause errors in the first place (or edit existing code that would result in an error). (Remember: I am talking all kinds of errors that are detected by the language system, not errors in your algorithm).

One of my hobbies is restoring, maintaining, and driving a pre-war car. Believe it or not, the only way to check the oil level is to open the bonnet, locate and pull out a metal stick, wipe it clean on a rag (or my handkerchief usually!), insert it again, pull it out, and look at where the oil is on the stick. I have a more modern car, too. It has multiple computers on board. And now to check the oil level I just need to … you've guessed it … open the bonnet, and …

Those of us interested in both the pedagogy and the supporting resources for teaching programming need to set our ambitions higher -  and address the issues that have simply been ignored for 50 years.

And, in case you're thinking 'AI' – what I'm describing doesn't need the faintest (malodorous, IMO) whiff of 'AI'. It's just plain old fashioned programming – the best kind. Not easy, but then nothing worth having is easy to acquire.

I hope to have a go at this myself, in the not too distant future. Meantime I have a book to finish writing, and a whole lot of software that goes with it. And that's not to mention the 'technical debt' accumulating on the car …