Last Week on My Mac: Language wars

Even the coolest and least emotional of us can get emotive and irascible about their beliefs. In programming, this is most likely to happen over platforms (my Mac is better than your Windows/Linux) or languages. Such language wars are among the most bizarre of human behaviour, and watching some of these tirades of religious fervour on Twitter is amazing, to say the least.

I’m a bit of a language agnostic, or perhaps profligate would be more appropriate. Over the forty-odd years that I’ve been writing and running code, I’ve used Algol, Fortran, Basic, Pascal, Object Pascal, C, occam, various types of Assembler, Common Lisp, APL, Icon, LabVIEW G, HyperTalk, AppleScript, and most recently Swift, and picked up a smattering of many more. I’ve loved and hated them all at times, but none has ever seemed sufficiently ‘perfect’ to inspire religious feelings, nor so flawed that I am driven to berate anyone who dares use it.

My two biggest reasons for choosing a language are its support on the target platform, and its ability to express my code clearly.

Language support is critical, particularly on a Mac. When I first started commercial development for Macs, I was warned that I would have to learn Apple’s Object Pascal and its development environment, Macintosh Programmers’ Workshop (MPW). In those days, writing code for the Mac any other way was a tough and often frustrating choice. Then Apple drifted away before making Objective-C the benchmark for Mac OS X. As I had a suite of apps in Object Pascal for Classic Mac OS, those products were instantly orphaned.

Many of us thought Objective-C was a strange choice, forced on Apple as part of Mac OS X’s NeXT origins. I was far from enamoured with C++, but by anyone’s measure, Objective-C had (then) lost out to it as the successor to C – another language which I tried to avoid whenever I could.

When Apple announced Swift five years ago, it couldn’t have come at a better time for me. I was retiring from my day job, and hoping to focus my life more on development and painting. These have been early days for Swift, and over those five years it has changed greatly. It’s still a general-purpose multi-paradigm language, though, and lets the coder decide whether they want to write my sort of ploddingly transparent Pascal-like code, or terse riddles more like a sort of verbal APL.

Just as in regular languages, it isn’t hard to write Swift code which is almost incomprehensible. Neither the language nor conventions recommended by Xcode encourage a developer to do so, but one of the most common objections to the use of Swift is that it somehow makes obfuscation inevitable. Most programmers come from a background of declarative grammar, and Swift’s support for alternatives such as functional and generic programming can come as a bit of a shock. But you don’t have to go there at all, and if you don’t think you can maintain it, you shouldn’t be writing it that way.

Personally, I find Objective-C messaging quite strange and difficult to grok, but my exposure to languages like Smalltalk has been limited. I don’t see any way round that if you want to code in Objective-C, but that’s not seen as being disadvantageous. In any language, it’s surely most important to find a personal style which you find efficient for working and which is, above all else, readily maintainable.

Another frequent subject among the language-religious is whether, when it comes to accessing macOS features, a language is considered to be ‘first’ or ‘second class’. Given that Objective-C has been part of macOS since its inception, it isn’t surprising that some older interfaces are quite awkward to access from the brash newcomer Swift. For many, Swift coders have written wrappers to protect you from C calling conventions and the like, and I haven’t yet found any part of macOS which is inaccessible from Swift. This isn’t really about class, it’s just about age: and if that was really so important, we’d probably still be writing a lot of assembler or raw C.

For me, one of the important determinants when choosing a language is its impact on the product, in terms of its resource requirements and performance, which are so seldom measured or compared objectively.

At the end of these tirades of fanaticism for or against any particular language, I’m simply left wondering what any of this has to do with reality. If I can write and repair code when I’m so bushed that I’m in danger of falling asleep on the keyboard, and the resulting apps do their job well, who cares whether they’re written in Swift or Fortran?

That’s my problem. I see programming languages are mere tools, not systems of belief in themselves. As the polyglot might make love in French, drive in Italian, and do business in English, I’m happy to get on with whatever works best in the circumstances. Perhaps I’m just destined to burn in language Hell.