[hota_mazi]

> All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language.

If you think FP is mutually exclusive with OOP, you understand neither.

OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

FP operates at a more granular level, basically how you implement your methods.

And by the way, FP has design patterns as well.

FP and OOP are extremely complementary.

[runT1ME]

>OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

This is not true, ad hoc polymorphism works fine without subtype polymorphism.

[hota_mazi]

You're absolutely right but you're not answering my objection.

Show me an example of a type class with five functions and then how I can reuse it while overriding one of these five.

[js8]

You don't need overriding, in fact you should avoid it. All five functions are already valid operations on the type class (the data you have). If you want to add an operator, then you define another function (with another name) and call it. If the existing modules need to call that operator instead, change them to be explicit about what you're doing.

This is where OOP gets it wrong, because this situation leads to logical contradictions (breaking the type system), in particular, breaking of the LSP.

[lomnakkus]

> Show me an example of a type class with five functions and then how I can reuse it while overriding one of these five.

Huh? As I'm sure you're aware "type classes" != "classes", so I'm not sure why you're expecting them to be 'interchangeable' in this manner. It would be better to ask for some functionality (not a mechanism, as you're asking) and then show how one could be achieved[1] in one, but not the other.

Personally, I think any kind of implementation override is a code smell. If you need common functionality, just have a plain function outside your class and use that from both interface overrides.

[1] "Elegantly" or "expressively", one presumes. Of course everything can be achieved in any TC language.

[prodigal_erik]

If two things (typeclasses, interfaces, whatever) are very similar, I just want to write how they're different. Without something like inheritance I also have to redundantly restate all the ways they're the same, which nobody benefits from, it's only an opportunity to make a mistake.

[ilugaslifg]

You do not understand what a typeclass is or how it's meant to be used. If you are redundantly restating a single thing in a Haskell program, you have taken a very wrong turn.

Give me a single example of something that it turns out is truly better expressed through inheritance, and you will be on the shortlist for a Turing Award.

[lomnakkus]

My point is that it's not "(typeclasses, interfaces, whatever)". They're similar, yes, but my point is that they aren't similar enough in the "mechanical" sense that the parent poster seems to be assuming.

EDIT: Btw, I think it may actually be possible to encode what the parent poster wants by just having a type class per method, but it's obviously a weird and non-idiomatic encoding given the presumed lack of any laws.

[kdsgfn]

What you're describing can easily be done by making a module that re-exports four functions from another module and implements the fifth itself (in haskell, anyway).

[hota_mazi]

Yes, like I said, OOP does this a lot more elegantly.

[sdflkd]

Agreed. Anyone who thinks this hasn't played enough with FP languages.