Object-oriented programming is a disease, and I can't wait until we're collectively done with it.
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.
> 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.
>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.
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.
> 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.
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.
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.
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.
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).
This sort of heated rant makes for a bad HN comment, regardless of how correct your views are. It leads to flamewars, which we don't want here, so please don't post like this.
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).
There is far too much conviction in the world. One of the reasons HN is so enjoyable is that the discussions tend to avoid the heat that you can find just about anywhere else.
I can appreciate that, but empirically we know from long experience that such comments lead to downward spirals. That's why the site guidelines are the way they are; it isn't to dampen conviction.
so, if i'd noticed you were dang before i responded i probably wouldn't have. only because i was trying to form a consensus. i didn't realize the consensus was being explained to me. :)
I dislike OOP. It's my least favorite paradigm. The "objects-first" approach to teaching programming was such a bad idea.
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.
I've spent the vast majority of my career in OO-centric projects, but between my experience in Javascript and Clojure I've begun to see OO as FP with a layer of syntactic sugar. Objects are just closures at the end of the day, after all.
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.
> IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field.
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.)
> 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.
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.
> Mathematicians discovered the existence of these structures first and gave them names. Programmers 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.
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.
> Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
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.
So what names do you think should be used instead of Monad, Applicative, Functor, .. ? (There was an interesting discussion about this on HN: https://news.ycombinator.com/item?id=9887728)
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).
To do OOP good requires a lot of forward thinking and careful planning. Though most of the two are lacking supply when you're dealing with large teams of programmers and you end up with some IFactoryAbstractInterfaceInvoker eg... the kingdom of nouns game.
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.
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.
There was a great talk by (David West) (https://www.youtube.com/watch?v=RdE-d_EhzmA&index=2&list=PLe...) that does make the point that objects have little, if any, value as a programming concept Because all the arguments about objects occurred in the context of programming they focused on things that really don't matter much, like single versus multiple inheritance, dot notation versus explicit messages for getting and setting or invoking methods; class hierarchies, friends, even the idea of a class.
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.
Kudos for mentioning David West! I strongly recommend his book "Object Thinking" as the book about what OOP really is, how object orientation is achieved and which languages' philosophy is OO compatible and which ain't (spoiler: C++ and Java are in the latter group). While Java is my favorite language so far, I certainly hope that some proper OO language will emerge in the near future.
I'm on the fence about Object Thinking. Most of OOP books I've read are very anecdotal without any empirical evidence to back up their claims. I've read a couple of research papers that used used (empirical evidence) to see if OOP was better than any of the competing other languages. The paper conclude's there isn't really any significant difference. The only difference they did find is higher languages where less code, but the complexity per line was higher than earlier languages.
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.
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.