How would Functional Programming proponents answer this statement in Code Complete?

Question

On page 839 of the second edition, Steve McConnell is discussing all the ways that programmers can "conquer complexity" in big programs. His tips culminate with this statement:

"Object-oriented programming provides a level of abstraction that applies to algorithms and data at the same time, a kind of abstraction that functional decomposition alone didn't provide."

Coupled with his conclusion that "reducing complexity is arguably the most important key to being an effective programmer" (same page), this seems to pretty much a challenge to functional programming.

The debate between FP and OO is often framed by FP proponents around the issues of complexity that derives specifically from the challenges of concurrency or parallelization. But concurrency is certainly not the only kind of complexity software programmers need to conquer. Perhaps focusing on reducing one sort of complexity increases it greatly in other dimensions, such that for many cases, the gain is not worth the cost.

If we shifted the terms of the comparison between FP and OO from particular issues like concurrency or reusability to the management of global complexity, how would that debate look?

EDIT

The contrast I wanted to highlight is that OO seems to encapsulate and abstract away from the complexity of both data and algorithms, whereas functional programming seems encourage leaving the implementation details of data structures more "exposed" throughout the program.

See, e.g., Stuart Halloway (a Clojure FP proponent) here saying that "the over-specification of data types" is "negative consequence of idiomatic OO style" and favoring conceptualizing an AddressBook as a simple vector or map instead of a richer OO object with additional (non-vectorish & non-maplike) properties and methods. (Also, OO and Domain-Driven Design proponents may say that exposing an AddressBook as a vector or map overexposes the encapsulated data to methods that are irrelevant or even dangerous from the standpoint of the domain).

Answer 1

Keep in mind that the book was written over 20 years go. To professional programmers of the day, FP didn't exist - it was entirely in the realm of academics & researchers.

We need to frame "functional decomposition" in the proper context of the work. The author is not referring to functional programming. We need to tie this back to "structured programming" and the GOTO filled mess that came before it. If your point of reference is an old FORTRAN/COBOL/BASIC that didn't have functions (maybe, if you were lucky you'd get a single level of GOSUB) and all your variables are global, being able to break your program down into layers of functions is a major boon.

OOP is a further refinement on this sort of 'functional decomposition'. Not only can you bundle instructions together in functions but you can group related functions with the data they're working on. The result is a clearly defined piece of code that you can look at and understand (ideally) without having to chase all around your codebase to find what else might operate on your data.

Answer 2

I imagine functional programming proponents would argue that most FP languages provide more means of abstraction than "functional decomposition alone" and do in fact allow means of abstractions comparable in power to those of Object Oriented Languages. For example one could cite Haskell's type classes or ML's higher order modules as such means of abstractions. Thus the statement (which I'm pretty sure was about object orientation vs. procedural programming, not functional programming) doesn't apply to them.

It should also be pointed out that FP and OOP are orthogonal concepts and not mutually exclusive. So it does not make sense to compare them with each other. You could very well compare "imperative OOP" (e.g. Java) vs. "functional OOP" (e.g. Scala), but the statement you quoted would not apply to that comparison.

Answer 3

I find functional programming extremely helpful in managing complexity. You tend to think about complexity in a different way though, defining it as functions that act on immutable data at different levels rather than encapsulation in an OOP sense.

For example, I recently wrote a game in Clojure, and the entire state of the game was defined in a single immutable data structure:

(def starting-game-state {:map ....
                          :player ....
                          :weather ....
                          :other-stuff ....}

And the main game loop could be defined as applying some pure functions to the game state in a loop:

 (loop [initial-state starting-game-state]
   (let [user-input (get-user-input)
         game-state (update-game initial-state user-input)]
     (draw-screen game-state)
     (if-not (game-ended? game-state) (recur game-state))))

The key function called is update-game, which runs a simulation step given a previous game state and some user input, and returns the new game state.

So where's the complexity? In my view it has been managed quite well:

• Certainly the update-game function does a lot of work, but it is itself built up by composing other functions so it's actually a pretty simple itself. Once you go down a few levels, the functions are still pretty simple, doing something like "add an object to a map tile".
• Certainly the game state is a big data structure. But again, it's just built up by composing lower level data structures. Also it's "pure data" rather than having any methods embedded or and class definition required (you can think of it as a very efficient immutable JSON object if you like) so there is very little boilerplate.

OOP can also manage complexity through encapsulation, but if you compare this to OOP, the functional has approach some very big advantages:

• The game state data structure is immutable, so a lot of processing can easily be done in parallel. For example, it's perfectly safe to have a rendering calling draw-screen in a different thread from the game logic - they can't possibly affect each other or see an inconsistent state. This is surprisingly difficult with a big mutable object graph......
• You can take a snapshot of the game state at any time. Replays are trivial (any thanks to Clojure's persistent data structures, the copies take up hardly any memory since most of the data is shared). You can also run update-game to "predict the future" to help the AI evaluate different moves for example.
• Nowhere did I have to make any difficult trade-offs to fit into the OOP paradigm, such as defining a rigid class heirarchy. In this sense the functional data structure behaves more like a flexible prototype-based system.

Finally, for people who are interested in more insights on how to manage complexity in functional vs. OOP languages, I strongly reccoomend the video of Rich Hickey's keynote speech Simple Made Easy (filmed at the Strange Loop technology conference)

Answer 4

"Object-oriented programming provides a level of abstraction that applies to algorithms and data at the same time, a kind of abstraction that functional decomposition alone didn't provide."

Functional decomposition alone isn't enough to make any sort of algorithm or program: you need to represent the data too. I think the statement above implicitly assumes (or at least it can be understood like) that the "data" in the functional case is of the most rudimentary kind: just lists of symbols and nothing else. Programming in such a language is obviously not very convenient. However, many, especially the new and modern, functional (or multiparadigm) languages, such as Clojure, offer rich data structures: not only lists, but also strings, vectors, maps and sets, records, structs - and objects! - with metadata and polymorphism.

The huge practical success of OO abstractions can hardly be disputed. But is it the last word? As you wrote, concurrency issues are already the major pain, and the classical OO contains no idea of concurrency at all. As a result, the de facto OO solutions for dealing with concurrency are just superimposed duct tape: works, but it's easy to screw up, takes considerable amount of brain resources away from the essential task at hand, and it doesn't scale well. Maybe it's possible to take the best of many worlds. That's what modern multiparadigm languages are pursuing.

Answer 5

Mutable state is the root of most complexities and problems related to programming and software/system design.

OO embraces mutable state. FP abhors mutable state.

Both OO and FP have their uses & sweet spots. Choose wisely. And remember the adage: "Closures are poor man's objects. Objects are poor man's closure."

Answer 6

Functional Programming can have objects, but those objects tend to be immutable. Pure functions (functions without side effects) then operate on those data structures. It's possible to make immutable objects in object oriented programming languages, but they weren't designed to do it and that's not how they tend to be used. This makes it hard to reason about object oriented programs.

Let's take a very simple example. Let's say that Oracle decided that Java Strings should have a reverse method and you wrote the following code.

String x = "abc";
StringBuffer y = new StringBuffer(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString());

what does the last line evaluate to? You need special knowledge of the String class to know that this would evaluate to false.

What if i made my own class WuHoString

String x = "abc";
WuHoString y = new WuHoString(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString())

It's impossible to know what the last line evaluates to.

In a Functional Programming style it would be written more as follows:

String x;
equals(toString(reverse(x)), toString(reverse(WuHoString(x))))

and it should be true.

If 1 function in one of the most basic classes is so difficult to reason about then one wonders if introducing this idea of mutable objects has increased or decreased the complexity.

Obviously there are all sorts of definitions of what constitutes object oriented and what it means to be functional and what it means to have both. To me you can have a "functional programming style" in languagess that don't have things like first class functions but other languages are made for it.

Answer 7

I think in most cases the classic OOP abstraction does not cover the concurrency complexity. Therefore OOP (by its original meaning) doesn't exclude FP, and that's why we see things like scala.

Answer 8

The answer depends on the language. Lisps, for example, have the really neat properly that code is data--the algorithms you write are actually just Lisp lists! You store data the same way you write the program. This abstraction is simultaneously simpler and more thorough than OOP and lets you do some really neat things (check out macros).

Haskell (and similar language, I imagine) have a completely different answer: algebraic data types. An algebraic data type is like a C struct, but with more options. These data types provide the abstraction needed to model data; functions provide the abstraction needed to model algorithms. Type classes and other advanced features provide an even higher level of abstraction over both.

For example, I am working on a programming language called TPL for fun. Algebraic data types make it really easy to represent values:

data TPLValue = Null
              | Number Integer
              | String String
              | List [TPLValue]
              | Function [TPLValue] TPLValue
              -- There's more in the real code...

What this says--in a very visual way--is that a TPLValue (any value in my language) can be a Null or a Number with an Integer value or even a Function with a list of values (the parameters) and a final value (the body).

Next I can use type classes to encode some common behavior. For example, I could make TPLValue and instance of Show which means it can be converted to a string.

Additionally, I can use my own type classes when I need to specify behavior of certain types (including ones I did not implement myself). For example, I have a Extractable type class which lets me write a function that takes a TPLValue and returns an appropriate normal value. Thus extract can convert a Number to an Integer or a String to a String as long as Integer and String are instances of Extractable.

Finally, the main logic of my program is in several functions like eval and apply. These are really the core--they take TPLValues and turn them into more TPLValues, as well as handling state and errors.

Overall, the abstractions I'm using in my Haskell code are actually more powerful than what I would have used in an OOP language.

Answer 9

The quoted sentence does not have any validity anymore, as far as I can see.

Contemporary OO languages can not abstract over types whose kind is not *, i.e. higher kinded types are unknown. Their type system does not allow to express the idea of "some container with Int elements, that allows to map a function over the elements".

Hence, this basic function like Haskells

fmap :: Functor f => (a -> b) -> f a -> f b 

cannot be written easily in Java*), for example, at least not in a type safe way. Hence, to obtain basic functionality, you have to write lots of boilerplate, because you need

1. a method to apply a simple function to elements of a list
2. a method to apply the same simple function to elements of an array
3. a method to apply the same simple function to values of a hash,
4. .... set
5. .... tree
6. ... 10. unit tests for the same

And yet, those five methods are basically the same code, give or take some. In contrast, in Haskell, I'd need:

1. A Functor instance for list, array, map, set and tree (mostly predefined, or can be derived automatically by the compiler)
2. the simple function

Note that this is not going to change with Java 8 (just that one can apply functions more easily, but then, exactly, will the problem above materialize. As long as you do not even have higher order functions, you are most likely not even able to understand what higher kinded types are good for.)

Even new OO languages like Ceylon do not have higher kinded types. (I have asked Gavin King lately, and he told me, it was not important at this time.) Don't know about Kotlin, though.

*) To be fair, you can have an interface Functor that has a method fmap. Bad thing is, you can't say: Hey, I know how to implement fmap for library class SuperConcurrentBlockedDoublyLinkedDequeHasMap, dear compiler, please accept that from now on, all SuperConcurrentBlockedDoublyLinkedDequeHasMaps are Functors.

Answer 10

Anyone who ever programmed in dBase would know how useful single line macros were to making reusable code. Although I haven't programmed in Lisp, I have read from many others who swear by compile time macros. The idea of injecting code into your code at compile time is used in a simple form in every C program with the "include" directive. Because Lisp can do this with a Lisp program and because Lisp is highly reflective, you get much more flexible includes.

Any programmer that would just take an arbitrary text string from the web and pass it on to their database isn't a programmer. Likewise, anybody that would allow "user" data to automatically become executable code is obviously stupid. That doesn't mean that allowing programs to manipulate data at execution time and then execute it as code is a bad idea. I believe that this technique will be indispensable in the future which will have "smart" code actually writing most programs. The whole "data/code problem" or not is a matter of security in the language.

One of the problems with most languages is that they were made for a single off line person to execute some functions for themselves. Real world programs require that many people have access at all times and at the same time from multiple Cores and multiple computer clusters. Security should be a part of the language rather than the operating system and in the not too distant future it will be.