How has the church of OOP failed? Nearly every used language is based almost entirely on OOP. OOP makes organizing software and code reuse incredibly easy. The only real downsides to OOP is that its arguably slower and has more overhead. But that's only a problem in niche applications (ie. embedded apps).
> OOP makes organizing software and code reuse incredibly easy.
That is the big promise and the big lie of OOP. It, in fact, accomplishes the opposite.
The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...). And if you want to use other people's objects (say from a library) you first have to make a layer that translates them for your own objects, since objects from other systems won't directly fit the model of your own object system, they always need to be engineered in. And if the objects are encapsulating data that you actually need, but doesn't offer ways to get it (private methods), you often have to jump through hoops to get it.
Not to mention the fact that OOP often entails immutability which leads to problems while doing multithreaded processing.
Clearly the answer is to use a more data-oriented perspective and use a programming language focused around data. Clojure gets it right and that's what I use. It's all concise functional code that skips all that class creation OOP loves, instead operating directly on immutable data (numbers, strings, maps, vectors, sets).
I recommend watching some talks by Rich Hickey (the guy who made Clojure). They're almost all excellent.
Well I wonder all those reusable libraries that I'm using all the time such as boost, Qt, POCO, openframeworks, etc... come from then. Am I dreaming them ?
> The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...)
not all code on earth is your average server app that communicates with a DB and sends JSON to the internet. I don't think I have even one installed program working like this on my computers. However I have an office suite, a lot of GUI apps, media authoring software, music player, web browser, mail client.. and they are all built with OOP languages - C++ being the one used for the immense majority - and OOP patterns.
Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works?
You can build almost an entire ORM from a database without even writing any code in Entity Framework.
> And if you want to use other people's objects (say from a library) you first have to make a layer that translates them from your own objects
Funny, I've been using .NET framework objects without any type of translation. And the point is to use inheritance to mitigate the translation.
Don't blame the model for its poor use. If there's no way to get the data you need, then that means the class was designed so you didn't actually need it or there are other ways to get it (i.e. through an interface).
>Clojure gets it right and that's what I use.
Except Clojure uses OOP principles and even admits to saying it uses immutable objects in the form of interfaces. Interfaces are essentially stripped down abstract classes. How this is not a subset of OOP, I don't know.
I'm sure Clojure is great, but can you write interactive applications with it without integrating OOP libraries?
> Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP.
Except for the fact that there's usually a mismatch between how your database handles data and how you want to get them back into objects. Cue: Object-relational impedance mismatch.
And while your objects become bigger and bigger and your domain more complicated, you end up relying on ORMs who keep re-creating those objects from the database with every transaction and are loading lots of data no one requested.
And then you are wondering why your stuff doesn't scale.
> Interfaces are essentially stripped down abstract classes. How this is not a subset of OOP, I don't know.
It's not. Interfaces have been around way before OO entered the field.
> Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works? You can build almost an entire ORM from a database without even writing any code in Entity Framework.
That was actually sort of my point. You need all of this extra stuff _because_ your code is all objects. Data doesn't get serialised, data just gets sent and then it gets received. Why should you spend time serialising and de-serialising an object, when you can just send your map data structure directly? Maps can be represented 1:1 as e.g. JSON. Any JSON data is basically a big map data structure. It's one function call instead of hours of writing ORM classes or custom serialisation methods just to send some data over a wire.
> Except Clojure uses OOP principles and even admits to saying it uses immutable objects in the form of interfaces. Interfaces are essentially stripped down abstract classes. How this is not a subset of OOP, I don't know.
You don't use interfaces in Clojure, you tend to use multi-methods for most purposes where an interface is needed.
I wouldn't say Clojure uses OOP principles. Its core is written in Java, so obviously that part is forced to use objects, but that is only used to create the immutable data structures used in Clojure, which are represented as data literals, not as objects. You typically don't operate on objects in Clojure unless you're doing interop with Java or JavaScript. Instead what you do is use pure functions that take immutable data as input and spits out new immutable data. There is no object to consider, only the raw input data. A vector or a map is as much of an object as a struct or an enum. Those are data types that also existed in C, not exactly intended as an object-oriented language.
> I'm sure Clojure is great, but can you write interactive applications with it without integrating OOP libraries?
>Maps can be represented 1:1 as e.g. JSON. Any JSON data is basically a big map data structure. It's one function call instead of hours of writing ORM classes or custom serialisation methods just to send some data over a wire
Again, you don't write the ORM classes, the framework does it for you.
And what you advocate is essentially sending a table over the network. So, what happens if your data within that map is complex? Are you suggesting to send every piece of a complex data type over the wire in separate chunks? If so, how do you relate it in the application? You still to make some sense of that JSON data in your application. Having it in a big map structure is akin to a god object.
I my mind all you're doing is masking objects in different concepts just because you don't like using classes.
And now you have to rely on a framework, where there's more opportunity for leaky abstractions, more surface area where bugs can show up.
I'm not sure what you mean by complex data - data is data, and using a serial format like edn allows you to encode a lot of different stuff as data - even functions. I think you're stuck in the oo mode where you're passing around objects and classes instead of just data. Data is so much easier to deal with!
It failed by teaching that every data structure should be put into classes using many levels of inheritance, interfaces, encapsulation, accessors and the whole shebang when the thing really is just a plain old integer. OOP is really useful and powerful in many areas and applications but it is not the only tool that has to be used for everything.
