7 ms·

> It's a language completely based on 90's hopes that OOP was a good idea. I find the dismissive tone rather amusing. A large majority of the code running on

> It's a language completely based on 90's hopes that OOP was a good idea. I find the dismissive tone rather amusing. A large majority of the code running on our planet today is OOP. You could argue that there might be better ideas out there, but OOP is certainly an idea that has not only proven itself to be tremendously useful, but that has also been able to adjust and adapt through decades of changing requirements. It's pretty much the only software paradigm that's survived for that long.

jstimpfle 9y ago
Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxonomic code, but in the end they never seem to get value out of it, only more and more incompatible objects (when I hear "mock object" it's time to run). In OOP >50% of the LOC is just stupid bureaucrazy, setting up object graphs in the name of "isolation" (the irony), half-initializing fields, conforming to the right interfaces etc. This is completely meaningless, do-nothing code. Worse, it gives the illusion to remove some contextual dependencies this way, but the code never seems to work outside of the context it was created in. It's only much harder to read because the context is files away. OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. It tries to repair this wrong idea with inheritance (which is at least as bad an idea). And it makes it really hard to cope for "cross-cutting concerns", which are actually 90% of all we care for, not just a side concern. The complexity is in the edges (i.e. how is information moved/transformed), not in the objects! OOP mostly survived where performance / architectural scalability is not super important (e.g. Python or similar scripting languages, where it enables dynamic typing). And it survived where the big money is, but not necessarily technical competence (where it enables Object-verb type code completion). That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p > A large majority of the code running on our planet today is OOP. Good example code base? > It's pretty much the only software paradigm that's survived for that long. Maybe check on your history? Many people are totally happy with procedural programming.
- mgummelt 9y ago
  > when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.
  - tathougies 9y ago
    > Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.
macintux 9y ago
> It's pretty much the only software paradigm that's survived for that long. Perhaps the only one that’s been the most popular for that long.
thesz 9y ago
>It's pretty much the only software paradigm that's survived for that long. Functional programming predates non-functional programming - Turing's papers and thesis were published (at least) a year after Church's papers on lambda calculus. Type systems in FP run decades ahead of type systems in regular programming languages. For example, simple type system for FP was published in 1948 and it was (more or less) equivalent to Fortran's type system (1958). The type inference was published in 1968 by Hindley and Milner adapted his algorithm to more "efficient" mutable state in 1978. Type inference come to mainstream languages only in what? 2004? The algebraic types and pattern matching were born in 1971, the year I born too. These facilities start to appear in mainstream languages no earlier than 2008 if you consider Rust at that time as a mainstream language. And C# acquired them, I think, in 2016 and not earlier. I boldly and offensively assume that OOP is the only paradigm you decide to care about and thus you consider it "the only software paradigm". I think that it is a very useful position in life, not to care about things you decided not to care about. I do that too.

jstimpfle 9y ago

Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxonomic code, but in the end they never seem to get value out of it, only more and more incompatible objects (when I hear "mock object" it's time to run). In OOP >50% of the LOC is just stupid bureaucrazy, setting up object graphs in the name of "isolation" (the irony), half-initializing fields, conforming to the right interfaces etc. This is completely meaningless, do-nothing code. Worse, it gives the illusion to remove some contextual dependencies this way, but the code never seems to work outside of the context it was created in. It's only much harder to read because the context is files away. OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. It tries to repair this wrong idea with inheritance (which is at least as bad an idea). And it makes it really hard to cope for "cross-cutting concerns", which are actually 90% of all we care for, not just a side concern. The complexity is in the edges (i.e. how is information moved/transformed), not in the objects! OOP mostly survived where performance / architectural scalability is not super important (e.g. Python or similar scripting languages, where it enables dynamic typing). And it survived where the big money is, but not necessarily technical competence (where it enables Object-verb type code completion). That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p > A large majority of the code running on our planet today is OOP. Good example code base? > It's pretty much the only software paradigm that's survived for that long. Maybe check on your history? Many people are totally happy with procedural programming.

mgummelt 9y ago
> when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.
- tathougies 9y ago
  > Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.

macintux 9y ago

> It's pretty much the only software paradigm that's survived for that long. Perhaps the only one that’s been the most popular for that long.

thesz 9y ago

>It's pretty much the only software paradigm that's survived for that long. Functional programming predates non-functional programming - Turing's papers and thesis were published (at least) a year after Church's papers on lambda calculus. Type systems in FP run decades ahead of type systems in regular programming languages. For example, simple type system for FP was published in 1948 and it was (more or less) equivalent to Fortran's type system (1958). The type inference was published in 1968 by Hindley and Milner adapted his algorithm to more "efficient" mutable state in 1978. Type inference come to mainstream languages only in what? 2004? The algebraic types and pattern matching were born in 1971, the year I born too. These facilities start to appear in mainstream languages no earlier than 2008 if you consider Rust at that time as a mainstream language. And C# acquired them, I think, in 2016 and not earlier. I boldly and offensively assume that OOP is the only paradigm you decide to care about and thus you consider it "the only software paradigm". I think that it is a very useful position in life, not to care about things you decided not to care about. I do that too.