I've recently purchased the Data-Oriented Programming Unlearning objects by Yehonathan Sharvit. I and would like to write out some notes I've captured during reading it.
I don't like technical/programming writing using personal narration. It just seems fluffy to me. A lot of words, with very low information density. But that's just my opinion - maybe other people enjoy it.
The book starts with a straw-man of a naive (but not uncommon to see in reality) OOP code. Then the author goes on to explain what's wrong with it. I agree with most of the critique. The core of the proposed alternative approach is to separate code from the data, which I also advocate. I actually agree with a lot of things described in the book, so from now on, I'll focus on my disagreements.
The book advocates representing all the data separated from the code as a recursively nested map of free-form objects keyed by strings. Basically, all the data is one big JSON object. And I can't agree with that.
I guess at the root of the disagreement comes dynamic vs static typing again. If you are going to use a dynamically typed language... you might as well do what the book advocates. Shove everything in JSON maps. In modern programming languages with a nice type system (Rust, Ocaml, etc.) with generics, type inference, structural pattern matching, such an approach doesn't make sense. You'd be throwing tons of benefits, for a very little benefit.
The book unsurprisingly uses JavaScript for code examples, and the author mentions coming up with DOP from a Closure background. I don't want to get too into dynamic vs static typing debate, but IMO: the way type system was implemented in legacy languages like Java is terrible, and I can't blame the industry for switching to Ruby, Python, JS, etc. eventually, but nowadays statically types languages like TypeScript, Rust, etc. are way better and static typing wins over dynamic typing.
My preference and advice: if you are in the static typing camp, ignore these untyped maps, and use types instead. A lot of other things described in the book will work with types just as well. The author mentions the disadvantages of using static types, and there's a lot of truth in it. But it does not change my opinion.
Generally while reading the book it was clear to me that the whole approach is optimized for backend request-response JSON data shoveling. My background is in implementing much more complex software, with tight performance and complexity requirements, of various types, among some usual JSON shoveling between HTTP endpoints and a database. This DOP approach is going to quickly break down when challenged by more complex (technically or socially) scenarios, IMO.
While I am an advocate of functional programming and immutability, the author severally downplays and/or ignores the downsides and limitations of immutability, persistent data structures, functional programming, etc. Yes, mutability is a sharp tool and it's best to opportunistically avoid it, but it's still a necessary and/or worthwhile tradeoff in a lot of cases.
In chapter 13: Polymorphism without objects, a multimethod approach to dynamic polymorphism was presented and it seems very clunky. In my own (very data-oriented) programming approach, I just use interfaces a lot, in the code part of my software. And if I had to implement a dynamic call based on the value of some "type" field, I would just use case statement, and I think the author is making similar mistakes as OOP developers by dismissing it.
Anyway, to sum up: the "Data-Oriented Programming Unlearning objects" is an interesting book as in so far as it breaks out of OOP dogma. It presents a complete set of ideas and tools to design and implement software avoiding OOP dogma. I don't agree with some ideas in it, in particular, abandoning the benefits of static typing by representing everything as a JSON object, but nevertheless, I think it's a worthwhile read for people looking for some food for thought and exploring alternatives to OOP.
#programming #books