OOP vs functional (11)

1 Name: #!/usr/bin/anonymous : 2011-03-26 13:11 ID:tubYEjxP This thread was merged from the former /code/ board. You can view the archive here.

in layman's terms what is the difference between the two ?

2 Name: #!/usr/bin/anonymous : 2011-03-26 21:22 ID:fy1QcJq/

Functional programming isn't the direct opposite of OOP, but of imperative programming. Imperative programming operates on the principle that programs have a global 'state' which should be manipulated to produce the desired results, while functional programming attempts to avoid state and treat all data and program flow as interactions between functions. Having no state is often described as being "functionally pure" or "no side effects."

To use an example, consider possible programs in an imperative and functional style:

def x_plus_three(x):
y = 42 # this would be a side effect
# it's poor programming, but the language won't stop you
return x + 3

Algebra, while not technically a programming language, is indeed functional:

f(x) = x + 3

Notice that using algebra, you couldn't change the value of y from within a function that operates only on x. Purely functional languages are subject to the same constraint- in fact, they don't actually 'change' anything at all, they merely produce brand new outputs by performing calculations on their inputs. This prevents errors in case you didn't want y to become 42 or x to permanently increase by three.

As for OOP, it's just a means to reduce errors created by accidentally changing things you didn't intend to change. You might define y as a private variable in a class, meaning each object of that class possesses its own 'y' and only functions attached to that object can change it, for that object alone.

In sum, to quote a certain Michael Feathers:

> OO makes code understandable by encapsulating moving parts.
> FP makes code understandable by minimizing moving parts.

3 Name: #!/usr/bin/anonymous : 2012-01-26 01:47 ID:auY5imFY

Functional isn't opposite of OO, because there is functional OO.

OO with immutable objects is functional. (States can still be represented by creating new objects based on old ones.)

From a functional point of view, OO is a way of organizing the types into classes which are tuples of properties optionally linked by inheritance relationships, and of dispatching methods based on class-based pattern matching over the argument lists.

Functional OO is "cleaner" than regular OO in some ways. For instance circle-ellipse issues don't arise, because you can't mutate a circle or ellipse once it is constructed.

4 Name: #!/usr/bin/anonymous : 2012-04-11 02:57 ID:x2KjDRnY

>>3

> circle-ellipse issues don't arise, because you can't mutate a circle or ellipse once it is constructed.

I don't believe you here. You can still make a copy of some object A, and call it B. Hell, you can even call it A with a let statement.

5 Name: #!/usr/bin/anonymous : 2012-07-17 22:25 ID:n43w4UzA

I had an interesting realization on the nature of OOP once. When you think about it, it effectively models multiple computers running programs and interacting with each-other.
Even in game programs you have the 'view' model where one ticks each registered object in the main loop - it can be viewed as multiple processors being 'ticked' to the next CPU cycle.

6 Name: #!/usr/bin/anonymous : 2012-08-27 12:46 ID:BkDUZxkD

>>3
Pure OOP [i]is[/i] the opposite (dual) of pure FP. OOP is modeled by terminal coalgebras, FP by initial algebras. The distinction you're making is imperative vs declarative.
To solve the ``Expression Problem'', you need both.

7 Name: #!/usr/bin/anonymous : 2012-08-27 12:47 ID:Heaven

>>6
is

8 Name: #!/usr/bin/anonymous : 2012-10-08 20:33 ID:g8LKidg7

OOP is not needed in most small projects as it only complicates understanding of the code and, as a result, increases time spent on its' reading and monies spent on its' support.
OOP makes life easier when dealing with something really obstructive. Instead of making clusterfuck of dynamically loaded modules and thousands functions in the global namespace, you simplify (or trying to) program structural organization, dividing it into classes and objects. Saves lots of time when amount of actual developers is more than 3.
Oh, and, of course:

object->doSomething(whatever);
doSomething(object, whatever);

9 Name: #!/usr/bin/anonymous : 2012-10-20 13:51 ID:ExnosPyy

Note that variables captured in closures/continuations are technically equivalent to instances of which all members, including methods are private - and only visible to child classes defined in it's own scope (NOT derived classes, protected: is a sideffect).

In the same vein closures are just class instances without sideffects (are we comparing to pure-functional, right?).

Btw, this is clearly visible in C++11 and it's implementation of lambdas.

However nobody uses pure functional style, nor OO with such a rigid encapsulation. Both are most widely deployed in multi-paradigm systems, on that level, they could be IMO treated as equal.

10 Name: #!/usr/bin/anonymous : 2013-08-03 14:09 ID:zc9L2Zn3

>>8

There is little difference between the two in a language which typesystem can express subtypes. In such a language

object->method(arg1,arg2,arg3) 

would be syntactic sugar for:

method (object, arg1, arg2, arg3)

where object can be replaced by an appropriate subtype. Subtyping can express inheritance.

11 Name: #!/usr/bin/anonymous : 2013-08-11 05:20 ID:Heaven

> Functional programming isn't the direct opposite of OOP, but of imperative programming.

Now try to explain concatenative programming languages.

Name: Link:
Leave these fields empty (spam trap):
More options...
Verification: