Writing code is the primary activity of software development. Writing the right code, code that delivers customer value, is the hard part. But right or wrong, the main thing that developers do is work in an editor, transforming inputs to outputs.

For more than a decade, most mainstream developers have done their work guided by the concepts of object orientation, which says that programs should be structured in a way that mirrors real-world objects. The fundamental concept of an “object” is a software module that combines the functions that operate on data and the data itself an object instance for a customer. For instance, it could store the data of a particular person’s name, account number and so forth.

This is so ingrained that it may seem natural to those who have known no other way, but 25 years ago, it seemed an academic theory with dubious benefits. As an alternative to the behavior-oriented “structural programming” model and the data-oriented world of “fourth-generation languages,” object orientation sometimes seemed like so much mumbo-jumbo, and other times it seemed like it was belaboring well-known principles.

But, over time, object orientation has become the norm. Its dominance is, in my opinion, as much a matter of happy coincidences as any inherent virtue; I utterly believe in the virtues of object orientation, but its uptake in the industry was largely driven by promises of code reuse that were never achieved, and an accidental association with GUI programming, which caused a wholesale reset of development techniques.

Today, we are in a similar situation with functional programming. It will not replace object-oriented programming in the way that OOP replaced structural programming; the concepts of “class” and “object” are clearly attractive for structuring software modules. Rather, functional programming techniques will become ever more common, and programming languages will evolve to have more and more functional features.

It’s always easy to predict what has already happened; in truth, functional programming approaches have quietly become commonplace. I say “functional programming approaches” because what I’m talking about is not at all the “pure functional” theory-driven model. Rather, from a strictly pragmatic point of view, if you compare code written at the turn of the millennium with code written today, you’ll see today’s code has less internal state and more context-carrying arguments, and you’ll see yesterday’s code uses object-structural techniques where today’s developers would use first-class functions (that is, where an OOP developer might define a single-method interface to capture the idea of a sorting strategy, the functional programmer would simply pass around a particular function as the implementation).

There are two major reasons for this change: One simply being that popular languages such as JavaScript and C# conveniently provide functions as first-class types; but the far more important reason is the rise in unit testing as a pervasive discipline in the industry. Functional programming says that the proper role of a function is the transformation of a single input into a single output.

Such functions are by far the easiest to unit-test. Functions that take several different parameters, or are complex monolithic objects, or that squirrel away the results of their calculations, simply require more legwork to test. Programmers, admirably protective of their own time, have slowly been adopting functional forms without necessarily knowing or caring that these forms are “more functionally oriented.”