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.
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've never seen anyone mentioned an argument that is pretty obvious to me, and invalidates the whole “logical” and “mathematical” conclusion, and proves that people's intuition is correct.
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.