Difference between OOP and Functional Programming (scheme) [closed]

Question

I'm watching a video course/lectures from Stanford. The course is "The Structure and Interpretation of Computer Programs"

In the first OOP lecture, the instructor (Brian Harvey) describes an OOP method as one that gives different answers for the same question, while a function in functional programming gives a certain output for a certain input.

The following code is an example of a method in OOP that gives a different answer each time it's called:-

(define-class (counter)
  instance-vars (count 0))
  (method (next)
    (set! count (+ count 1))
    count) )

Now although the course is illustrated by scheme, I didn't pay much attention to the language itself, and so I can't explain the code; but can't a similar function "next" do the same thing as this "next" function? In C, I would declare a global variable, and each time increase it by one when calling next. I know C is procedural, but I'm guessing a similar thing can be done in Scheme.

Answer 1

Well. With all due respect to the lecturer, these are slightly fishy definitions of both "OOP" and "functional programming". Both terms are consistently used, well, inconsistently, both in industry and academic contexts, not to mention informal use. If you dig a bit deeper, what's really going on is that there are several orthogonal concepts--different axes along which a choice is made in how to approach a program--that are being conflated, with one set of choices being arbitrarily called "OOP" despite not having anything else tying them together.

Probably the two biggest distinctions involved here are:

• Identity vs. value: Do you model things by implicit identity (based on memory location or whatnot) and allow them to change arbitrarily? Or do you model things by their value, with no inherent notion of identity? If you say x = 4 does that mean that x is an alias to the timeless Platonic ideal of the number 4, or is x the name of a thing that's currently a four, but could be something else later (while still being x)?

• Data vs. behavior: Do you work with simple data structures whose representation can be inspected, manipulated, and transformed? Or do you work with abstracted behaviors that do things, representing data only in terms of the things you can do with it, and let these behavioral abstractions operate on each other?

Most standard imperative languages lean toward using identity and data--pointers to C structs are about as purely this approach as possible. OOP languages tend to be defined largely by opting for behavior over data, often leaning toward identity as well but not consistently (cf. the popularity of "immutable" objects).

Functional programming usually leans more toward values rather than identity, while mixing data and behavior to various degrees.

There's a lot more going on here as well but I think that's the key part of what you're wondering here.

---

If anyone's curious I've elaborated a bit on some of this before: Analyzing some essential concepts of many OOP languages, more on the identity/value issue and also formal vs. informal approaches, a look at the data/behavior distinction in functional programming, probably others I can't think of. Warning, I'm kind of long-winded, these are not for the faint of heart. :P

Answer 2

There is a page on the excellent Haskell wiki, where differences in Functional Programming and OOP are contrasted. The Haskell wiki is a wonderful resource for everything about functional programming in general in addition to helping with the Haskell language.

Functional programming and OOP Differences

The important difference between pure functional programming and object-oriented programming is:

Object-oriented:

Data:

• OOP asks What can I do with the data?
• Producer: Class
• Consumer: Class method

State:

• The methods and objects in OOP have some internal state (method variables and object attributes) and they possibly have side effects affecting the state of computer’s peripherals, the global scope, or the state of an object or method. Variable assignment is one good sign of something having a state.

Functional:

Data:

• Functional programming asks How the data is constructed?
• Producer: Type Constructor
• Consumer: Function

State:

• If a pure functional programming ever assigns to a variable, the variable must be considered and handled as immutable. There must not be a state in pure functional programming.
• Code with side effects is often separated from the main purely functional body of code
• State can be passed around as an argument to a function, this is called a continuation.

Functional substitutes for OOP generators

The way to do something similar to OOP style generators (which have an internal state) with pure functional programming is to approach the problem from a different point of view, by using one of these solutions depending on the use case:

1. Process some or all values in a sequence:

Type of sequence can be list, array, sequence or vector.

• Lisp has car and Haskell has first, which take first item from a list.

• Haskell also has take, which takes the first n items, and which supports lazy evaluation and thus infinite or cyclic sequences – like OOP generators do.

• Both have first, and different map, reduce or fold functions for processing sequences with a function.

• Matrices usually also have some ways to map or apply a function to each item.

2. Some values from a function are needed:

The indices might be from a discrete or continuous scale (integers or floats).

• Make one pure function to generate the indices (events) and feed those to another pure function (behaviour). This is called Functional reactive programming. This is a form of Dataflow programming along with cell-oriented programming. The Actor model is also somewhat similar in operation, and a very interesting alternative to threads with handling concurrency!

3. Use a closure to confine and encapsulate the state from the outside

• This is the closest subsitute to OOP way with generators (which I think actually originated to imitate closures), and also farthest from pure functional programming, because a closure has a state.