Scala; the ‘Postfunctional’ Language?


Martin Odersky, author of the Scala programming language has stepped into the “is Scala a functional language?” debate and put a fresh spin on the question: “is Scala a postfunctional language?”

To the man behind Scala, it most definitely is. Scala offers all the programming constructs one would normally associate with functional programming, however, even if the core is functional, Odersky states that Scala has so much more to offer.

To get to grips with this argument, first you need to decide on your definition of a functional language. Odersky splits this complex debate debate into two camps, a “broad definition” camp and a “narrow definition” camp. Odersky is not a fan of the narrow definition, dismissing it as obsolete. To him, if a programming language has to permit only pure functions and not allow side effects to be classed as functional, then there are very few truly functional languages currently in use. He cites that even Haskell has the I/O monad.

Odersky prefers the more inclusive definition: any language that makes function-orientated programming easier and more natural, is a functional language. This is a very vague definition – when it ceases being difficult to write functional programming, and starts being easy, purely depends on individual perception – still, Odersky’s perception is that this is exactly what Scala does.

Scala certainly offers support for function-orientated programming – functions are first class values, lazy vals and streams offer lazy evaluation, etc. There has, however, been some debate as to whether Scala is functional “enough,” with Robert Fischer labelling it a “statically typed object oriented language with closures.” He points out that Scala does feature object-oriented structures, such as class inheritance and overloading; and, if you subscribe to the “narrow” definition of functional programming then Scala’s uncontrolled side-effects render its claims to the title of ‘functional language,’ null and void.

Odersky dismisses these points, stating that just because Scala “is built on the hypothesis that one can be both functional and object-oriented” doesn’t mean it isn’t a ‘true’ functional programming language.

Assuming that you agree with the concept of a language that’s simultaneously object-orientated, and functional-orientated, and have a “broad definition” of functional programming, Odersky’s next point is compelling: people use Scala like a functional language, therefore it is functional language. He cites Scala compiler sources and Scala libraries, written in a predominantly functional style, as proof.

He summarises that Scala provides all the features of a functional language, but with built-in support for imperative constructs and objects. He proposes the hypothesis that, as functional languages become mainstream, Scala’s additional, non-functional features will set it in good stead to be the next generation of programming languages. This proposed trend isn’t a startling new concept: the same thing happened with structured languages and Java. Java provides most of the functionality of a structured language, but the debate about whether it is a structured language or not, is irrelevant now that Java has entered the mainstream.

The crux of Odersky’s conclusion is difficult to argue with: if Scala was adopted as a mainstream programming language, then it would cease to matter whether it was object-orientated, or functional.

Inline Feedbacks
View all comments