I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer.
OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply it.
IMO this is the wrong way to do things. Developers should be taught abstract domain modelling skills in a language-independent way, then taught how solutions can be implemented in different paradigms. Then they can start coding.
The solution is in the design of the relationships, not in the language syntax. And there's no such thing as a off-the-shelf one-size-fits all set of relationships.
There are domains where it makes total sense to subclass polygon through rectangle to square, and domains where that's a very bad idea and will cause endless pain. So it's not enough to say "This thing is like this other thing, so they both belong on the same inheritance tree." Sometimes the resemblance is superficial and irrelevant in terms of the domain - even though to you as a human programmer the similarities are "obvious."
Neither OOP nor FP can help you if your ability to design minimal but powerful abstractions that fit specific problems is poor. OOP and FP will expose you to new ways of thinking about problems, but neither is general enough to "just work" or keep you out of trouble if you don't truly understand what you're trying to do.
I think the problem is more that Roman and Indo-Arabic numerals teach that the solution is in the notation, when in fact the solution is in the mathematician. . .
I’m confused about your analogy. Indo-Arabic number representation enables one to mentally carry out computations that would be much more complex in Roman notation. The notation might not be the solution, but the notation certainly enables solutions not really conceivable in other notations.
I believe functions + immutable data enable me to mentally figure out solutions to complex problems that would be much more complex if solved with objects and inheritence and mutable state.
The analogy breaks down (at least for me) as there are some trade-offs being glossed over that don’t really exist with the different systems of numerals. What’s being lost for the conceptual simplicity you’ve gained?
Perhaps that works in theory, but in practice abstract domain modelling only gets you so far. In the real world to build a working system that solves a real problem you typically have to work iteratively from both ends simultaneously until you eventually meet in the middle. Do some modelling, then write some code to validate your understanding and understand what's really going to work, then repeat ad nauseum.
The classes of bugs you get in an OOP heavy conceptual modelling inheritance tend to be far more difficult to reason about, because half of the damn classes using it end up being utility classes, so you end up modeling a computer that does a thing instead of the thing.
> I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer.
I would say the solution is in the appropriate construct. Do whatever means writing the least amount of code possible. Less code means less to maintain and less to execute.
OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply it.
IMO this is the wrong way to do things. Developers should be taught abstract domain modelling skills in a language-independent way, then taught how solutions can be implemented in different paradigms. Then they can start coding.
The solution is in the design of the relationships, not in the language syntax. And there's no such thing as a off-the-shelf one-size-fits all set of relationships.
There are domains where it makes total sense to subclass polygon through rectangle to square, and domains where that's a very bad idea and will cause endless pain. So it's not enough to say "This thing is like this other thing, so they both belong on the same inheritance tree." Sometimes the resemblance is superficial and irrelevant in terms of the domain - even though to you as a human programmer the similarities are "obvious."
Neither OOP nor FP can help you if your ability to design minimal but powerful abstractions that fit specific problems is poor. OOP and FP will expose you to new ways of thinking about problems, but neither is general enough to "just work" or keep you out of trouble if you don't truly understand what you're trying to do.