Strong typing, the new crusade for the functional programming zealots

I remember a time when a cleancut C++ programmer would browse the backwaters of the internet and inevitably stumble across the heretical suggestion that functions rather than objects should be the basis of all code. I was reminded of this time recently when somebody suggested that Raskell was good because it would introduce more people to functional programming. What surprised me was that I didn't rush to join her on her quest to liberate all state from instance variables, and allow it to roam free in lexical closures. I shrugged off the functional programming crusade as a distraction from a Haskeller's true moral duty these days - proselytising great type systems.

Functional programming is no less of a great idea than it ever has been, but the battle has been won. Projects like node.js taught the world that functions really are a natural way to deal with multithreading. Node could be dismissed as a fad in the process of imploding, but even conservative languages such as C, C++ and Objective-C have all embraced Lambda expressions recently, and next week when Java 8 releases with Anonymous function support, the functional programming crowd will have raised their flag above the high temple of cube farms and tedium. It is time to move on.

Where to? To type systems of course. Everyone is entitled to his or her own opinion on type systems, but I live unashamedly in the strongly typed camp. I cant understand why anyone would sacrifice the security and performance of a strongly typed language. Why trade a compile time error for a runtime one?

The answer of course is that strongly typed languages can be very inconvenient. Take a look at the following simple python example

def multiply(x, y):
    return x * y

and compare it to the equivalent c code

int multiply(int x, int y) {
    return x * y;
double multiply(double x, double y) {
    return x * y;
// and the rest

You quickly see that although it is a little inconvenient to declare types explicitly, often the benefit lies mainly in the implicit polymorphism of weakly typed code (or duck typed as Python rather eccentricly refers to it). C++ improves the situation a little with templates, but I refuse to accept that dressing up a macro system to look like polymorphism can be considered progress. Now look at the Haskell version (spread over two lines in the spirit of fairness)

multiply x y =
    x * y

It is no more verbose than the Python version, but it will run faster, and best of all it will throw a compiler error if you try to multiply a window object by a url object, rather than delegating that testing to the users of your website.

Strong typing has a well earned reputation for being a pain in the arse, but the truth is that bad strong type systems like those in C\C++ are a pain in the arse, good strong type systems like those in Haskell and Golang with Type inference, Algebraic datatypes, and interface based polymorphism across even the primitive datatypes are a coder's best friend.

I leave you with a plea - try a modern strongly typed language for your next side project. I would suggest golang. Personally I prefer Haskell, but its focus on purity can make it hard to get anything useful done for the first few years. Golang has taken the best of Haskell's type system, Functional programming's approach to concurrency, Python's bottomless standard library and most rarely, it seems to have inherited from Google that C\C++'s feel of being a "serious" language in which real people get shit done.

Posted on 14 March 2014

Based on a work at

Slide to code blog is licensed under a Creative Commons Attribution 3.0 Unported License