4 ms·

I think it's important to make the distinction between a successful idea and a good one. For example OO as a paradigm in mainstream languages (C++, Java) has be

I think it's important to make the distinction between a successful idea and a good one. For example OO as a paradigm in mainstream languages (C++, Java) has been very successful, despite it being more often than not a bad idea (e.g. horrible inheritance hierarchies are still implemented in this day and age, with dire consequences on code quality). In OP's article, OO is filed under "what works", which I strongly disagree with. If anything, software development works DESPITE OO, which in my experience constantly hinders progress because of rigid architectures.

charlysl 9y ago
I don't believe that the problem is OO in itself, but the way in which it is often used. You can write a bad program in any paradigm, and a good one too. FP is less popular and tends to attract a more curious crowd, who is more willing to learn how to use it well, whereas OO languages are used by everyone. On top of that, OO is build on top of a more expressive computation model, the stateful one, which because of its power is much more difficult to use well (and easier to abuse) than the much simpler functional/declarative model.
- Tomis02 9y ago
  > I don't believe that the problem is OO in itself, but the way in which it is often used. That's similar to what proponents of communism have been saying - "it does work if you do it right". The problem is that things start breaking down as soon as the project scale. For small programs a pure OO model can work, but increased complexity means people will definitely switch to a hybrid OO-(procedural|functional) style, simply because pure OO is untenable in large codebases.
  - charlysl 9y ago
    Haha, communism. Communism failed in Russia. But democracy failed in Russia too. Was communism the problem? I am half kidding, but I have wondered sometimes ...
raiflip 9y ago
As much as FP has made my life easier, have to disagree with you on OO. Any language/paradigm is capable of producing bad code. In my first job a high up manager brought in Clojure to a department filled with Java and OO acolytes. While the language was amazing, the Clojure code base was filled with gigantic let statements simulating imperative code, functional spaghetti, and given the lack of a good IDE difficult to debug (had to throw exceptions just to see variable values... shudders). The point is not that FP is bad, just that any tool in unskilled hands can produce bad code. Not sure what it is like for the industry at large, but from what I've seen a dominant paradigm in Java is to separate out model classes that are basically just structs with Service or Workflow classes that manipulate the data. It's questionable how much of that is still OO (at least when I started learning it the narrative was to put your code where your data is. POJOs are the opposite of that). Given say having a high level service that calls low level services and external system while returning a result produces code thats very easy to trace and provides solid abstraction to the calling code. Also if you've read Uncle Bob's data structure vs. Object dichotomy you'll see how Objects are objectively better in some scenarios, and OO languages give you powerful tools for objects. That said 100% agree with you on horrible inheritance hierarchies. What I think would be best is some course on how to combine OO and FP paradigms to get the best of both worlds (though tbh it'd probably be 90% FP with some OO).
- charlysl 9y ago
  "What I think would be best is some course on how to combine OO and FP paradigms to get the best of both worlds" If you want to find out, read "Concepts, Techniques, and Models of Computer Programming". It's mindblowing. It answers that question exactly. This is a dense but exceptionally written 1000 page book, but maybe you can just read section 4.8.5 to get an idea [1]. However, I think you will take more than just reading this bit, to understand the different models (many more than the 2 everybody talks about). Section 4.8.7 is actually "Using different models together", with the key "impedance matching" concept. The author sort of summarizes it here [2] There is also a mooc in edx, but it just scratches the surface of what's in the book [3] [1] https://books.google.com.vn/books?id=_bmyEnUnfTsC&pg=PA322&lpg=PA322&dq=picking+the+right+model+concepts+techniques&source=bl&ots=nCktxEdEEl&sig=G00yeodibw3ZSxOGoRdjF8x1cUQ&hl=en&sa=X&ved=0ahUKEwiLiOKOr-TXAhULabwKHVdIB7wQ6AEIJzAE#v=onepage&q=picking%20the%20right%20model%20concepts%20techniques&f=false https://books.google.com.vn/books?id=_bmyEnUnfTsC&pg=PA322&l... [2] http://lambda-the-ultimate.org/node/4698 http://lambda-the-ultimate.org/node/4698 [3] http://lambda-the-ultimate.org/node/4842 http://lambda-the-ultimate.org/node/4842

charlysl 9y ago

I don't believe that the problem is OO in itself, but the way in which it is often used. You can write a bad program in any paradigm, and a good one too. FP is less popular and tends to attract a more curious crowd, who is more willing to learn how to use it well, whereas OO languages are used by everyone. On top of that, OO is build on top of a more expressive computation model, the stateful one, which because of its power is much more difficult to use well (and easier to abuse) than the much simpler functional/declarative model.

Tomis02 9y ago
> I don't believe that the problem is OO in itself, but the way in which it is often used. That's similar to what proponents of communism have been saying - "it does work if you do it right". The problem is that things start breaking down as soon as the project scale. For small programs a pure OO model can work, but increased complexity means people will definitely switch to a hybrid OO-(procedural|functional) style, simply because pure OO is untenable in large codebases.
- charlysl 9y ago
  Haha, communism. Communism failed in Russia. But democracy failed in Russia too. Was communism the problem? I am half kidding, but I have wondered sometimes ...

raiflip 9y ago

As much as FP has made my life easier, have to disagree with you on OO. Any language/paradigm is capable of producing bad code. In my first job a high up manager brought in Clojure to a department filled with Java and OO acolytes. While the language was amazing, the Clojure code base was filled with gigantic let statements simulating imperative code, functional spaghetti, and given the lack of a good IDE difficult to debug (had to throw exceptions just to see variable values... shudders). The point is not that FP is bad, just that any tool in unskilled hands can produce bad code. Not sure what it is like for the industry at large, but from what I've seen a dominant paradigm in Java is to separate out model classes that are basically just structs with Service or Workflow classes that manipulate the data. It's questionable how much of that is still OO (at least when I started learning it the narrative was to put your code where your data is. POJOs are the opposite of that). Given say having a high level service that calls low level services and external system while returning a result produces code thats very easy to trace and provides solid abstraction to the calling code. Also if you've read Uncle Bob's data structure vs. Object dichotomy you'll see how Objects are objectively better in some scenarios, and OO languages give you powerful tools for objects. That said 100% agree with you on horrible inheritance hierarchies. What I think would be best is some course on how to combine OO and FP paradigms to get the best of both worlds (though tbh it'd probably be 90% FP with some OO).

charlysl 9y ago
"What I think would be best is some course on how to combine OO and FP paradigms to get the best of both worlds" If you want to find out, read "Concepts, Techniques, and Models of Computer Programming". It's mindblowing. It answers that question exactly. This is a dense but exceptionally written 1000 page book, but maybe you can just read section 4.8.5 to get an idea [1]. However, I think you will take more than just reading this bit, to understand the different models (many more than the 2 everybody talks about). Section 4.8.7 is actually "Using different models together", with the key "impedance matching" concept. The author sort of summarizes it here [2] There is also a mooc in edx, but it just scratches the surface of what's in the book [3] [1] https://books.google.com.vn/books?id=_bmyEnUnfTsC&pg=PA322&lpg=PA322&dq=picking+the+right+model+concepts+techniques&source=bl&ots=nCktxEdEEl&sig=G00yeodibw3ZSxOGoRdjF8x1cUQ&hl=en&sa=X&ved=0ahUKEwiLiOKOr-TXAhULabwKHVdIB7wQ6AEIJzAE#v=onepage&q=picking%20the%20right%20model%20concepts%20techniques&f=false https://books.google.com.vn/books?id=_bmyEnUnfTsC&pg=PA322&l... [2] http://lambda-the-ultimate.org/node/4698 http://lambda-the-ultimate.org/node/4698 [3] http://lambda-the-ultimate.org/node/4842 http://lambda-the-ultimate.org/node/4842