There is much debate about the merits of different approaches to type systems. Teedy Deigh considers how to make the most of them.
The language of type systems is strewn with polarising metaphors. Do you want your type system to be strong? Do you want it to be muscled and rippling or would you rather it was weak, feeble and a bit of a lightweight, pushed around in its sandbox? On the other hand, would you prefer your type system to be dynamic, with an élan and drive that makes it charming and witty, agile and flexible? You could instead have a static type system, all staid and stuck in the mud.
‘If you used a proper language, with a static type system, you wouldn’t need to write all those unit tests.’
‘Your code must either do very little or not compile if you think types eliminate the need for tests. If you used a proper language, with a dynamic type system, you might actually write something interesting and, hey, perhaps even ship it!’
‘Duck typing is for monkeys so they can patch their running systems because they’re so busy reshipping to cover their mistakes they only talk about testing without actually doing any. A checked type system gives you at least a reality check rather than a maintenance bill.’
‘Strong typing skills are what you need with statically typed languages. Why write two lines when you can spend twenty lines plea-bargaining with the compiler?’
The discussion over type models in languages can get quite heated at times, making you want to change the subject to something less contentious – religion, politics, football, operating systems, editors, etc.
In the spirit of compromise, static type systems have loosened up a little, with type inference used to deduce types the compiler knows full well. Bureaucratic pedants might quibble, believing that if you want to use an object you should fill out a form in triplicate so you can be properly sure you’re getting the right type, but most C++ programmers have found themselves marvelling at the recycled
auto
keyword. C# programmers, meanwhile, have been excited by the ability to use
var
to make their code look like JavaScript, and yet still have a clue as to what’s actually going on, or to use
dynamic
to introduce the element of surprise. Haskell programmers have looked on unimpressed.
Going the other way, we see that declared type systems have crept into more libertine languages, bringing tie-and-tease – if not fully bound BDSM – into their programming discipline. PHP has type hints, which bring to the language a system of typing that ingeniously combines the limitations of static typing with the weaknesses of dynamic typing. More recently Dart has presented programmers with a meh-based type model that allows you to declare your types boldly and defiantly, but in a way that they can be ignored politely. Lisp programmers have stammered indifference.
But these type institutions and movements mask a deeper issue for the modern programmer: all of these refinements and additions are intended to make programmers’ lives easier and, therefore, their livelihoods less secure and their day-to-day negotiations with the compiler and runtime configuration intrinsically less challenging and more boring. I propose that we need a new school of thought in programming language models: type interference. Type interference is not specifically a kind of type model, but is more a property that certain type systems can exhibit.
A great example of type interference is the head-on collision between C++’s template system and the traditional procedural worldview of most compilers. The resulting debris yields pages of cryptic hieroglyphs. This kind of interference has resulted in many lost hours – even days – of programmer time, while at the same time sparking a secondary industry in tools and expertise to decrypt such apocrypha. It has allowed some programmers to rise above others by learning to read the tea leaves of the compiler's runic ramblings, acquiring deep knowledge of arcane arts rather than actually developing software or learning how to improve their people skills.
The discovery that C++’s template system was Turing complete can be seen to be at the heart of this type interference devolution. Indeed, it is widely acknowledged that a compilation message from a particularly gnarly template that was missing a comma was the first to pass the Turing test.
Disappointingly compiler writers have been making progress on reducing the level of noise, allowing some messages to be contained even on something as small as a 1080p HD screen!
A form of type interference that has taken the Java world by Sturm und Drang is dependency injection, a form of substance abuse that is spilling over into other languages. The term dependency injection sounds a lot more exciting than ‘lots of XML to create objects and pass arguments around’. Its countercultural overtones make it both attractive and addictive. Rather than creating objects in an obvious and visible way, where they are needed and using the principal programming language of a system, programmers instead dump various object and type relationships into less readable XML files that are separate from the rest of their code. This can make even the simplest instantiation an act of careful orchestration between different frameworks, languages and phases of the moon. In large organisations it can lead to regional conflicts and protracted political wrangling over files.
It is expected that one day DI will be unmasked as an April Fool’s joke, a cunning con that has deceived programmers into stating that their systems are loosely coupled, highly cohesive and statically typed, while at the same time deferring all type decisions to runtime and sweeping all the dependency problems under the rug of XML files. It is also worth noting that XML, like the C++ template system, is a tenebrous exercise in obscurity. The waves of angle brackets across the screen look not so much like a formation of migrating geese as an Agincourt of arrows, threatening any who dare attempt understanding.
It has long been known that the majority of professional programmers write only a few lines of working code every day. Type interference helps with that, allowing them to claim a debugged template fragment or XML stanza as the major part of their five-a-day. Type systems need to balance the needs of the many with the needs of the few, favouring developmental obscurity and job security over other measures of productivity and worthiness.
