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.
...
For further actions, you may consider blocking this person and/or reporting abuse
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
Not really understanding what you're saying here.
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.
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.
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).
That's ok. My focus was not on neuroscience studies and recent goals, but on programming :)
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.
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.
:))
You seem to be such a FP guru! :D
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.
Yep, you hit the point.
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.
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.
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.
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.
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.
There actually was an OS written in functional programming language: Genera OS. It was used to operate Symbolics Lisp Machines. :)
+1 for this guy.
If you're going to kick a Junior dev around at least be correct.
House.
Yeah, it was a provocation. Thanks for the link :)
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".