Posts

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:

• It's a follow-up post and code example to my previous post titled "How I structure my apps (in Rust and other languages)".
• It's a follow-up post and code example to "Growing Object-Oriented Software vs what I would do".
• It's a showcase, research, and example project on the cross section of event-based systems and using hexagonal/clean architecture in Rust.
• It is a description of my general approach to building application/services, so I can share it and receive feedback, possibly improving how I do things.

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...

TL;DR: I review Growing Object-Oriented Software, Guided By Tests and contrast it with my personal approach to developing software, explaining my reasoning, and making some comments on the book, OOP and software engineering in general.

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.

Have you ever noticed that Jira (and most if not all) SWE work tracking systems allow assigning only one person to a given task? The whole industry (at least where I've seen it) runs around the assumption that at the bottom "one task == one person".

The more I think about it through the years, the more confident I am that it's a very unproductive thing to do, and we should default to two people working at the same time on a given task. In complex domains, sometimes potentially even three.

Anytime there's a thread about Bitcoin on HN or elsewhere and people start talking about money, Bitcoin, crypto, economic and such, it becomes pretty clear that pretty much no one there has any clue what they are talking about.

One talking point that irritates me most in these discussions is that both sides (pro and anti crypto) are wrong about "why does fiat money have some / does not have any value". The pro-crypto side says "fiat money has no value / is not backed by anything" and the anti-crypto side says "fiat money is backed by the fact that you have to pay taxes with it / government has guns".

Both statements are nonsense. The simple truth is: modern "fiat money" is backed by the loans created when it was created.

Just recently, I've discovered that I have an Aphantasia - "inability to voluntarily create mental images in one's mind."

In one of post on the excellent blog of Ted Kaminski he talks about Data vs Object distinction. When I was reading it I got excited because I've been mulling about this exact distinction when crystalizing my problems with mainstream-class-oriented-OOP. And I think we're both aiming at the same thing, but I have drawn the line between the two differently. Plus I have some other thing to say about this confusion.

From my point of view, the main source of progress in programming (software engineering) was, is and will be sacrificing small scope expressiveness and power to improve larger-scope composability.

I keep thinking about this idea of a different approach to building Operating Systems. I know it's not a new idea.

I guess the core of the idea is that the programming language, its runtime, and the OS should be the same thing. You know - kind of like Emacs or generally Lisp, or Smalltalk. Where the language is the runtime, and it allows modifying itself while its running.

Maybe I'm wrong, and what do I know about anything anyway, but I think the previous attempts to make this a reality were outcompeted due to practical considerations: mostly performance and resource utilization.

You see, I am a bottom-up developer.: When I was a kid I first learned how do electric switches and transistors work, how to chain them into longer logical circuits. I was playing with writing assembler code for MOS CPU of my C64, POKEing and PEEKing bytes into addresses of memory mapped hardware registers. As a teenager, I was hacking on a Linux kernel. For me, the computer will always be only a very fast automaton, composed of circuits, capacitors, and so on, executing long sequences of tiny CPU instructions, and the job of software is to make it do something reliably and efficiently.

The new era is beginning, and the old era is ending. C and C++ as a lingua franca of systems programming are being displaced by Rust. Many will deny it, many will fight it. But I'm confident it is already happening and is inevitable to continue at accelerating pace.

As some people might now I am a vocal OOP critic. I think it is fair to say that I am on a crusade, actually. :D

Oftentimes, my long online posts explaining what is wrong with OOP meet with a No true Scotsman argument. That I am somehow pointing out to flaws in caricature of an OOP, and the correct OOP is free from these issues. To prove to myself and other people that it is not the case, I decided to go through some classic OOP books, and criticize the OOP examples in them.

My first choice is the Clean Architecture by Robert C. Martin (aka Uncle Bob). I must admit Uncle Bob is not one of my favorite software engineering gurus. But he is a reputable and experience developer, and if he was to write a caricature of OOP, then who are the people who dare to say they do it right?

Everybody does code reviews nowadays (I hope!). Research shows that it increases quality... blah, blah, blah.

But, how many times did you think about how much does it cost? Because you know ... Code Review isn't free. Code Review takes time. A developer publishes a PR, and then... what? Is there anyone readily available to review it? Other devs are busy doing their own stuff. Should the developer interrupt someone to get a fast review? Or just context switch to something else for now? I'm sure the research was not investigating this part.

Before most readers close this page enraged, shouting "Obviously, Code Review is good, you fool! It's totally worth it!" Yes, Code Review is worth it! I didn't say it isn't. I only said that it does have productivity cost and you should not ignore it. Please, while you are aware of the benefits you're getting, also acknowledge the costs you made to gain them.

I'm not just trying to be controversial and/or annoying. My point is: if you want to be good at something, you have to be mindful of both of them: benefits and costs, to maximize the former, while minimizing the later! Most of my guidelines below are going to be about minimizing the cost of Code Reviews.

This is going to be a quick overview of how I tend to write my application code. It might be a bit Rust-centric, but I apply similar methods in all programming languages I use.

I think it's an important subject and during past online discussions about learning Rust and writing code "the Rust-way", I was asked multiple times how do I do it. I don't really have a lot of time to write something longer and better structured, so please excuse anything that is confusing. You get what you pay for.

Also, I don't want to suggest this is some sacred, best way or anything like that. I think this is what I'm typically doing. A result of years of professional and Open Source work and experiences I gained during that time. I'm always happy to learn and get to know other points of view, so I'm happy to hear any feedback.

Test runners/frameworks caused me a lot of grief over the years. It's part of the reason why really appreciate how standard #Rust test runner works. As usual with Rust, core developers, and the community at very least avoided the most common misfeatures and made the right thing to be the easiest and most natural thing to do.

That's why i recently (probably too abrasively) bashed an announcement of some new Rust testing library.

I've taken some time and collected a list of feature request, misfeature rants, that I just want to share.