Functional Programming and Object-Oriented Programming. What are they and what are their main differences?

Question

What are and what are the main differences between Functional Programming and Object-Oriented Programming?

Answer 1

In theory, comparing these two paradigms makes no sense: the functional programming, to imperative programming and the logic programming (among others) refer to the way a given computation is described - respectively, in the form of mathematical functions (lambda calculus), in the form of explicit instructions to the machine (von Neumann architecture), and in the form of logical predicates to be proved by induction (resolution in first-order logic with setback). Already the object-oriented programming has more to do with how the data structures of a program are combined/united with the subroutines that have dealt with these structures (i.e. the data and behavior are combined in the same logical structure).

That is, one can have a language that is both functional and object-oriented - in the same way that one can have one that does not follow either paradigm.

In practice, most object-oriented languages follow the imperative paradigm, and similarly many functional languages (such as Lisp) include nonfunctional characteristics - such as state variables. For this reason, in the rest of the answer I will consider object orientation in an imperative context - although in principle it is possible to apply it to other contexts.

Functional Programming

Functional programming is based on the mathematical concept of function, where for each element of its domain (input) set there is only one element in its counter-domain (output) set. In addition, functions are usually expressed by means of other functions - so obtaining the value of the function for a given set of parameters involves not only applying the rules of that function, but also making use of other functions.

For this reason, functional programming does not have the concept of "state variables"; if any value (be it numerical, textual, a vector, matrix, or something more complex) appears at any time in computation, that value is considered to be unique and immutable throughout the process. One can establish relations between values - how to say that 2 is half of 4 - but the value 2 will always be a 2 and the 4 will always be a 4.

Object-Oriented Programming

In imperative programming it is considered that data structures (again, numbers, text, vectors, matrices, etc.) exist in a given state, and that through specific commands to the computer this state is being changed in the course of the program, so that at the end of the execution it represents the consequences of a logical process. The available commands are fixed by language, and usually there are separate commands to handle types of data distinguished.

The concept of "object" is an extension of this behavior beyond the data types of the language itself, applying them also to the types defined by the user: for each data structure defined, a series of operations is also defined that can be applied to this structure - in general influenced by its internal state - and from then on it is allowed to use these structures as distinct types, and not as generic data structures. Add to this the concept of "more generic types" and "more specific types" (i.e. inheritance), and we have the possibility of creating a rich taxonomy of types each with its operations - so that the programs can be expressed in a higher level of abstraction than those using only the types provided by the programming language itself.

When objects and their relations are the central point of a proramation language, it is said that it is "object-oriented" (or, in the popular, object-oriented to objects) - because the entire logical flow of the program is based on what objects exist and how they interact with each other. That is, initially these objects are there - in their initial state - and as the program interacts with its environment (either through an input, or through user interaction) these objects will change their state.

Similarities

• Just as a function has domain and counter-domain, an object has operations that are only applicable to it in particular.

• Just as a set can have subsets, an object can have subtypes; and just as a subset element can be used as a parameter for a function that has the main set as a domain, an object of the subtype inherits all operations of its base type (i.e. they apply equally and he).

• There is [necessarily] no entry or exit point in a functional program: in principle, any of its functions could be called from an interactive input, for example. Similarly, an object-oriented system does not establish a "start" or an "end" for the program: each "message" sent to an object will cause a series of effects (and perhaps a response), but there is no predefined order for which messages will be sent.

Differences

• The main difference is the question of the state: a function by definition does not have side effects, it only returns a result from a given set of parameters. Consequently, two or more calls from the same function passing the same parameters should produce equal results - while in the POO the result may vary depending on the state of the object at the time the Mensagen was sent.

• As a consequence, while in the POO an object can be ignorant of the other objects that make up the system (it is enough to know its nearest neighbors and send messages to them) - reducing the coupling - this is more difficult to achieve in functional programming (and by my experience, also in logic) because of the immutability of data structures.

  • Exemplifying, if the entity A has a reference to the B, and the internal state of B changes, no need to notify A because the subsequent messages they exchange will be influenced by the change of state (in POO). Already in the functional paradigm, A and B are the results of a computation - valid now and forever; if another computation produced a B', then it is necessary to produce also a A' so that the desired relationship between the B "new" and the A fits your new configuration.

• On the other hand, this independence from a state makes it much simpler to evaluate and debug functional programs - because they can be tested part by part and the result of the whole will be identical to the sum of the parts. Whereas in the POO it is sometimes difficult to reproduce - or even discover - the state in which a set of objects was when unexpected behavior occurred, so as to inspect their behavior.

Answer 2

The mgibsonbr response is excellent and I could not have done better. I’ll just put something a little different:

Functional	OOP
Based on mathematical functions	Based on forms and behaviors of objects through fields and methods
Lambda Calculus	Based on forms and behaviors of objects through fields and methods
Principle of Compositionality	Heritage and Abstraction
Recursion	Polymorphism
Referential transparency	Encapsulation
Computational purity (no side effects)	Side effects
Lazy Evaluation (delayed execution)	Eager Evaluation (immediate execution)
Immutability	Data is mutable
Lineage based on "macros" (Lisp) or "Pattern matching" (ML)	Lineage based on "classes" (C++) or "prototypes" (Javascript)
Things defined with many behaviors	Many things and defined behaviors
Formulas/actions first	Data/nouns first
Find the correction of the code	Search for code reuse
Enforcement order does not matter (parallelism)	Order of execution is important
Data loosely coupled to functions	Strongly coupled data and functions
Concision (opinion?)	Explicitude (opinion?)
Lisp, Scheme, ML, Scala, F#, Haskell, Erlang	Smalltalk, C++, Java, Python, Ruby, JS

Of course there are some points that help understand the differences between them. I won’t go into detail about each point, it would give a book. The subject is a little more complex than that and there are some inaccuracies to simplify the exposure. The table should not be interpreted as a definitive comparison of differences. Neither is it a "either you choose one or the other aspect of each side of the table".

One of the most important points is that pure languages in one paradigm are usually less useful in most real world applications and do not achieve great success. For technical or cultural reasons, languages closer to the imperative paradigm are more popular.

Actually in OOP, the only popular languages are essentially imperative with object orientation characteristics and implement various functional programming concepts. And the main concept of the paradigm, which is inheritance, is often discouraged. Some people put another concept as the main one, but other concepts are not even unique to object orientation.

Functional languages that do not allow any kind of state change, or side effects (even if controlled) have extremely impaired utility for most of the problems.

Don’t be fooled when they try to sell paradigm purity. That’s great in academia. No paradigm is a panacea for anything.

Both paradigms provide abstractions, therefore inefficiencies will be present, each with its own characteristic. To reduce inefficiencies the purity of paradigm must be left aside; and the closer they approach the imperative, the closer they are to concrete processing.

Complementing according to the comments below, the concepts are orthogonal, and if it is not clear, in "real world" languages they are either functional or imperative with object-oriented characteristics.

Object orientation It is such a complicated theme that no one has a clear definition of what it is. For every person you ask it will give its definition. So if someone says you’re wrong, you probably are, but not the way they’re saying :) And Alan Kay, creator of the term, admits more recently that Smalltalk, his language, is actually message-oriented and not objects (see another controversy).

And it’s sad that a lot of people think that they’re object-oriented programming and they’re not, it’s like writing a book having a hard time in communication and expression classes. They go so far as to discuss which language is more object-oriented than the other, Java or C# (among others). Both are very little object oriented (Aaahhhh, marketing), and it is recommended to use little of the characteristics of this paradigm. This is because each one thinks that a certain characteristic is more important than another and none implements all the characteristics of the paradigm purely. Thank goodness!

And functional languages are far from controversial? No, many people consider that Lisp, which was the first functional language, is not purely functional and only those based on ML are. Moreover, some say that Lisp is one of the most object-oriented languages that exist (the very creator of the term).

Some say that orientation is even paradigm, and this is just another reason to show that they are orthogonal.

Today new languages and those that are wanting to be updated increasingly adhere to the functional paradigm. Of course, not purely, just pragmatically. I put in the Scala and F# in the functional table because they sell like this, but they are very imperative too, and they implement everything of importance of object orientation. So even imperative and functional can be used together, although there is a paradigm that is strong and the other only helps. C# is an example of an imperative language that is more and more functional, but will never cease to be predominantly imperative, and will maintain its object orientation (but that has less and less important role, since the 2.0 this has been falling).

In code organization, in its data structure that has more to do with OOP, the imperative procedural/modular and even the functional is more useful than the pure object oriented. Many do not realize this and continue to do the same always following the cake recipe you learned. People use OOP as a "good practice" (search here for what I think of it). Good practice is knowing what you’re doing and adopting what’s best for each case. Composition is the secret to good maintenance and today who does not stray from OOP creates objects that have nothing to do with the initial idea of the paradigm and it is common to modularize so much that borders on functional, modular and even procedural, but as it is within a class, they think that.

I explained some facts and gave some opinions, not least because this is a subject not so well defined and understood by all.

Answer 3

Object orientation aims to mirror the real world. For example: a car, we can insert it into the system, which would turn it into an object. This object has attributes (such as color, make, power, etc.) that distinguish it from other objects. It is a discipline and type of programming that I like and prefer, but I made a summary because the subject is very extensive. I hope my reply helped(a).