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.
The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and carry around in their heads, is a crime against our profession.
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.
This is not true, ad hoc polymorphism works fine without subtype polymorphism.
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.
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.
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.
This is where OOP gets it wrong, because this situation leads to logical contradictions (breaking the type system), in particular, breaking of the LSP.
Even if you took out the rantiness, the comment is still too generic to actually be saying anything. So to convert it to a good HN comment, you would need to both de-flamebait it and add information (e.g. specific examples).
Are you sure? :)
so i was trying to say, without sounding like a pushover, that i may not have responded in fear of undermining your hard work.
cheers & thanks sir!
All that said, there is a place for OOP. And while a world without OOP would be a better place than a world without FP (if we had to choose), I think you'll be waiting a looong time for that world to materialize.
The mental fun was when it dawned on me that most of the benefit from the FP I was falling in love with was coming not from FP itself, but from the liberal use of immutability... and that OOP can be written in a way that similarly embraces immutability.
I don't know if my OO code got better or worse from an outside perspective once I realized that, but it certainly made it easier for me to reason about my experimental side projects.
Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns.
Just an inflammatory comment.
IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field.
OO design patterns do not have mathematical foundations, but that does not make them arcane or toxic.
> you shouldn't use such a broad brush
Probably not, I agree.
I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not.
It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions (too little bang for the buck). (The other two criticisms are lack of formal definition and lack of representation in the computer language.)
Mathematicians discovered the existence of these structures first and gave them names. Programers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not.
> It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions.
They are not, and have been employed by couple of generations of programmers to create useful software.
Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
Regardless, I think it is a shame to call the same thing differently just for the sake of it.
> They are not, and have been employed by couple of generations of programmers to create useful software.
I can somewhat recommend this presentation: https://www.youtube.com/watch?v=Rmer37g9AZM
The concepts presented are very sound, however the presentation could be a little better.
Yes, I am aware of it. I have read Wadler's papers pointing out that list comprehensions are a specific instance of a Monad and proposing Monads as a way to structure functional programs. But I wish the Haskell did not directly copy the term Monad into the language, setting off this bad precedent. Like CAR and CDR in Lisp, unfortunately, this one will stay in Haskell. Hopefully future languages will introduce more sensible terminology, like how Lisps have evolved over the years.
> Regardless, I think it is a shame to call the same thing differently just for the sake of it.
We have to agree to diasgree on this. IMO the intended usage of a concept should dictate its name, not how humans first arrived at it.
Funny, I actually prefer CAR and CDR in Lisp to FIRST and SECOND, and I learned it only a few years ago. (It seems to me that it's more poignant since the lists are composed of cons cells.)
I think it ultimately doesn't matter - the usage of the term dictates its meaning as much as the other way around (but this can again be my mathematical background talking, which explicitly tries to unteach you to intuit based on the names of things).
The other main concern was it was over-hyped with consultants running around to all businesses during the dot net time with xml with no empirical evidence to backup their claims.
The whole OOP was a giant experiment.
I'm not dishing OOP per say. My main concern is OOP emphasis (Java) is everything needs to be a class. There are times when there isn't a need for a noun for a bunch of functions that operate over a collection of abstract data types. The other problem is how OOP is first introduced to programmers. They're taught they need to categorizing everything into a taxonomy (classes) and inheritance. So the emphasis is incorrectly put on the art of taxonomy instead of getting the job done the most straight forward approach.
There are actually OOP proponents like James Coplien and Trygve Reenskaug who think that Java is more "class-oriented" than "object-oriented", making it really hard to do proper OOP in Java.
He is more in favor programming of conceptualizing the real world as entities interacting with each other then designing systems that model those interactions. Thinking in objects allow one to design better systems that may not nesseary be represented as OOP in the language.
Jumping to the conclusion of his talk, he more or less advocating in using Abstract Data Type instead of objects. That's what I got from it anyway. Though it kind of reinforces that OOP changes depending on who you talk too.
One recent paper I read is called (The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics) concluded when you've control for class size all OOM disappeared. In other word's, you can ignore most OOP Metrics and simply run a line count over a single file and it give you a better indication bugs/faults a class may have over running the OOP metrics.
I do think David West is a smart guy, but nothing from what I've seen in `Object Thinking` comes with any significant examples, sample group, or control study that measure his approach of Object Thinking.