19 ms·

Everything sucks, they just all suck differently. I still think OO provides a pretty easy mental framework for programming. You can get good results. Bit of

Everything sucks, they just all suck differently. I still think OO provides a pretty easy mental framework for programming. You can get good results. Bit of discipline without going crazy and it works really effectively. Despite its shortcomings.

tootie 8y ago
OO is the worst programming paradigm in the world except for all the others.
- markdog12 8y ago
  This is a decently clever Churchillian quip. At the very least, it does not deserve downvotes.
- tombert 8y ago
  Admittedly I'm somewhat of a FP fanboy, but I seriously cannot disagree with you more on this. Functional Programming (and Logic Programming) are better than other paradigms because, unlike Java (or C++, or C#...) there is an emphasis on correctness, and the people working on FP compilers (like Haskell and Idris) are utilizing mathematics to do this. No idea on your opinion on mathematics, but to me Math/Logic reign supreme; the more mathematically-bound your program is, the less likely it is to do something you don't want later. Compare this to Java. It's 2019, and we're still doing `if (x==null) return null` all over the place (I'm aware that the option type exists but that doesn't really help when it's not enforced and none of my coworkers use it). How about having to create six different files for something that I could have written in 20 lines in Haskell? Or how about the fact that the type system exists to help with optimizations, and due to a lack of support for structured typing, it can only be useful for that. I realize that I'm picking on Java, but Java is the biggest target when it comes with OOP as the industry understands it. I personally cannot stand having to create fifty files do to something like a database wrapper, and in Java that's effectively the only way to program.
  - libria 8y ago
    > How about having to create six different files Took me a few reads but it's better stated "six different classes". At first I was confused about why you rely on `java.io.File` for business logic. So, if I'm stuck on JVM, what's my FP alternative that compiles and runs comparatively? Clojure? Scala?
    - bsder 8y ago
      Clojure. If I'm stuck in JVM-land, Clojure followed by straight, modern Java would be my choices.
    - pkolaczk 8y ago
      Scala. Particularly Scala 3. Because it is principled but also very pragmatic.
      - hota_mazi 8y ago
        Scala failed because it's the opposite of pragmatic. If you're looking for pragmatic, take a look at Kotlin. As for Scala 3, it's still years away, if it ever comes out. And when it does, there's little reason to think its goals will be different from what Scala 2 was (an academic language) since it's the same team as Scala 2 writing it.
        jhomedall 8y ago
        In what way is Scala not pragmatic?
        hota_mazi 8y ago
        It's a language that's aimed more at research, producing papers for conferences, and financing the EPFL and its PhD students than at users in the real world. There's absolutely nothing wrong with that, by the way, I love studying all the advanced concepts that Scala has pioneered over the years. But it's also the reason why it's largely in decline and why Kotlin has taken the industrial world by storm: because it is a pragmatic language.
- westoncb 8y ago
  I think this is pretty insightful. It's easy to hate on OO because of something along the lines of it not being a neat mathematical formalism, which can facilely be argued as strictly a deficiency: if you don't look too closely, it certainly appears as only a deficiency. I think a deeper look inevitably runs into two things: (1) certain domains are more easily approached through spare mathematical formalisms than others. E.g. if the domain you're modeling is already most easily thought about in terms of compositions of mathematical transformations, you should probably model it functionally. (2) Finding a declarative characterization of the results you'd like, or a neat chain of functional compositions which produce it, typically takes more work up front. (For many projects, the initial work up front is worth it—but for lots and lots of others, it's essentially over engineering.) OO is often not 'ideal,' but frequently, solidly pragmatic. As a paradigm, the aesthetic behind it reminds me of TypeScript's designers intentionally foregoing soundness of the type system.
harimau777 8y ago
I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of functional programming (immutability, functional purity, construction via composition, and declarative programming) serve as a check that prevents things from getting out of control. That being said, I think it's worth considering that all of the "core principles" of FP that I mentioned could be incorporated into OO. It also seems like FP can be more prone to out of control syntax (e.g. unwise use of point free style).
- cwbrandsma 8y ago
  Forces discipline is a double edged sword. It can help you keep things clean and understandable, but it can also limit things. For example: I am pretty good with react and redux, but I was more productive with JQuery. JQuery doesn’t have the forced discipline of react+redux, but it gets the job done. At the same time, I’ve seen larger amounts of crap JQuery code than React+Redux. The real issue: discipline has to be learned, often by experience, it isn’t forced. If you force it, then no one knows why things are they way they are.
  - simplify 8y ago
    > If you force it, then no one knows why things are they way they are. It's more accurate to say "if you don't teach why' then no one knows why". Forcing or not has nothing to do with it. I would argue "forcing" is strictly better, since learning discipline requires experience in doing things in every other wrong way. While that's great for learning on your own, I wouldn't want developers to "learn discipline" like this in production.
- Consultant32452 8y ago
  Just my personal anecdote. The only functional programming languages I have extensive experience with are C and JS. I have NEVER seen a sensibly organized or maintained medium to large sized C or JS application. Every time it's been total chaos. In Java projects, there's a 50/50 shot of it being moderately sensible. I'm confident other people have completely different experience. Based on your post it sounds like you have had a different experience, and I have no trouble believing that. Anyways, just my $0.02.
gboudrias 8y ago
Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to get, it's just ridiculous overengineering 95% of the time. Same goes for a lot of stuff in OO. I attribute it to the corporate mindset it seems to thrive in, but I could be wrong.
- wnevets 8y ago
  I feel like what happened to agile development happened to OOP, people morphed it into something that it was never meant to be.
  - TheCondor 8y ago
    Yeah, somewhere it stopped being about modeling your problem and it became a code organization technique. There was an incredible effort to formalize different modeling techniques/languages but it’s dried up. It seems to be what we do, I’d say fp is in the same place. My CS program was heavily built around the ML family of languages, specifically Standard ML, with the algebraic types, functions, pattern matching (on your types,) etc. it seems like that “functional programming” is a radically different thing than what people do in js or erlang and call it that. It all comes around, I guess, static types were pretty gauche 10-15 years back and now how many folks are using typescript to make their js better?
  - Nasrudith 8y ago
    Evolutionary design is that way in general really. Your intentions never matter - just what it can be used for.
- Consultant32452 8y ago
  In my opinion OO design is valuable in extremely large code bases and/or code bases that will likely exist for decades and go through multiple generations of significant refactoring. With respect to your setters and getters question, particularly in regards to Python... The @Property feature in Python is just a specific implementation of the setters/getters OO design principle. I can easily be convinced typing foo.x is better than foo.getX(), but I have a hard time having a strong emotional reaction to one vs the other if the language allows them to have the same benefits.
euske 8y ago
I think OO can work because in many problems we only focus on one thing at a time. If multiple objects with equal complexity/importance are involved, OO can get sticky (e.g. which object should invoke a method, etc). I think Joe's article is intentionally provocative to make a point, but I'd like to see more discussions about when and why OO doesn't work well sometimes and what the course of actions we should take.
- jstimpfle 8y ago
  I've upvoted you because you spotlighted a very important issue. In OOP we are supposed to think of a program as little pseudo-isolated programs that somehow work together to fulfill the technical requirements. This model works where it actually represents the real world: Mostly, in distributed systems. In other areas, it just leads to overengineered piecemeal crap that is incredibly hard to understand. Where you can get control over what happens, you absolutely should get it. Don't act like your program was a thousand little independent components that have their own mind and lifes. Because it isn't like that, and if it was, there was no way you could actually get in control of these to make them produce a very specific outcome. So the only reason why many OOP programs sort-of work is because programmers never actually respect the abstractions that they set up by defining so many classes and methods. To get the program to work, one needs to know very precisely what each class does in each cases. In the end OOP is just a terrible farce since there is no rhyme and reason for all these classes. It's needless bureaucracy, and prevents us from structuring programs in a more efficient and maintainable way.
kumarvvr 8y ago
> I still think OO provides a pretty easy mental framework for programming Very true. It's a practical solution to a complex problem. However, when systems get complex, it becomes very hard to find the right object / type to bottle up logic. Perhaps, then, a mix of OO and functional is the solution.
weberc2 8y ago
OO languages work effectively in spite of OO features. Sounds like a hot take, but throw away inheritance altogether (or use it to automatically delegate to some component, like a dodgier version of struct embedding in Go), use interfaces if the language doesn’t support first class functions, etc and you’ll be effective, which is to say, write it like you would write Go or Rust or similar.
overgard 8y ago
That sounds wise but it doesn't really mean anything. There are things that suck about a Ford Pinto and there are things that suck about about a Tesla Model S, but saying that they both have their downsides is technically true while obscuring the fact that the Tesla is a muuuuuuuuuuuuuuch better car.
- polynomial 8y ago
  Is there a name for this particular argumentative fallacy?
  - Nasrudith 8y ago
    False equivalence - even if they are similar in one respect doesn't erase the other differences. Saying both a bicycle and a truck can move things on roads and can kill you if run over by one are technically true but misses many other larger differences.
- blub 8y ago
  Good choice of example. Both the Pinto and Tesla, unlike most cars kill(ed) their owners in surprising ways.
kazinator 8y ago
The basic situation is this. We often have a situation in which N operations contain M cases (for M different types). Without OOP, we have the ugly organization of writing N functions that each dispatch M cases of code by pattern matching or switching on a numeric type field or whatever. OOP lets us break these pieces of logic into separate methods. And then in the physical organizationof the program, we can group those methods by type. For any given type, we have N methods: each one implements one of those N functions just for that type. This is a better organization because if we change some aspect of a type, all the changes are done in one place: the implementation file or section of file for that type. Or if a new type is added, we just add N methods in a new file or section; we don't have to change the code of numerous functions to introduce new cases into them. Those who write articles opposing OOP never seem to constructively propose an attractive alternative for this situation. It is this attractive program organization which swayed developers toward OOP, or even full blown OOP evangelism. It's not because it was hyped. OOP has concrete benefits that are readily demonstrable and applicable. OOP is what allows your operating system to support different kinds of file systems, network adapters, network protocols, I/O devices and so on. It's unimaginable that the read() system call in your kernel would contain a giant switch() on device type leading to device-specific code, which has to be maintained each time a new driver is added.
- xKingfisher 8y ago
  Well yeah, that's the expression problem[0]. With OOP I can add a new datatype easily, but when I want to extend the behavior of that type I now need to go to M different places. With a functional style I only need to do one. You're open on types but closed over behaviors. Functional styles are the opposite. In some sense, I would even go as far as saying the idealized 'UNIX philosophy' is a degenerate example of this. We have a very limited set of types (the file) and a bunch of independently implemented behaviors. Imagine implementing sed or grep on a per-file (or per filesystem) basis. These both get really interesting when you consider libraries/user extensibility, since unrelated actors could now add either new types or new methods. Most languages just punt on this by banning one or the other. A pattern matching style would allow me to add a new sql() system call to query into the filesystem. Look at how much trouble there is adding new features to CSS, TCP, Java, etc trying to coordinate among so many different actors. Or consider the case of a programming language AST. I can make a pretty printer, an interpreter, an optimizer, a type checker, a distributed program runner. But trying to do that with an OOP style is much harder for a large AST. At the end of the day, we have NxM (type, behavior) pairs and there are pros/cons to each way of slicing them. [0] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
bsder 8y ago
> I still think OO provides a pretty easy mental framework for programming. You can get good results. The problem is that OOP is a slate of something like 18 characteristics and no language ever picks the same choices. That having been said, the big problem with (especially early) OOP is that "Is"/"IsA" (aka structural inheritance) is the primary abstraction. Unfortunately, "Is"/"IsA" is a particularly lousy choice--practically anything ("Contains" or "Accesses" or ...) is better. Most of the modern languages designed in the past 10-20 years reflect this--"Traits"/"Interfaces" seems to be what everybody has settled around.

tootie 8y ago

OO is the worst programming paradigm in the world except for all the others.

markdog12 8y ago
This is a decently clever Churchillian quip. At the very least, it does not deserve downvotes.
tombert 8y ago
Admittedly I'm somewhat of a FP fanboy, but I seriously cannot disagree with you more on this. Functional Programming (and Logic Programming) are better than other paradigms because, unlike Java (or C++, or C#...) there is an emphasis on correctness, and the people working on FP compilers (like Haskell and Idris) are utilizing mathematics to do this. No idea on your opinion on mathematics, but to me Math/Logic reign supreme; the more mathematically-bound your program is, the less likely it is to do something you don't want later. Compare this to Java. It's 2019, and we're still doing `if (x==null) return null` all over the place (I'm aware that the option type exists but that doesn't really help when it's not enforced and none of my coworkers use it). How about having to create six different files for something that I could have written in 20 lines in Haskell? Or how about the fact that the type system exists to help with optimizations, and due to a lack of support for structured typing, it can only be useful for that. I realize that I'm picking on Java, but Java is the biggest target when it comes with OOP as the industry understands it. I personally cannot stand having to create fifty files do to something like a database wrapper, and in Java that's effectively the only way to program.
- libria 8y ago
  > How about having to create six different files Took me a few reads but it's better stated "six different classes". At first I was confused about why you rely on `java.io.File` for business logic. So, if I'm stuck on JVM, what's my FP alternative that compiles and runs comparatively? Clojure? Scala?
  - bsder 8y ago
    Clojure. If I'm stuck in JVM-land, Clojure followed by straight, modern Java would be my choices.
  - pkolaczk 8y ago
    Scala. Particularly Scala 3. Because it is principled but also very pragmatic.
    - hota_mazi 8y ago
      Scala failed because it's the opposite of pragmatic. If you're looking for pragmatic, take a look at Kotlin. As for Scala 3, it's still years away, if it ever comes out. And when it does, there's little reason to think its goals will be different from what Scala 2 was (an academic language) since it's the same team as Scala 2 writing it.
      - jhomedall 8y ago
        In what way is Scala not pragmatic?
        hota_mazi 8y ago
        It's a language that's aimed more at research, producing papers for conferences, and financing the EPFL and its PhD students than at users in the real world. There's absolutely nothing wrong with that, by the way, I love studying all the advanced concepts that Scala has pioneered over the years. But it's also the reason why it's largely in decline and why Kotlin has taken the industrial world by storm: because it is a pragmatic language.
westoncb 8y ago
I think this is pretty insightful. It's easy to hate on OO because of something along the lines of it not being a neat mathematical formalism, which can facilely be argued as strictly a deficiency: if you don't look too closely, it certainly appears as only a deficiency. I think a deeper look inevitably runs into two things: (1) certain domains are more easily approached through spare mathematical formalisms than others. E.g. if the domain you're modeling is already most easily thought about in terms of compositions of mathematical transformations, you should probably model it functionally. (2) Finding a declarative characterization of the results you'd like, or a neat chain of functional compositions which produce it, typically takes more work up front. (For many projects, the initial work up front is worth it—but for lots and lots of others, it's essentially over engineering.) OO is often not 'ideal,' but frequently, solidly pragmatic. As a paradigm, the aesthetic behind it reminds me of TypeScript's designers intentionally foregoing soundness of the type system.

harimau777 8y ago

I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of functional programming (immutability, functional purity, construction via composition, and declarative programming) serve as a check that prevents things from getting out of control. That being said, I think it's worth considering that all of the "core principles" of FP that I mentioned could be incorporated into OO. It also seems like FP can be more prone to out of control syntax (e.g. unwise use of point free style).

cwbrandsma 8y ago
Forces discipline is a double edged sword. It can help you keep things clean and understandable, but it can also limit things. For example: I am pretty good with react and redux, but I was more productive with JQuery. JQuery doesn’t have the forced discipline of react+redux, but it gets the job done. At the same time, I’ve seen larger amounts of crap JQuery code than React+Redux. The real issue: discipline has to be learned, often by experience, it isn’t forced. If you force it, then no one knows why things are they way they are.
- simplify 8y ago
  > If you force it, then no one knows why things are they way they are. It's more accurate to say "if you don't teach why' then no one knows why". Forcing or not has nothing to do with it. I would argue "forcing" is strictly better, since learning discipline requires experience in doing things in every other wrong way. While that's great for learning on your own, I wouldn't want developers to "learn discipline" like this in production.
Consultant32452 8y ago
Just my personal anecdote. The only functional programming languages I have extensive experience with are C and JS. I have NEVER seen a sensibly organized or maintained medium to large sized C or JS application. Every time it's been total chaos. In Java projects, there's a 50/50 shot of it being moderately sensible. I'm confident other people have completely different experience. Based on your post it sounds like you have had a different experience, and I have no trouble believing that. Anyways, just my $0.02.

gboudrias 8y ago

Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to get, it's just ridiculous overengineering 95% of the time. Same goes for a lot of stuff in OO. I attribute it to the corporate mindset it seems to thrive in, but I could be wrong.

wnevets 8y ago
I feel like what happened to agile development happened to OOP, people morphed it into something that it was never meant to be.
- TheCondor 8y ago
  Yeah, somewhere it stopped being about modeling your problem and it became a code organization technique. There was an incredible effort to formalize different modeling techniques/languages but it’s dried up. It seems to be what we do, I’d say fp is in the same place. My CS program was heavily built around the ML family of languages, specifically Standard ML, with the algebraic types, functions, pattern matching (on your types,) etc. it seems like that “functional programming” is a radically different thing than what people do in js or erlang and call it that. It all comes around, I guess, static types were pretty gauche 10-15 years back and now how many folks are using typescript to make their js better?
- Nasrudith 8y ago
  Evolutionary design is that way in general really. Your intentions never matter - just what it can be used for.
Consultant32452 8y ago
In my opinion OO design is valuable in extremely large code bases and/or code bases that will likely exist for decades and go through multiple generations of significant refactoring. With respect to your setters and getters question, particularly in regards to Python... The @Property feature in Python is just a specific implementation of the setters/getters OO design principle. I can easily be convinced typing foo.x is better than foo.getX(), but I have a hard time having a strong emotional reaction to one vs the other if the language allows them to have the same benefits.

euske 8y ago

I think OO can work because in many problems we only focus on one thing at a time. If multiple objects with equal complexity/importance are involved, OO can get sticky (e.g. which object should invoke a method, etc). I think Joe's article is intentionally provocative to make a point, but I'd like to see more discussions about when and why OO doesn't work well sometimes and what the course of actions we should take.

jstimpfle 8y ago
I've upvoted you because you spotlighted a very important issue. In OOP we are supposed to think of a program as little pseudo-isolated programs that somehow work together to fulfill the technical requirements. This model works where it actually represents the real world: Mostly, in distributed systems. In other areas, it just leads to overengineered piecemeal crap that is incredibly hard to understand. Where you can get control over what happens, you absolutely should get it. Don't act like your program was a thousand little independent components that have their own mind and lifes. Because it isn't like that, and if it was, there was no way you could actually get in control of these to make them produce a very specific outcome. So the only reason why many OOP programs sort-of work is because programmers never actually respect the abstractions that they set up by defining so many classes and methods. To get the program to work, one needs to know very precisely what each class does in each cases. In the end OOP is just a terrible farce since there is no rhyme and reason for all these classes. It's needless bureaucracy, and prevents us from structuring programs in a more efficient and maintainable way.

kumarvvr 8y ago

> I still think OO provides a pretty easy mental framework for programming Very true. It's a practical solution to a complex problem. However, when systems get complex, it becomes very hard to find the right object / type to bottle up logic. Perhaps, then, a mix of OO and functional is the solution.

weberc2 8y ago

OO languages work effectively in spite of OO features. Sounds like a hot take, but throw away inheritance altogether (or use it to automatically delegate to some component, like a dodgier version of struct embedding in Go), use interfaces if the language doesn’t support first class functions, etc and you’ll be effective, which is to say, write it like you would write Go or Rust or similar.

overgard 8y ago

That sounds wise but it doesn't really mean anything. There are things that suck about a Ford Pinto and there are things that suck about about a Tesla Model S, but saying that they both have their downsides is technically true while obscuring the fact that the Tesla is a muuuuuuuuuuuuuuch better car.

polynomial 8y ago
Is there a name for this particular argumentative fallacy?
- Nasrudith 8y ago
  False equivalence - even if they are similar in one respect doesn't erase the other differences. Saying both a bicycle and a truck can move things on roads and can kill you if run over by one are technically true but misses many other larger differences.
blub 8y ago
Good choice of example. Both the Pinto and Tesla, unlike most cars kill(ed) their owners in surprising ways.

kazinator 8y ago

The basic situation is this. We often have a situation in which N operations contain M cases (for M different types). Without OOP, we have the ugly organization of writing N functions that each dispatch M cases of code by pattern matching or switching on a numeric type field or whatever. OOP lets us break these pieces of logic into separate methods. And then in the physical organizationof the program, we can group those methods by type. For any given type, we have N methods: each one implements one of those N functions just for that type. This is a better organization because if we change some aspect of a type, all the changes are done in one place: the implementation file or section of file for that type. Or if a new type is added, we just add N methods in a new file or section; we don't have to change the code of numerous functions to introduce new cases into them. Those who write articles opposing OOP never seem to constructively propose an attractive alternative for this situation. It is this attractive program organization which swayed developers toward OOP, or even full blown OOP evangelism. It's not because it was hyped. OOP has concrete benefits that are readily demonstrable and applicable. OOP is what allows your operating system to support different kinds of file systems, network adapters, network protocols, I/O devices and so on. It's unimaginable that the read() system call in your kernel would contain a giant switch() on device type leading to device-specific code, which has to be maintained each time a new driver is added.

xKingfisher 8y ago
Well yeah, that's the expression problem[0]. With OOP I can add a new datatype easily, but when I want to extend the behavior of that type I now need to go to M different places. With a functional style I only need to do one. You're open on types but closed over behaviors. Functional styles are the opposite. In some sense, I would even go as far as saying the idealized 'UNIX philosophy' is a degenerate example of this. We have a very limited set of types (the file) and a bunch of independently implemented behaviors. Imagine implementing sed or grep on a per-file (or per filesystem) basis. These both get really interesting when you consider libraries/user extensibility, since unrelated actors could now add either new types or new methods. Most languages just punt on this by banning one or the other. A pattern matching style would allow me to add a new sql() system call to query into the filesystem. Look at how much trouble there is adding new features to CSS, TCP, Java, etc trying to coordinate among so many different actors. Or consider the case of a programming language AST. I can make a pretty printer, an interpreter, an optimizer, a type checker, a distributed program runner. But trying to do that with an OOP style is much harder for a large AST. At the end of the day, we have NxM (type, behavior) pairs and there are pros/cons to each way of slicing them. [0] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem

bsder 8y ago

> I still think OO provides a pretty easy mental framework for programming. You can get good results. The problem is that OOP is a slate of something like 18 characteristics and no language ever picks the same choices. That having been said, the big problem with (especially early) OOP is that "Is"/"IsA" (aka structural inheritance) is the primary abstraction. Unfortunately, "Is"/"IsA" is a particularly lousy choice--practically anything ("Contains" or "Accesses" or ...) is better. Most of the modern languages designed in the past 10-20 years reflect this--"Traits"/"Interfaces" seems to be what everybody has settled around.