OOPs vs pure functional programming

The central tenet of object-oriented programming is perhaps the encapsulation of shared mutable state and behavior into a single unit, the object. This is beneficial because shared mutable state is mutable and shared, and by limiting what behaviors can mutate the state and how the state is shared, we make the program comprehensible.

Everybody can come up with a scheme to mutate state and share it, in a way that they themselves think they are able to understand all the implications of doing so but almost often they are wrong. There are hidden implications of having excessive mutable state listed below.

A real programmer should face mutable shared state with humility and not multiply it reveling in his own ability to understand it.

Object-oriented programming does not limit the programmer from increasing mutability and “sharedness” of state. It merely suggests good practices called “design patterns” that programmers follow them, when convenient, if at all.

As a consequence we have:

  • Good practices decided by purported experts like Gang of Four and people like Martin Fowler who do not have any good reason why they are right except that they are influential. They got influential by preaching feel good practices they discovered through experience which like religion feels right. And to be fair there is some truth in good design practices much like how basic religious tenets of mainstream religions are honorable. But excessive adherence to such practices often reveals their weaknesses.
  • The entire industry plagued with hipsters who come up with one framework/paradigm every week that follow the above mentioned good practices in various ways trying to find the next great magic formula for managing complexity.
  • Abstractions that are only used in job interviews to hire programmers to maintain poorly written code which does not use any of the said abstractions.
  • Debuggers are necessary because of excessive mutable state.
  • We have to constantly run the program to know if it works. Test-driven development, behavior drive development arises from this. This is called operational semantics as opposed to denotational semantics.
  • Formal verification methods involving mutable state is exceedingly complex.

Pure functional programming school of thought plans to create a brave new world order by liberating people from this mess. You have nothing to lose but your chains. 😉

  • Pure functional programming abolishes all mutable state. Mutability only exists as a syntactic sugar if at all, and only a simulacrum of mutation exists.
  • Pure functional programming abolishes all shared state.
  • As a consequence encapsulation is unnecessary and even detrimental. All we need is namespacing.
  • Pure functional programming does side effects without losing denotational semantic properties of functions.
  • Instead of relying on experts preaching good practices we rely on theoretical results which yield terseness and better denotational semantics i.e. the ability understand program behavior without running it.
  • Debuggers are rarely needed.
  • Test-driven development is replaced with proof-driven development and random test case generation.
  • Job interviews are about abstractions which are actually used in the code base not some nice to have design pattern postponed because of deadlines to gradually create messy code.
Advertisements

3 thoughts on “OOPs vs pure functional programming

  1. > encapsulation is unnecessary and even detrimental

    I cannot agree with you here. I’ve seen haskell codebase of 65k lines long, and my task was to encapsulate things for it to be taken apart.

    Encapsulation is a way for _leather bags_ we are to minimise amount of objects to hold in memory at once; it’s not an OOP invention.

  2. You need debugger, because you are not perfect being and is capable of making errors in the first place.

    Proofs are, in fact, much less bearable than tests.

    This leads to manual fudges in proofs and usage of `auto` and `crush` tactics that behave as gradient descent in the proof space. If they find a proof, you can’t know is it sane or they made a shortcut using existing variable of some type.

    So, for instance, any proof assistants if asked to prove existence of function returning `Maybe` using automatic tactics will surely answer “yes”, because, you know, there is `Nothing`.

    And if you are doing proofs manually, you are writing another program, in fact, so it gave you nothing, but a wall of code to hide fudges behind.

    I personally prefer property-based test frameworks like `quickcheck`/`smallcheck`. They cannot prove, but at least they give me counterexamples to work with.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s