![](/style/images/good.png)
![](/style/images/bad.png)
"Data-Oriented Programming Unlearning objects" - short review — Dawid...
source link: https://dpc.pw/data-oriented-programming-short-review
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
“Data-Oriented Programming Unlearning objects” – short review
December 30, 2021I'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.
Recommend
-
11
Opportunistic programming June 29, 2020Here is my take on the relationship between functional, imperative, actor, and service-oriented programming, and a short description...
-
5
-
1
@raffaeleflorioRaffaele FlorioAbstractions ExplorerResponsibilities are what differentiate objects. They represent what an object can do fo...
-
4
Making Open Source economy more viable with dual license collectivesDecember 8, 2021I've been a FOSS enthusiast since around 1998 when I discovered Linux when I was about 13 years old. It was truly one of the definitive events in my...
-
4
“Objects” (in OOP) are just confusing peopleFebruary 16, 2022I have recently discovered a very good youtube channel about business software development: CodeOpinion
-
12
Comments Jody Whitesides (2009-09-05) #I'm amazed by how many times I'm asked for opinions and when I present as many angles as I can, people look at me funny.I love the idea of un...
-
5
Most of us can relate to feeling a bit worn out at the end of a challenging week at work. But warning bells should begin to ring when stress leads to sleepless nights, tiredness becomes a constant sense of fatigue, and you finish workdays no...
-
18
The art of unlearningHow letting go of the familiar can help product designers become more creative.
-
8
For Subscribers 'I Instilled Fear in Others:' How This Entrepreneur Confronted H...
-
7
Machine unlearning: The critical art of teaching AI to forget
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK