What's wrong with Object-Oriented Programming and Functional Programming
yinwang0.wordpress.com
What's wrong with Object-Oriented Programming and Functional Programming
1–10 of 145 posts
Re: What's wrong with Object-Oriented Programming and Functional Programming
#2So does the author deny the existence of any sort of domain where these paradigms would be "right"? Or are they universally "wrong"? Also, he states a view or philosophy: "everything is an object" and then he says "this is wrong because I disagree. functions are not objects". Wow. If you remove the commentary about scala and python, which is irrelevant to his philosophical thesis, then what is his argument? And why is it not a matter of just having a different definition?
Re: What's wrong with Object-Oriented Programming and Functional Programming
#3From a mathematical/theoretical point of view, this is an interesting article, but I think it misses the larger point of programming language paradigms. Yes, the PL researchers have their reasons for creating languages that are object oriented, functional, procedural, imperative, declarative, logical, etc. but those are rarely, if ever, the reason that programmers choose these languages.
Ultimately, the main purpose of a programming language is to convey intent to other programmers. If calling an object a function just because it has a `__call__` method makes it easier to convey intent, then it doesn't really matter that the object is not really a function. Personally, I'd be interested in any research into the ability to convey intent using these different paradigms.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#4This looks like an attack to functional programming mainly. And if you follow Haskell closely I think that the guys building it are well aware that the world is actually full of side effects. But the thing is that if they push the "pure" ideology to its limits they will uncover a number of useful things along the way. And that is the whole reason to stick to it. Maybe you don't find the usefulness of monads, but that doesn't mean that there is no value of composing part of you programs in this way. Otherwise you are stuck to the same old ways of doing things.
So going with pure has its benefits for all of us, but this does not mean that we should stick with something just because. Unfortunately the answer to most of the questions in programming/software development is: it depends.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#5This article is remarkably low on arguments, despite being so long. Just a few of its gems:
> OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects.
This has two problems:
1. It's factually wrong. Smalltalk functions are first-class objects.
2. It fails to explain why that would be wrong (assuming it were, you know, true).
The author does give the (poor) examples of Python and Scala, which -- in his opinion -- incorrectly call a function an object, because only the __call__ and apply are the "function objects" one is trying to define, but they were "kidnapped" and jailed into their wrapping objects. IMO, this is ontologically incorrect. The same can be said of any object's definition: if I have an object called PlaneVector, the "vector object" itself would actually be only its x and y properties, which I have kidnapped and jailed into my object.
The fact that this structure (the object I'm defining in my programming language) is not the same as its counterpart in the world of ideas (i.e. the plane vector in maths) should be fairly obvious, despite using the same generic term (i.e. object) to denote both.
Behold, then, the straw man:
> Most OO languages also lack correct implementations of first-class functions. An extreme is Java, which doesn’t allow functions to be passed as data at all. You can always wrap functions into objects and call them “methods”, but as I said, that’s kidnapping. The lack of first-class functions is the major reason why there are so many “design patterns” in Java. Once you have first-class functions, you will need almost none of the design patterns.
There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive.
I have less of a problem with the author's treatment of functional programming. What he's essentially trying to argue is that:
> Simulating them [side effects] with pure functions is doomed to be inefficient, complicated and even ugly. Have you noticed how easy it is to implement circular data structures or random number generators in C? The same is not true for Haskell.
IMO, this is true, but the isolation of side effects doesn't have to happen only by the ugly means he outlines next (i.e. monads) in every application. A typical CRUD application the web kids like to write can be written so that the only side effects involved are in fact modifications of the database, in which case the side effects are confined to SQL.
I also think there's an ontological error in this argument. Its foundation is that FP tries to "ignore" side effects even though they are real, but the examples the author gives are several layers of abstraction below. C also woefully ignores some of the side effects in the silicon (e.g. if you go low enough, calling a function with no side effects that does not even alter the state of the program will, in fact, alter the state of the underlying silicon, and quite substantially so), and I think it's reasonable to assume that we can't quite move the debate into which of those should be ignored or not.
All languages abstract the silicon away, and it's not only good that they do, it's what they were built for. I honestly don't miss hardwiring relays.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#6This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…
I can't speak for the author, but it seems he presented his argument poorly on OOP. I am not sure if it follows the same line of thought I have about OOP, but I regard OOP more as a mental model than a practical one. In that way I don't think everything is an object, more of there are nouns and there are verbs, and everything is to be described in such relationship. I prefer to think and work in component based approach though. Functional programming, on the other hand, is a set of rules over your mental model. Ultimately, I think, it boils down to your mental model which suits you best and, having said that, subjective reasoning. But that's how I think about it, doesn't have to be true.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#7This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…
This article's thesis is pretty much "both object-oriented and functional paradigms have limitations which become apparent when you push them to ridiculous extremes". Which is neither an interesting thesis nor one that is in dispute (except maybe among a very small number of people). But to be fair that thesis makes for far less linkbaity a title than "What’s Wrong with OOP and FP".
Re: What's wrong with Object-Oriented Programming and Functional Programming
#8This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…
I think the author also gets it wrong on the FP side, as he forgets the impure ones, like ML and Lispy ones, where side-effects are accepted.
This type of articles is also nonsense in a time and age where mainstream languages are going multi-paradigm and it is up to the developers to choose the best paradigms to model the application's architecture.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#9This looks like an attack to functional programming mainly. And if you follow Haskell closely I think that the guys building it are well aware that the world is actually full of side effects. But the thing is that if they push the "pure" ideology to its limits they will uncover a number of useful things along the way. And that is the whole reason to stick to it. Maybe you don't find the usefulness of monads, but that…
> But the thing is that if they push the "pure" ideology to its limits they will uncover a number of useful things along the way.
For example new elegant approaches to parallelism/concurrency that would be very difficult in an impure language.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#10This is an interesting article.
It is the first critique of functional programming I've read from someone who clearly knows their shit.
I plan to look at miniKanren more when I get the chance.
I done a fair amount of math though likely less than the author but I have a similar impression - the things that are hardest to understand aren't necessarily the best tool for every job, despite their beauty. And beautiful abstraction for its sake can be a dangerous anti-pattern as much as excess hacks and simplicity.