3 ms·
I have not read the article but I've seen other blog posts on the subject. The issue with "OOP is bad" is that OOP means different things to different people.
by sirwhinesalot 5y ago
I have not read the article but I've seen other blog posts on the subject.
The issue with "OOP is bad" is that OOP means different things to different people.
Abstract Data Types are sort of a subset of OOP and are massively useful, I certainly don't think it's a good idea to expose the internal implementation of a data structure most of the time. Any sort of plugin system works in an OO matter. It is a useful tool, no question.
Even things like Actors like in Erlang (which are much closer to the Alan Kay style OO) are massively useful in a distributed setting where state is naturally distributed.
Where you get into trouble is when you go the whole "lets model a taxonomy of the world" style with inheritance hierarchies or go ham on design patterns, layers upon layers of abstraction and other nonsense like that.
The saddest thing about the "object–relational impedance mismatch" is that the focus went totally to the wrong side. The relational model is a much nicer way to model relations than a graph of objects (that's the whole point after all). SQL sucks but that's a separate issue, Entity Component Systems are a form of relational modeling for example and work really well, or even better Datalog.
- almostdeadguy 5y agoThe problem with the "inheritance isn't part of OO" take is that every single one of the languages we call object-oriented that gained mass adoption have inheritance, including Alan Kay's own smalltalk. There have been entire books written about object-oriented design describing ways to use (or not use) inheritance in program design. So whether or not it was intended to be important by the author of the term is immaterial, it for all intents and purposes is a crucial part of object oriented languages. Inheritance is not the only problem w/ OO either, many things are straight up awkward to express when you must couple data and code together. Many 2+-argument function w/ disparate parameter types create confusion about which class "owns" the definition of the function. You also don't need to marry data and code to get the benefits of encapsulation. Many functional languages in the ML family have developed clever solutions to encapsulate the definition of a datatype while exposing it to module-local functions. There's no need for the datatype to carry a method around with it to support this.
- dools 5y ago"The saddest thing about the "object–relational impedance mismatch" is that the focus went totally to the wrong side. The relational model is a much nicer way to model relations than a graph of objects (that's the whole point after all)." I found the same thing. When I was using ORMs I always found them clunky for all but the simplest tasks, where I would long for an easy way to use SQL and have it "just work" for objects, so I created this: https://github.com/iaindooley/PluSQL https://github.com/iaindooley/PluSQL It's obviously not been maintained but I think it's a model that has legs: that is, simply the creation of SQL with some convenience methods, allow the use of completely arbitrary SQL, and then intuit the object mapping automatically without loading the entire result set into memory.
- Semaphor 5y agoThere are many such MicroORMs, C# has a few extensions for Dapper, as well as several newer projects that directly have different querybuilders and convenience methods.
- nyanpasu64 5y agoDo relational models support sum types? I find them an essential feature in programming languages, nearly as important as structs or rows.
- sirwhinesalot 5y agoUnfortunately many don't. Standard Datalog for example doesn't have disjunction which you need to model sum types as relations. My preference is to have sum types modeled separately from relations as just a complex type that can be related as well. This is the approach taken by Souffle, a C++ Datalog implementation which supports sum types.
- sirwhinesalot 5y agoFor some reason I cannot edit the post above, but I misspoke on Datalog, since it has disjunctions, just not in the head of rules. You can go pretty far with disjunctions in the body which suffices for most cases of modelling "sum types". For example: Stakeholder(X) :- Shareholder(X); Customer(X); CEO(X). It's still a lot better to model them separately from the relations, for the same reason that you want to model relations between points as actual relations between points not between X, Y and X, Y.