contrarian notes on software engineering, Open Source hacking, cryptocurrencies etc.
Since “mocks” and “mocking” is somewhat vague, and nuances between mocks, fakes, mock objects, test doubles, spies, etc. are confusing, let's start with what I mean by “mocking”.
What I mean by it is intercepting and/or substituting internal and often arbitrary function calls to test your code.
A great example of a mocking approach is a mocking framework like Mockito, where the tests look like this:
I have recently discovered a very good youtube channel about business software development: CodeOpinion. Very concisely yet informative. I highly recommend it. Don't worry – it's OOP-rant free, and all about mainstream accepted good practices, not some wacko OOP-hater like me.
Anyway, while going through some of the episodes I have found a good example of how “Objects” (in OOP) are a metaphor that is just confusing people.
Please watch the AVOID Entity Services by Focusing on Capabilities – it's just 7:30:
BTW. I highly recommend Statistical Rethinking 2022 Youtube lectures by the same author. I started watching them recently and I am enjoying them a lot so far (finished first two videos so far).
I like fast code, and I cannot lie.
I've been optimizing a lot of projects over the years, and here are some tips that I'd like to share with you
dpc-pariter
TL;DR: I published a parallel processing library for Rust that works differently than rayon and is especially useful in cases where rayon falls a bit short. I'll talk a little bit about it, and show you when it can be helpful.
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.
I'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 life. There is something extraordinary and even spiritual in the idea of a global, voluntary, collaborative yet competitive network of people sharing their knowledge and work and building together something that can challenge even the largest commercial organizations.
However, it's clear that there's a huge problem with FOSS:
https://imgs.xkcd.com/comics/dependency.png
and the older I get, the more this practical reality bothers me.
While sharing work freely is noble and leads to great overall efficiencies, the pragmatic reality is that FOSS developers live in a material world, a market economy, and need to make money somehow. Many approaches to funding FOSS development have been tried, all of which with rather unsatisfying results.
Here is an idea that has been sitting in my mind for more than a year now, and I still think it might work. I finally decided to write it down, so people can tell me if it already has been tried or why is it bad. I almost never have any truly unique idea, so I bet someone will send me a link proving that I just suck at googling stuff. If you think it's good – feel free to give it a try. After all, ideas are cheap and execution is where the value is.
This post and work behind tries to achieve multiple goals:
I often receive feedback to my general OOP critique from people somewhat sympathetic to my message suggesting that since OOP is vague and not precisely defined, it would be more productive to talk about its core tenets/features in separation and drop the “OOP” name altogether.
I've also received an email (hi Martin!) asking among other things on my opinion about usage of interfaces in OOP. So instead of writing a private response, I'm just going to dwell a bit more on it in a blog post.
BTW. I'm continuing to read #oop #books to gather more insight and arguments. Currently, I am going through Object-Oriented Software Construction by Bertrand Meyer. The book is huge and presents the case for OOP in-depth, which is perfectly fulfilling my needs. And on top of it – it's old, so it gives me a lot of insight on “what were they thinking?!” ;). Hopefully, I'll get to a post about it in the not-too-distant future, but I will be referring to it already in this post.
Anyway... about the polymorphism and stuff...
Edit: I received a lot of feedback that this post is a rant. It's probably true. The primary reason is because of frustration. I have been engaging online looking for books and example of code presenting “Good OOP” for studying and refining my views. The previous book I was recommended and read: Growing Object Oriented Software, was a blast. This book was recommended frequently, even more than the previous one, so I reluctantly bought it and then got rather upset about how big of a disappointment it was. It's a book about small scope code refactoring, not really OOP, so it's not even on the point. And even at learning to refactor, I think it uses confusing and counterproductive examples all the way. I read it, I didn't like it, I wrote a short rant why exactly, to get it off my list. If you don't enjoy rants, hit Ctrl+W now.
When asking around “Good OOP” examples a lot of people recommend 99 bottles of OOP book. I was reluctant to buy it. By the name and the description, I could tell that it is going to use the “99 Bottles of Beer” song as an example of some sort... which frankly seemed completely unproductive. But since people keep on mentioning it – I got it. And unsurprisingly, I was right: the book indeed is confusing and just... not good.
TL;DR: Even as a vocal critic of OOP, I can see that this book is doing a huge disservice to anything that could be called a reasonable OOP. Save yourself $40 and don't buy it. If you own it, throw it in the trash. If you've read it – know that you learned a bunch of nonsense about OOP, and maybe some minor stuff about structuring your code and writing tests.
