DEV Community

Object-Oriented Programming Strikes Back!

Riccardo Cardin on August 10, 2017

Originally posted on: Big ball of mud Disclaimer: the post contains some humor. If you are sensible to humorism, please, do not continue to read. ...
Collapse
 
spearofsolomon profile image
Nathan Spears

The funny thing about this

| At first sight, object-oriented programming is very close to how we perceive reality.

is that we don't actually perceive reality as a set of objects.

| It misunderstands the fundamental fact about evolution, which is that it’s about fitness functions—mathematical functions that describe how well a given strategy achieves the goals of survival and reproduction. The mathematical physicist Chetan Prakash proved a theorem that I devised that says: According to evolution by natural selection, an organism that sees reality as it is will never be more fit than an organism of equal complexity that sees none of reality but is just tuned to fitness.

We actually perceive reality using a set of functions! :D

Collapse
 
weswedding profile image
Weston Wedding

Not really understanding what you're saying here.

Collapse
 
spearofsolomon profile image
Nathan Spears • Edited

It's easy to think that we perceive a world of objects, but we don't.

We perceive a world of tools and obstacles and add a layer of object definition on top of that. So fundamentally, we see things in terms of their functional use: ie, we actually interpret the world as a functional place rather than an object-oriented place.

theatlantic.com/science/archive/20...

And furthermore, it seems that our consciousness is also composed of lots of functional streams in our brains.

Thread Thread
 
riccardo_cardin profile image
Riccardo Cardin

I partially agree with you. I think you're really describing how we behave, and not how we perceive reality. You said that we peceive "tools" and "obstacles": these are objects. ;)

Anyway, interesting point of view. Many thanks.

Thread Thread
 
spearofsolomon profile image
Nathan Spears

It's not a point of view, it's how neuroscience is working out our interpretation of the world.

A tool is something that has utility (this input gives this output). An obstacle is something in the way. An object is a layer of interpretation on top of those properties.

In other words, you can sit on a chair without needing to know that it's a chair. Say that you were blindfolded and someone put your hands on a flat place. You would be able to turn around and sit on it without needing to know anything else about it - it's a sitting place. That's the utility. Functionally you input your butt and output your body at rest.

Take off the blindfold and you could see that it's a chair, or a stool, or a stump, or a cliff's edge. Doesn't matter, they are all sitting places. You perceive the object after you perceive the utility, but the natural (and completely reasonable) assumption that people had for thousands of years was that we perceived the object and then perceived the utility. Objects are results of categorization made possible by consciousness, but the systems that consciousness is built on don't require objects to operate (obviously, or the animals who use them would be unable to operate).

Thread Thread
 
riccardo_cardin profile image
Riccardo Cardin

That's ok. My focus was not on neuroscience studies and recent goals, but on programming :)

Thread Thread
 
spearofsolomon profile image
Nathan Spears

Sure. My point is that learning to see problem-solving techniques as composable functions may actually be closer to our innate problem-solving paradigms than Object-oriented techniques are.

Collapse
 
uberto profile image
Uberto Barbini

Some random thoughts:

  • some applications are definitely better suited by one style or other. Even with arrows and bananas doing UI stuff in Haskell is still quite painful.

  • if we take that Alan Kay knows about OOP, then Java, C# etc. are not really OOP. Which bring us to the conclusion that we are switching from pseudo-oop to pseudo-fp.

  • SOLID... well don't let me start about SOLID. It seemed a good idea at the time and we can leave it at that.

  • when you start seeing Catamorphisms everywhere, then you can call yourself functional programmer.

:))

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

You seem to be such a FP guru! :D

Collapse
 
k2t0f12d profile image
Bryan Baldwin

These are not antitheses of the other, nor are they the only "orientation" in programming, nor are they or any other methodology a panacea for effective programming. They are tools. And often the wrong ones to use.

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

Yep, you hit the point.

Collapse
 
jervine791 profile image
john ervine • Edited

FP is great in the right hands. Making the transition from OOPs can be a difficult one. Having written Clojure for 2 years, it took a solid year to adapt and write clean maintainable code. Once you get over the learning bump, programming in a FP paradiam is great fun. The biggest thing I got from the experience was a new way of looking at problems. Alot of these techniques can be applied in languages like Java.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

A modern application shouldn't be written without using concepts from a variety of different paradigms. I'm trying to keep a good overview of them here.

That said, I don't think functional programming is good at modelling the state transitions of a system, and should be limited to calculation domains where it is a preferred choice. The problem with state modelling via state variables and monads is that it doesn't actually model what the system is doing anymore. It's a bad mapping from an imperative, concurrent, domain into a functional one.

The relation between learning curve and level of errors is just wrong. By such logic I could start writing my C++ using nothing but Korean language for comments and symbol names and my programming would suddenly have fewer errors. An inappropriate choice of paradigm is what leads to errors, and this is the reason why all apps generally use bits of all paradigms.

Collapse
 
rubberduck profile image
Christopher McClellan

I'm not sure I can agree with your assertion that state transitions are less clean in FP. In OOP, we model state transitions by delegating to objects that perform an appropriate action for the current state. In FP we model state transitions by delegating to a function that performs an appropriate action for the given state. It's just two ways to skin the same cat.

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

I agree with the first part of your comment, that reflects exactly the same conclusions I came to. However, you misunderstood the graph that relates learning curves with probability of introducing an error in a program.

Collapse
 
davedecahedron profile image
David Howell

I'm really surprised there isn't some paper proving that OOP and functional are two manifestations of the same thing. For example this article on how category theory can be implemented in OOP - using Java as the example reperiendi.wordpress.com/2007/11/0...
Mostly via interfaces.

I also think it's interesting to note that Martin Odersky designed Scala as a "fusion of functional and object oriented paradigms". The reasons for that are partly to ease the learning curve and to enable compatibility with existing Java (and .NET, whatever happened to Scala.Net?) although more importantly to create a composable, modular, scalable language that benefits from the best of multiple paradigms. Essentially, Scala is not a Functional only language, by design.

Collapse
 
voins profile image
Alexey Voinov

There actually was an OS written in functional programming language: Genera OS. It was used to operate Symbolics Lisp Machines. :)

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

+1 for this guy.

Collapse
 
burito profile image
Daniel Burke

Have you ever heard about an operating system written in a functional programming language? Nope.

If you're going to kick a Junior dev around at least be correct.

House.

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

Yeah, it was a provocation. Thanks for the link :)

Collapse
 
riccardo_cardin profile image
Riccardo Cardin

I do not agree with you. I mean, you're right when you said that both paradigms have their own use cases. However, I think that you can achieve the best of both using them in conjunction. "FP in a OOP shell".