The transition from object-oriented to functional programming

I am convinced that we will move from object-oriented programming to functional programming. I am also convinced that the transition will be a difficult one, more difficult that the transition from structured programming to object-oriented programming.

The transition from structured programming to object-oriented programming was difficult. Object-oriented programming required a new view of programming, a new way of organizing data and code. For programmers who had learned the ways of structured programming, the shift to object-oriented programming meant learning new techniques.

That in itself is not enough to cause the transition to functional programming to be more difficult. Functional programming is, like object-oriented programming, a new view of programming and a new way of organizing data and code. Why would the transition to functional programming be more difficult?

I think the answer lies within the organization of programs. Structured programming, object-oriented programming, and functional programming all specify a number of rules for programs. For structured programming, functions and subroutines should have a single entry point and exit point and IF/THEN/ELSE blocks and FOR/NEXT loops should be used instead of GOTO statements.

Object-oriented programming groups data into classes and uses polymorphism to replace some conditional statements. But object-oriented programming was not totally incompatible with structured programming (or 'procedural programming'). Object-oriented programming allowed for a top level of new design with lower layers of the old design. Many early object-oriented programs had large chunks of procedural code (and some still do to this day). The thin layer of objects simply acted as a container for structured code.

Functional programming doesn't have this same degree of compatibility with object-oriented programming (or structured programming). Functional programming uses immutable objects; object-oriented programming is usually about mutable objects. Functional programming works with sets of data and leverages tail recursion efficiently, object-oriented programming uses the explicit loops and conditional statements of procedural programming.

The constructs of functional programming work poorly at containing object-oriented constructs. The "trick" of wrapping old code in a containing layer of new code may not work with functional programming and object-oriented programming. It may be better to build functional programming constructs inside of object oriented programming constructs, working from the "inside out" rather than from the "outside in" of the object-oriented transition.

One concept that has helped me transition is that of immutable objects. This is a notion that I have "imported" from functional programming into object-oriented programming. (And I must admit that the idea is not mine or not even new; Java's String objects are immutable and have been since its inception.)

The use of immutable objects has improved my object-oriented programs. It has moved me in the direction of functional programming -- a step in the transition.

I believe that we will transition from object-oriented programming to functional programming. I foresee a large effort to do so, and I foresee that some programs will remain object-oriented programs, just as some legacy programs remain procedural programs. I am uncertain of the time frame; it may be in the next five years or the next twenty. (The advantages of functional programming are compelling, so I'm tending to think sooner rather than later.)

The revenge of Prolog

I picked up a copy of Clocksin and Mellish, the "Programming in Prolog" text from 1981. (Actually, it's the second edition from 1984.)

This tome gave me a great deal of difficulty back in the late 1980s. For some reason, I just could not "get" the idea of the Prolog language.

Reading it now, however, is another story. Now I "get" the idea of Prolog. A few years of experience can have a large effect on one's comprehension of "new" technology.

What strikes me about Prolog is that it is not really a programming language. At least, not in the procedural sense. (And it isn't. Clocksin and Mellish state this up front, in the preface to the first edition.)

If Prolog isn't a programming language, then what is it? As I see it, Prolog is a language for interrogating databases. Not SQL databases with tables and rows and columns, but databases that hold bits of information that Clocksin and Mellish call "facts".

For example, one can define a set of facts:

male(albert).
male(edward).
female(alice).
female(victoria).
parents(edward, victoria, albert).
parents(alice, victoria, albert).

Then define a relationship:

sister_of(X,Y) :- female(X), parents(X, M, F), parents(Y, M, F).

And then one can run a query:

sister_of(alice, edward).

Prolog will answer "yes", working out that Alice is the sister of Edward.

Today, we would call this database of facts a NoSQL database. And that is what the Prolog database is. It is a NoSQL database, that is, a collection of data that does not conform (necessarily) to the strict schema of a relational database. The Prolog database is less capable than modern NoSQL databases: it is limited to text items, numeric items, and aggregations of items. Modern NoSQL databases can hold these and more: pictures, audio files, and all sorts of things.

Finding an early version of the NoSQL database concept in the Prolog language is a pleasant surprise. For me, it validates the notion of NoSQL databases. And it validates the idea of Prolog. Great minds think alike, and similar solutions to problems, separated by time, confirm the value of the solution.