'Why Pascal is Not My Favourite Programming Language', revisited

I was having one of those conversations at work with someone who didn't want programming languages to "nanny" him. I am fully in favour of programming languages that nanny - most work ends up maintaining other people's code, other people are idiots (*), and anything that minimises the pain is a good thing - analysis tools, test suites, etc., and even just not having the language provide you with every conceivable option and say 'sure, I trust you'. There's a reason we don't use Perl for everything. I want languages to nanny people, especially the vast majority of the people who claim they don't need nannying, because they know better. Most don't.

(*) This isn't egocentric. It holds true for you, too. From your point of view, I'm an idiot. This is because everyone's an idiot, but because there are far more other people, and just one you, you notice other people more. And just perhaps, you have a bit of a blind spot to your own stupidity. Also, I'm being a little unfair. Most people are idiots all of the time, and some people are just idiots some of the time. Nonetheless, everyone generates bugs.

The proposed root of this person's view was that their first proper programming language was Pascal, and that nannied far too much. This reminds me of Kernighan's Why Pascal is Not My Favourite Language. Admittedly, the Pascal I learnt to program with was the legendary Turbo Pascal 5.5, which played more than a little fast and loose with the original Pascal constraints, so I wasn't bitten by limitations.

A number of points made in that paper are quite valid - not so much about nannying, but about poor language design - such as having a fixed array size as part of its type. On the nannying side, it enforces structured programming (no breaks or early returns, which do tend to bite), it lacks a macro processor (either used for defining constants, badly, or providing exciting ways to screw things up), and there's no way to cast pointers around to construct your own allocators, etc.

In the end, C beat Pascal handily, but at what cost? C is a great systems programming language, but it's still used even now for the most inappropriate tasks. On the one hand, the ability to cast pointers however you like and have no array bounds checking has lead to decades of security holes and nightmarish bugs. On the other, productivity is dire, as there's no way to really climb up the layers of abstraction. Manual memory management is error-prone, and efficient generic containers will just make you want to cry.

In comparison, some of those ideas in Pascal are somewhat prescient. Structured programming can help optimising assemblers. If you can't tweak and cast pointers any way you like, you have a hope of creating sandboxable programs, and a lack of aliasing may help vectorisation. A restricted language helps with all kinds of analysis. The mindset behind Pascal is effectively the mindset behind Java and C#. The modern C is C++, which is just epically twisted and nutty, and will actually positively encourage you to shoot your own foot off.

For most enterprise applications programming, Java or C# is the right choice. The Pascal side beats the C side. If you work in a large company with lots of other developers, where reliability and maintainability counts above micro-optimisation and being a unique snowflake, well, suck it up. And occasionally, just occasionally, a runtime binary patch is the correct solution, and you can run wild.

Posted 2013-07-11.