5 ms·

Yeah I think you missed it. "Answering this simple question requires knowing everything. The whole execution history of foo. The whole codebase. You name it, yo

Yeah I think you missed it. "Answering this simple question requires knowing everything. The whole execution history of foo. The whole codebase. You name it, you have to keep it in your head." Here's the thing about OOADP (Note I didn't just use OOP): it gives you a simple methodology to solve problems and know where to put stuff. You don't know everything, because the assumption is that the codebase is going too big to know everything. But what you _do_ know is where things go; an organization of nouns. Good large projects have a design theme that's easy to understand and gives you the mental tools to reason about which pieces need your attention at any one time. OOP is all about working on little pieces at a time and not worrying about knowing everything. It has a lot of problems, but so does every paradigm. I've become a huge functional programming fan over the last couple of years, but I can tell you very frankly that nothing beats OOAD. Nothing. It is a gift from the gods. It allows you to take any problem and make it trivial. Large amounts of wiring will be required. The thing here is that as you start generalizing OOP, you being making this bastard thing that is part OOP and part FP. Or your codebase runs off the rails and becomes a hodgepodge of junk. Or you enter into the "Kingdom of Nouns". The ways to screw up are legion. Dependency issues are also a freaking nightmare in OOP. That's why OOP and some sort of TDD go hand-in-hand. I'm mostly with the author, but I don't think he understands the full extent of what he's talking about. OOP (and TDD) is a great tool for large, complex, shared codebases. Even though I'm a huge fan of FP, I remain very skeptical that it can scale well to 100+ developer efforts. I think to truly criticize something like this, you should know both how it's awesome and how it sucks, not just how it sucks.

dustingetz 15y ago
i read your post twice because its the top comment from my view, and while I see you wrote a lot, I don't think you actually said anything. are you interested in clarifying?
- DanielBMarkham 15y ago
  Sorry about that. Here's the underlying philosophy of OOP not covered by the original article [philosophy described]. Here are some strengths not covered by the original article [salient points covered]. Author managed to share his frustration with the structural details of the paradigm without conveying that he understood the bigger picture of its actual effective use. That's a recap. Work any better for you now? Or did you not understand my description of how the philosophy works or what the strengths were?
  - spacemanaki 15y ago
    dustingetz's criticism was a bit harsh, but I kind of agree with him. You aren't concretely illuminating how those qualities of OOP (or OOADP) are advantages or are unique to OO. I would really value more clarification from you on this, given your prolific HN presence and experience. I genuinely want to learn more about this (see my other comment in this thread), but I've struggled to find really good, motivating examples in the past. > nothing beats OOAD. Nothing. It is a gift from the gods. It allows you to take any problem and make it trivial. I'm supremely skeptical of claims like these. I could say that same thing about... anything. But that's just not enough. > Or your codebase runs off the rails and becomes a hodgepodge of junk. Or you enter into the "Kingdom of Nouns". The ways to screw up are legion. So how do you avoid this? How can I develop an intuition about good OO design? You talk about TDD a bit, but you can do TDD with functional programming too, and in many ways it's easier (less need for mock objects and dependency injection, which are as good an example of incidental complexity as I can think of). > I think to truly criticize something like this, you should know both how it's awesome and how it sucks, not just how it sucks. Yes! Please, help me learn how awesome OOP can be, and get to a place where I can criticize OOP more brutally. ;) Seriously though, what open source code or books would you recommend? I looked here: http://hn-books.com/#BC=0&EC=0&FC=0&Q0=11&QC=1 http://hn-books.com/#BC=0&EC=0&FC=0&Q0=11&QC... ... but it wasn't clear to me which of these books would be best. Many of them are a bit too specific. The functional programming proponents who have convinced me most are Clojure people. Rich Hickey's simplicity talk, his talks and mini-essays on state and time, Stuart Halloway's similar talk on simplicity, the idea of values over identities, dealing with basic data structures (maps, vectors, sets) over burying data in classes and domain specific APIs, separating out OO features to get "OO a la carte" ... it's very compelling stuff, and most of it is about striving for simplicity and tearing out unnecessary complexity. That's where I'm coming from in my skepticism of OOP, because most of it seems to make things more complex than they need to be, with not a lot of gain. On the other hand, I'm pretty green, so I know that much of this could just be naive fantasy, since I've never had to deal with massive codebases being hacked on by 100+ programmers, neither in FP or OOP languages/styles.
    - DanielBMarkham 15y ago
espeed 15y ago
But what you _do_ know is where things go; an organization of nouns. That's what Clojure namespaces provide. Regardless, the mutable state of objects doesn't align well with multi-core concurrency so its thread-lock complexity is rendering it obsolete.

dustingetz 15y ago

i read your post twice because its the top comment from my view, and while I see you wrote a lot, I don't think you actually said anything. are you interested in clarifying?

DanielBMarkham 15y ago
Sorry about that. Here's the underlying philosophy of OOP not covered by the original article [philosophy described]. Here are some strengths not covered by the original article [salient points covered]. Author managed to share his frustration with the structural details of the paradigm without conveying that he understood the bigger picture of its actual effective use. That's a recap. Work any better for you now? Or did you not understand my description of how the philosophy works or what the strengths were?
- spacemanaki 15y ago
  dustingetz's criticism was a bit harsh, but I kind of agree with him. You aren't concretely illuminating how those qualities of OOP (or OOADP) are advantages or are unique to OO. I would really value more clarification from you on this, given your prolific HN presence and experience. I genuinely want to learn more about this (see my other comment in this thread), but I've struggled to find really good, motivating examples in the past. > nothing beats OOAD. Nothing. It is a gift from the gods. It allows you to take any problem and make it trivial. I'm supremely skeptical of claims like these. I could say that same thing about... anything. But that's just not enough. > Or your codebase runs off the rails and becomes a hodgepodge of junk. Or you enter into the "Kingdom of Nouns". The ways to screw up are legion. So how do you avoid this? How can I develop an intuition about good OO design? You talk about TDD a bit, but you can do TDD with functional programming too, and in many ways it's easier (less need for mock objects and dependency injection, which are as good an example of incidental complexity as I can think of). > I think to truly criticize something like this, you should know both how it's awesome and how it sucks, not just how it sucks. Yes! Please, help me learn how awesome OOP can be, and get to a place where I can criticize OOP more brutally. ;) Seriously though, what open source code or books would you recommend? I looked here: http://hn-books.com/#BC=0&EC=0&FC=0&Q0=11&QC=1 http://hn-books.com/#BC=0&EC=0&FC=0&Q0=11&QC... ... but it wasn't clear to me which of these books would be best. Many of them are a bit too specific. The functional programming proponents who have convinced me most are Clojure people. Rich Hickey's simplicity talk, his talks and mini-essays on state and time, Stuart Halloway's similar talk on simplicity, the idea of values over identities, dealing with basic data structures (maps, vectors, sets) over burying data in classes and domain specific APIs, separating out OO features to get "OO a la carte" ... it's very compelling stuff, and most of it is about striving for simplicity and tearing out unnecessary complexity. That's where I'm coming from in my skepticism of OOP, because most of it seems to make things more complex than they need to be, with not a lot of gain. On the other hand, I'm pretty green, so I know that much of this could just be naive fantasy, since I've never had to deal with massive codebases being hacked on by 100+ programmers, neither in FP or OOP languages/styles.
  - DanielBMarkham 15y ago

espeed 15y ago

But what you _do_ know is where things go; an organization of nouns. That's what Clojure namespaces provide. Regardless, the mutable state of objects doesn't align well with multi-core concurrency so its thread-lock complexity is rendering it obsolete.