I once read an essay on https://clojuredocs.org. Now I’d like to find it again, but I cannot find it. The essay made the point, which I think Rich Hickey original made, that object oriented programming introduces a problem of non-reusable code because every object, with its methods, is basically its own special little language.
Does anyone know of an essay on https://clojuredocs.org that repeats the standard criticism that the Clojure community has of OOP?
Perhaps not what you’re thinking of/searching for, but your post reminded me of this one, which I like: Stevey's Blog Rants: Execution in the Kingdom of Nouns
I’m not sure that such essays would ever have been on clojuredocs.org – clojure-doc.org tends to have more “essay”-style pieces but I don’t believe it has ever hosted an essay on this topic. There’s this piece about state and identity on clojure.org (and maybe other parts of the rationale section will help): Clojure - Values and Change: Clojure’s approach to Identity and State
Some of what you might be thinking of is covered in Rich’s “Are we there, yet?” talk (again, mostly state and identity, but also time): talk-transcripts/Hickey_Rich/AreWeThereYet.md at master · matthiasn/talk-transcripts (github.com)
Several of Rich’s talks cover the issue of reusability and why user-defined types impede that (usually in the context of OOP), but it’s often more of an aside when he’s talking about generic code and abstractions, or the reusability of small, focused libraries.
Thank you for that. I used the wrong word when I said “essay.” It was an article that was instructional, but it included a paragraph or two that (at a minimum) repeated points that Rich Hickey had made about every object in object oriented programming having it’s own methods, and therefore being a mini-language unto itself. I think the contrast was to a more functional approach of generic data structures and a large number of functions that can do useful things with those generic data structures.
Thank you, I’ve read that before, but it is fun to read it again.
Sounds like Clojure - Rationale OO is overrated, which summarizes Rich’s points and specifically quotes Perlis: “It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.”?
This sounds like the HttpServletRequest bit from Clojure Made Simple (transcript).
So one of the other things I think we suffer from in object orientation is death by specificity. All the time, we have a new thing, we have a new idea, a new piece of data. Boom! We have a new class. Get this, get that, get whatever.
I do not care if they are value types, whatever. It is just a glorified map, except you cannot even use it as a map in Java. There is no generic way to manipulate something that says: get this, get that, get that. So new type, new language, it has got its own little vocabulary.
So you are going to have more code. You are going to have much less reuse. You are going to have more coupling. Because essentially what is happening is every object has its own little language: my class, my interface, my own language. This is my biggest pet peeve. I wanted to get away from this. When we saw it writing get this, get that, there is no purpose to this. This is just life-sucking.
The paper you’re looking for is on the so-called “expression problem”, and is no longer available from the original site. Last time I checked, a year+ ago, it was still available on an internet archive site, but I don’t have the link any more and you’ll have to dig for it. I suggest googling for clojure and “expression problem”. It might have been authored by Stuart Sierra, I don’t remember.
It isn’t necessarily a repudiation of OO, there’s nothing wrong with OO (IMO), it’s a tool just like FP, each with pros and cons. What it describes is the problem of being able to extend behaviors without access to the original source code (a TL;DR description that probably isn’t correct, but it’ll have to do for my reply and/or limited memory of the paper).
That’s the one I was thinking of, thanks.
Fantastic. I feel like this was written as an essay somewhere, but this is exactly the idea I was looking for. I knew someone had said this somewhere.
You might be thinking of this: Rich Hickey Interview with Fogus on CodeQuarterly (likely from around June 2011) · GitHub
(emphasis mine)
Fogus: So once incidental complexities have been reduced, how can Clojure help solve the problem at hand? For example, the idealized object-oriented paradigm is meant to foster reuse, but Clojure is not classically object-oriented—how can we structure our code for reuse?
Hickey: I would argue about OO and reuse, but certainly, being able to reuse things makes the problem at hand simpler, as you are not reinventing wheels instead of building cars. And Clojure being on the JVM makes a lot of wheels—libraries—available. What makes a library reusable? It should do one or a few things well, be relatively self-sufficient, and make few demands on client code. None of that falls out of OO, and not all Java libraries meet this criteria, but many do.
When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications. Clojure eschews this and instead advocates a simple associative model for information. With it, one can write algorithms that can be reused across information types.
This sentence in particular is the one that I was thinking of. Thank you.
