26 ms·

There is a recent paper called "Codata in action" [1] that I think gives a nice explanation of (part of) OOP in terms of codata types. But that paper also fina

There is a recent paper called "Codata in action" [1] that I think gives a nice explanation of (part of) OOP in terms of codata types. But that paper also finally clarified for me why OOP is so awkward and unnatural sometimes. Why should an entire program be composed only of codata types? One would think data types (which are traditionally seen more in functional languages than OOP languages) would be more natural for most problems. The specific combination of late binding and equi-recursive codata types that is approximated by OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. The other major problem I have with OOP is that it's not a straightforward manifestation of an underlying mathematical calculus, but rather a hodgepodge of (not universally agreed upon) programming ideas that are best applied on a more à la carte basis. These ideas should be used when appropriate rather than taken as an indivisible paradigm to be applied wholesale to every programming problem. That's why I prefer to think of OOP as a design pattern rather than a programming paradigm: useful in some situations, but not to be used for every situation. [1] https://www.microsoft.com/en-us/research/uploads/prod/2020/01/CoDataInAction.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/0...

pron 6y ago
> OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. How do you reach the conclusion that "the majority of problems are not"? But more importantly, the right question is not about the majority of problems, but the most common tricky parts of software, or, more precisely reduce the effort where it is largest, and the majority of tasks does not comprise the majority of effort. I am skeptical about any programming paradigm making a big difference, largely because evidence suggests none so far does, or, at least, that there are diminishing returns, but even if some programming paradigm could make a difference, I doubt FP would be it, and not only because empirically FP so far hasn't. The reason is that FP "helps" when the task is easy to begin with, and once you start dealing with interaction, it "devolves" into classical imperative programming. If any style could help, it would be a style that specifically helps with the hard parts, not the easy parts. An example of a more radical approach would be synchronous programming, that at least aims to make interaction/concurrency easier.
- trumpeta 6y ago
  I think the benefit of FP is long term. Refactoring and maintenance of systems somebody else, not with the company anymore, wrote. 2 months into a project you could be forgiven for thinking oop and fp are equivalent. You haven’t yet gone through a major shift in understanding the requirements.
  - pron 6y ago
    I have been using both FP and OOP (and I started with FP before OOP) for a quarter century already and have written extensively about the use of mathematical formalisms in software (https://pron.github.io/ https://pron.github.io/). But the question isn't about me, but about the industry as a whole. How many decades with no large benefits do we need before we say, this isn't helping, we should look elsewhere?
    - astrobe_ 6y ago
      I am not sure that OOP "isn't helping". I am not exactly an OOP fanboy, but we have to admit that, both inside and outside the industry (I'm thinking open source and hobby projects), OOP has contributed something. The industry has a lot of inertia, but it did eventually moved from assembly to high-level procedural languages, and from high-level procedural languages to OO languages. However to what extent the move to OOP rather than FP (or logic programming) for instance is accidental rather than rational is a question one may ask. Javascript has nothing special but is wildly used just because it benefited from its quasi-monopoly on web scripting. I think the problem is efficient, easy, correct: pick two. With "easy" meaning not only "easy to program with" but also "easy to learn" and "easy to hire people". Programming paradigms are false dichotomies. One can do pseudo-OOP with a procedural language, imperative in FP, FP-style in OOP. Not to mention the existence of multi-paradigm languages. Paradigms are merely about which programming style a language make easier, what is supported "out of the box". The problem is then for the user to pick the right main paradigm for the task at hand. This is where programming becomes a craft - just like a proof strategy in mathematics is not dictated by the formalism, but is chosen based on intuitions (that is, expertise). If there is no silver bullet, then maybe, from a programming language perspective, one can have a language that let us chose different pairs in (efficient, easy, correct) at different times. It is well-known that dynamic scripting languages make prototyping easier, but may not be viable in terms of efficiency and correctness for a finished product (Gradual typing tries to reduce this gap, it seems). Automatic memory management (garbage collectors) and more recently, languages with built-in concurrency features (instead of direct manipulation of OS threads) makes it easier to make less incorrect programs at the expense of some efficiency. If we admit there is no silver bullet, then can we however to build silver bullet factories?
webmaven 6y ago
> [...] only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. The problem domain that is naturally expressed in terms of OOP is GUI development (windows, toolbars, buttons, forms, and so on). The tendency to entangle the actual problem you're trying to solve with the problem of developing a user interface for your solution seems to be the main driver of the growth and extension of OOP languages over the past several decades. Various patterns (MVC, MVVC, etc.) for disentangling these while still using the same programming language have become popular, as have multi-paradigm / mixed-paradigm languages. Perhaps what was needed instead were multilingual programs, which is sort of where we ended up anyway, in an ad hoc manner (eg. HTML+CSS+JS+SQL+Python, etc.).

pron 6y ago

> OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. How do you reach the conclusion that "the majority of problems are not"? But more importantly, the right question is not about the majority of problems, but the most common tricky parts of software, or, more precisely reduce the effort where it is largest, and the majority of tasks does not comprise the majority of effort. I am skeptical about any programming paradigm making a big difference, largely because evidence suggests none so far does, or, at least, that there are diminishing returns, but even if some programming paradigm could make a difference, I doubt FP would be it, and not only because empirically FP so far hasn't. The reason is that FP "helps" when the task is easy to begin with, and once you start dealing with interaction, it "devolves" into classical imperative programming. If any style could help, it would be a style that specifically helps with the hard parts, not the easy parts. An example of a more radical approach would be synchronous programming, that at least aims to make interaction/concurrency easier.

trumpeta 6y ago
I think the benefit of FP is long term. Refactoring and maintenance of systems somebody else, not with the company anymore, wrote. 2 months into a project you could be forgiven for thinking oop and fp are equivalent. You haven’t yet gone through a major shift in understanding the requirements.
- pron 6y ago
  I have been using both FP and OOP (and I started with FP before OOP) for a quarter century already and have written extensively about the use of mathematical formalisms in software (https://pron.github.io/ https://pron.github.io/). But the question isn't about me, but about the industry as a whole. How many decades with no large benefits do we need before we say, this isn't helping, we should look elsewhere?
  - astrobe_ 6y ago
    I am not sure that OOP "isn't helping". I am not exactly an OOP fanboy, but we have to admit that, both inside and outside the industry (I'm thinking open source and hobby projects), OOP has contributed something. The industry has a lot of inertia, but it did eventually moved from assembly to high-level procedural languages, and from high-level procedural languages to OO languages. However to what extent the move to OOP rather than FP (or logic programming) for instance is accidental rather than rational is a question one may ask. Javascript has nothing special but is wildly used just because it benefited from its quasi-monopoly on web scripting. I think the problem is efficient, easy, correct: pick two. With "easy" meaning not only "easy to program with" but also "easy to learn" and "easy to hire people". Programming paradigms are false dichotomies. One can do pseudo-OOP with a procedural language, imperative in FP, FP-style in OOP. Not to mention the existence of multi-paradigm languages. Paradigms are merely about which programming style a language make easier, what is supported "out of the box". The problem is then for the user to pick the right main paradigm for the task at hand. This is where programming becomes a craft - just like a proof strategy in mathematics is not dictated by the formalism, but is chosen based on intuitions (that is, expertise). If there is no silver bullet, then maybe, from a programming language perspective, one can have a language that let us chose different pairs in (efficient, easy, correct) at different times. It is well-known that dynamic scripting languages make prototyping easier, but may not be viable in terms of efficiency and correctness for a finished product (Gradual typing tries to reduce this gap, it seems). Automatic memory management (garbage collectors) and more recently, languages with built-in concurrency features (instead of direct manipulation of OS threads) makes it easier to make less incorrect programs at the expense of some efficiency. If we admit there is no silver bullet, then can we however to build silver bullet factories?

webmaven 6y ago

> [...] only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. The problem domain that is naturally expressed in terms of OOP is GUI development (windows, toolbars, buttons, forms, and so on). The tendency to entangle the actual problem you're trying to solve with the problem of developing a user interface for your solution seems to be the main driver of the growth and extension of OOP languages over the past several decades. Various patterns (MVC, MVVC, etc.) for disentangling these while still using the same programming language have become popular, as have multi-paradigm / mixed-paradigm languages. Perhaps what was needed instead were multilingual programs, which is sort of where we ended up anyway, in an ad hoc manner (eg. HTML+CSS+JS+SQL+Python, etc.).