Comment by curryhoward | Hacker News Reader

Comment by curryhoward | Hacker News Reader

Parent Full thread

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/0...

> 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.

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.

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/). 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?

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?

I agree with most of what you've said, except that programming paradigm and languages have not helped with anything significantly beyond a certain point. They helped early on, FORTRAN was more productive than Assembly, FP/OOP helped after C etc., but we're seeing diminishing returns. And guess what: some predicted that this is exactly what would happen, incidentally, the very same person who said there's no silver bullet.

I'm not saying it's not possible to help, just that in a world of diminishing returns, it means that finding stuff that helps is very, very hard, and I think we're at a point where we can say that FP and OOP are not "the answer" to getting us further than where we already are, and start looking for other things.

> If we admit there is no silver bullet, then can we however to build silver bullet factories?

I would say that the answer is no, for a similar reason we can't build halting-problem-deciding factories. If we had silver-bullet factories, then unless picking the right bullet is very hard -- in which case we've solved nothing -- then we have a silver bullet. There are some fundamental reasons for that, and I tried to cover some of them here: https://pron.github.io/posts/correctness-and-complexity

The one unanswered question is how far are we from the best we can do?

Wouldn't you say that the next logical step is to go up an abstraction then? Assembly -> C -> OOP/FP -> ??? In that case, wouldn't it make more sense if that abstraction was build on top of something which you can mathematically reason about?

First, you can mathematically reason about a program written in any language; I do it all the time with TLA+ [1]. It is certainly not the case that FP is more amenable to mathematical reasoning than imperative code, although the kind of reasoning is different: FP mostly relies on equational reasoning while imperative mostly relies on assertional reasoning. Synchronous programming, for example, relies on temporal reasoning.

Second, mathematical reasoning has its limits, especially as we're dealing with intractable problems. It doesn't matter if you can somewhat more easily reason about a simple three-line program in one paradigm than in another if most important programs are six orders of magnitude bigger. Unfortunately, program correctness (aside from some very simple properties) does not compose tractably (i.e. even if reasoning about components A1...An is "easy", reasoning about the composition A1 ∘ ... ∘ An can be more difficult than any computable function of n. So I would not put ease of mathematical reasoning about simple cases as necessarily the main priority, let alone the only one.

[1]: https://pron.github.io/tlaplus

Logic programming immediately comes to mind. I've always had trouble to see the difference between imperative programming and procedural programming, and in a way OOP is procedural with lipstick (I'll wait that it is fashionable to bash FP to say the same about FP :-). Logic and declarative programming, on the other hand, are whole different beasts.

> [...] 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.).

Reply on news.ycombinator.com