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.
One problem that I have when discussing OOP is the “no true Scotsman” fallacy. Whatever criticism one has against OOP can be always rejected with “that's not a real/good OOP”.
So here is the dare – send me links to public Open Source projects that you think are an example of superb and excellent OOP code. It doesn't have to be fancy, but it has to be a real project doing something useful end to end: not a library or a framework. You can find the mail link at the bottom. I did some Google searches looking for similar questions (and answers) and I haven't really found anything useful.
Please share this post if you're also interested.
My plan is to collect some projects, pick up handful that I find best, and then apply common OOP criticism to a concrete code that other people find the best in class.
I will make sure to edit this post and add them below.
I was just recently mulling over how interfaces (Java-style) for data types are pretty much always the wrong thing to do.
Putting an interface means losing a resolution on something. Now you have to talk to it through a generic approximation. The benefit of that – you can now talk to anything that implements that interface, which means an open set. Anyone can come and add a new thing that implements that interface and it will work, without changing a line of code. Drawbacks: All the additional information about that thing is lost, and you have to come up with that interface which is not a trivial task. As the business logic changes, such interfaces often need to be revised. And as any abstraction and indirection – it introduces some confusion and mental tax.
In a typical business setting, data shape type is almost always a closed set. Even if you have N versions of some you want to support, you don't expect random external developers to add more, without altering the broader code around it. The closed set of allowed formats can just be expanded, new cases handled and the job is done. And business logic is never as simple as we would like and very often requires conditional handling, which is just painful to express via interfaces. A “switch statement” is more flexible and can do whatever without bothering with defining a contract between the data and the code using it.
While there are exceptions and it is all context-dependent, as a rule of thumb, avoid stuffing your data with interfaces, and use sum types.
If you copy&paste, or even accidental reuse a copyrighted code or other materials in your personal project, and a Big Co. finds out they're going to sue you and/or take down your project.
If Github/Microsoft scraps all of GPLed code they can find and feeds it into a database and obfuscates it calling it “an AI”, then start selling it for money, apparently it's supposed to be a “fair use”.
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.