ORM quotes from Rich Hickey
DUSTIN: This is a collection for study of everything Rich Hickey has said about ORM. Please share more quotes with me and I will add them!
As a default architecture mutable objects are terrible.
In OO, our fundamental construct, the Object conflates two things. Process, for which objects are an ok approach, and information for which they are a terrible, terrible, terrible approach.
Why did you do that (ed: using object's to represent data)? The answer could be: 'I was using Java, and I had no choice'. That's not a great answer. But it might be the truth.
Operational interfaces are specific. That generates a ton more code. It actually is a counter argument to the promise of object oriented programming. One of the promises was: reuse. This is the big lie of object oriented programming. Every new thing you have to do, you write a new class. Where's the reuse in that?
Java programmers and OO programmers have been kicking SQL. 'It requires ObjectRelationalMapping, and that's like a problem with SQL'. No! It's a problem with objects.
Objects are not the way the world works. Nothing in the world works that way. People don't hand their strings out to other people to start yanking on them. So that's how we're gonna have a soccer team: we're gonna have a reference to somebody else. You call pass to me. And we build this big spaghetti nightmare. This is completely not the way the world works. This is not how physics works. We say objects are a way to model the real world? It's not at all. It's a complete programming fabrication. It's not very realistic. It's not a good fit for almost anything. It is my opinion that object oriented programming, as delivered by Java, etc., is not a good default way to structure your program. https://www.youtube.com/watch?v=VSdnJDO-xdg&feature=youtu.be&t=2263
Mutable objects are the new Spaghetti code
What goes in the cache? What form does it take? When does it get invalidated? Whose problem are all these questions? Yours! Your problem! Or maybe you're buying some fancy ORM that makes it your problem with another a layer on op of your problem. Now you have two problems.
Nothing fact-like about the relational model. It doesn’t say when
Leave data alone. Programs are increasingly about code, and decreasingly about data. And I think that’s a mistake
Simple Made Easy (2011)
Who drives their car around banging against the guardrail saying, “Whoa! I’m glad I’ve got these guardrails because I’d never make it to the show on time.” The average juggler can do three balls. The most amazing juggler in the world can do, like, 9 balls or 12 or something like that. They can’t do 20 or 100. We’re all very limited. Compared to the complexity we can create, we’re all statistically at the same point in our ability to understand it, which is not very good. So we’re going to have to bring things toward us.
We were using these words really weakly.
ORM is complex, and declarative data management is simpler.
Eventual consistency is really hard for programmers. Inconsistency is very complex. It’s almost definitionally complex because consistent means to stand together, so inconsistent means to stand apart. THat means taking a set of things that are standing apart and trying to think about them all at the same time. It’s inherently complex to do that.
It’s the same stuff in both these diagrams, the exact. It’s the same strips. What happened? They got complected.
Object relational mapping has, oh my God complecting going on. You can’t even begin to talk about how bad it is, right?
Data: please! We’re programmers. We’re supposed to write data processing programs. There are always programs that don’t have any data in them. They have all these constructs we put around it and globbed on top of data.
Data is actually really simple. There are not a tremendous number of variations in the essential nature of data. There are maps. There are sets. There are linear, sequential things. There are not a lot of other conceptual categories of data. We create hundreds of thousands of variations that have nothing to do with the essence of this stuff and making it hard to write programs that manipulate the essence of the stuff. We should just manipulate the essence of the stuff. It’s not hard. It’s simpler.
Are we all not glad we don’t use the Unix method of communicating on the web? Right? Any arbitrary command string can be the argument list for your program, and any arbitrary set of characters can come out the other end. Let’s all write parsers. (laughs) No, I mean it’s a problem. It’s a source of complexity. So we can get rid of that. Just use data.
Clojure protocols and Haskell type-classes and constructs like that give you the ability to independently say, I have data structures, I have definition of sets of functions, and I can connect them together, and those are three independent operations.
You can get declarative data manipulation by using SQL or learning SQL, finally. Or something like LINQ or something like Datalog. … Rules, declarative rule systems, instead of embedding a bunch of conditionals in our raw language at every point of decision, it’s nice to sort of gather that stuff and put it over someplace else. I don’t know, I don’t want to know.
If you’re not using queues extensively, you should be.
Wrapping data in objects is wrong ... Which also applies to ORM is that it will tie your logic to representational things, which again is tying, complecting, intertwining. So represent data as data. Please start using maps and sets directly.
Value of Values – 2012
Information is based on the word inform which means to convey knowledge via facts and the purpose of that is to give shape to the mind. And information is just those facts. That’s what information is. Information is facts.
Mutable objects are nothing more than abstractions over places. The notion of going to the place and setting it to be a new value.
And I have a word for this or a term for this which I call, PLOP. PLace-Oriented Programming, which is what this is and you can tell when it's going on because anytime new information replaces old information, you're doing Place-Oriented Programming. There's a reason we do Place-Oriented Programming because way back in the early days of computers, we had to do Place-Oriented Programming. I saw Guy Steele give a great talk where he was talking about working, you know, building these systems on a computer that had four kilowords of memory. In every piece of memory, you knew the address, you knew the even number addresses starting at 2000 were used for jump table and these other addresses over here where used for data, and other parts of the addresses were used for code. Sometimes they were used for more than one thing because you knew, like right now, no one's using this for codes so we can use it for data and vice versa. You had to do it. There wasn't enough capacity to do anything else. Computer memories were really small. Disks were very small. Everything was very expensive. So we adopted an approach to programming that was based around the manipulation of places. It totally made sense. And the keyword there, the key aspect to that is it made sense. It used to make sense. Those limitations are gone. In the time that I've been doing programming, the capacity of these two things have increased a millionfold. A millionfold. What other thing in life you know has the same facts about it remain true when the size of something changes by a millionfold. Imagine if your car was a million times bigger than it is. What rules would still apply? What characteristics would still be true? Almost nothing but yet, we're retaining decisions we made when things were much much smaller and moving forward with it. So why does PLOP still rule?
That's the key question here. When we talk about Place-Oriented Programming, we often talk about these two things, memory and records. These words had meanings before we had computers, yeah? And we've taken them over. We've said, "Memory means addresses in RAM chips and records mean slots in database tables." And worse than just taking over these words, because obviously there's a limitation to a number of words and the analogies roughly hold, right? The analogies between memory and memory in your head roughly hold but the problem is, we've now been doing this for so long that we believe our own myths about what these things mean but we should go back to the facts of memory and records. The fact of memory is that it's an open system. If your friend gets a new email address, that doesn't go to your brain and find your friend's email address cells and replace his email address in that part, in those neurons in your brain. That's not how brains work. That's not how memory works. Memory is essentially an open system and an associative system. It is not an address-based system. Same thing, record keeping. We used to keep records before we had computers. What did we do? We took out the stone tablets and we chiseled the thing or we took out the papyrus and we wrote stuff there. When we had new information, what did we do? We did not go and smoothed over the marble and chiseled new stuff. We didn't go to the papyrus and take out erasers and things like that. When people built accounting systems before there were computers and they didn't use erasers either, right? What did they use? Double-entry accounting or ledger-based accounting. They only made correcting entries. They did not go back with erasers. That's not the way things worked before we had computers.
Immutable string is a comparable thing. Comparability is where we derive our ability to do logic and make decisions until we can say, “This is the same as it was yesterday. Is it greater or less than what it was?”
Values are immutable and values are semantically transparent. The purpose of a value is to expose itself to you so you can do that comparison and that equality test. Value’s not about encapsulating something in methods and doing things. Values are about saying, “Compare me to something else. I’m telling you what my precise meaning or my significance is.” Right on the label, right on the outside.
You can make up a value from scratch in any programming language quite readily. Can you make a string in any programming language? Yeah. Can you make a list of strings? Sure. A list of numbers? Yeah. A list of list of numbes? Yeah. A map of list of numbers? Yeah. Can I make an instance of your fancy interface in any other language? No. It’s not easy to fabricate that.
Values are language independent. The notion of a list or string or number or a map. This has nothing to do with the programming language.
If you have an object and you want to share it, what do you want to do? You have to define the object, define the interface for it and everything else but then you have to do what?... How do you copy it, what are the cloning semantics, whatever.
How many people have ever heard of read transactions? Yeah. How many people like read transactions? No. The whole idea is counter intuitive and violates physics. In physics, we just look at each other. We don’t have to stop everything in order to look at things. When we’re programming with values and using values especially in storage, we again have reduced coordination.
In the large we communicate values but in the small, in a programming language, we start doing icky things.
The first fact about facts is that facts are values. They’re not places.
Language of the System
The system is this composition of things whose language doesn’t know anything about systems.
At the top, we end up with either portions of applications or entire applications acting as services andor consuming each other as services. And that’s a system.
Design is to take things apart in such a way that they can be put back together
Design is separating into things that can be composed
Design helps extension. To the extent that you have broken things into separate parts, with an eye towards connecting them back together, it means that your resulting design is gonna have connection points.
And when you want your system to do something new, it will be possible to do it, because there's something there. That's why design is not just about accreting up to an answer. Because when you do that you don't end up with any connecting points. And you don't end up with any building blocks. And you can't really extend that thing. Similarly the flipside of that is:
To the extent you have broken up your problem into reusable parts and composed them, those parts may be separable from your design and useful in another context. And that's how we get reuse. Reuse comes from design. It doesn't come from language constructs or anything like that.
Every time I encounter something I can boil it down to that. Every time I encounter something that I wish my design was better, I need to do more of this (take things apart). Over and over again. I did not take it apart enough.