Object-Oriented Programming is Garbage: 3800 SLOC example [video]
youtube.com
youtube.com
The arguments against OOP seem to be 1) OOP obscures data structures by hiding them in too many data types, and 2) the boundaries created by these data types forces workarounds like extra fields to hold a root structure pointer even though it isn't part of the type.
OOP - in practice - does tend to encourage far too many types. A lot of these types are often represent code or design decisions, not the actual data. Instead of a "few" structs that clearly show how the data is organized, we tend to see OOP code that has the data structure spread out over various classes, interleaved with types that actually represent different actions (with the same data).
The solution I always try to keep in mind is that OOP can be useful if-and-only-if the data actually has a hierarchy. A single standalone class is equivalent to a basic struct passed to functions. The class only becomes worthwhile when are able to use polymorphism that closely model the data. The serious problems start when you try to force everything into a class; in extreme cases you end up with the Kingdom of Nouns[1]
The second argument seems to follow from the first; if you have too many types, you tend to take shortcuts like keeping a local reference to a parent or global object that is really outside your scope. This tight coupling creates maintenance problems and further confuses what the type is actually representing.
[1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
Not exactly -- a struct is equivalent to a class with public fields. If you have a non-anemic model class then you can guarantee that the object's state is within some boundaries (defined in the mutator methods).
You don't need a hierarchy to have polymorphism. The Observer pattern is very useful in my space game in Go. I wrote a small pair of Interfaces which makes it very easy for certain objects to register to receive notification when a ship despawns.
type DespawnListener interface {
NotifyDespawnShip(Ship)
}
type DespawnNotifier interface {
SetDespawner(Ship)
AddDespawnListener(DespawnListener)
NotifyDespawn()
}
type basicDespawnNotifier struct {
ship Ship
dependents map[DespawnListener]bool
}
func (self *basicDespawnNotifier) SetDespawner(ship Ship) {
self.ship = ship
}
func (self *basicDespawnNotifier) AddDespawnListener(dsl DespawnListener) {
self.dependents[dsl] = true
}
func (self *basicDespawnNotifier) NotifyDespawn() {
for key, _ := range self.dependents {
key.NotifyDespawnShip(self.ship)
}
}
No hierarchy is necessary in Golang or Smalltalk, because both have implicit interfaces and allow composition. (Golang is nice because its implicit Interfaces are made explicit and typesafe.)
The op is somewhat misguided. Good OO is comprised of good design, just as good computer games are comprised of good design. Expecting good OO of any programmer who just knows the "rules" of OO is like expecting the output of all game jam hackathons to be good games. Of course half of all OO projects found on Github with "obligatory" OO are going to show below average design, just as not every game from a game jam is not necessarily a masterpiece.
Saying "Good OO is comprised of good design" is meaningless - good code regardless of methodology is comprised of good design. You can't have good code unless it's been designed well. Good design is not a feature of the OO methodology, they are two independent properties of a program (design quality and methodology).
"Expecting good OO of a programmer who just knows the rules of OO" is exactly what OO was sold to us as achieving. By following the rules of OO design we were supposed to be able to automatically have better programs that were less likely to end up as spaghetti. If we wrote lots of small classes that just did one thing well and encapsulated their state properly we would magically have programs that were easy to understand and maintain, and we would be able to re-use the classes in other programs!
This was hardly ever achieved by anyone, and if it was it was independently of OO methodology not due to it. As you point out, reinforcing the op's points, it's very easy to get OO very wrong, even for experts.
I can change the underlying implementation of this subsystem, giving it additional capabilities, modulo some find-erase and compiler-guided changes, which I can be 100% sure are done correctly. Please give your own example of code which has the above properties.
"Expecting good OO of a programmer who just knows the rules of OO" is exactly what OO was sold to us as achieving.
As someone who was around for all of that rigamarole since the 90's, I am making precisely the point that this is wrong. The same goes for functional programming as well. The same goes for playing music or designing the inside of your house. There's a little practice, iteration, and self criticism that has to happen. Otherwise, what you get is pretty mediocre.
Keep in mind that the concept of a class unifies the concepts of modules and types. A class can be seen both as a module (with late binding, and of which there can be several instances) and as a record (with methods to abstract over the representation and allow polymorphism). The advantage is that you don't need a second module language on top of the type system.
Consider, for example, that as of OCaml 4 - with first-class modules and generative functors –, OCaml's module language is essentially a second fully-featured OO system. Using it as such would be awkward because of all the boilerplate involved (it isn't meant to be used that way), but all the functionality is there. This is basically because first-class modules provide late binding and generative functors allow for multiple instances of the same module.
But this means that, yes, you get more types because some of these types are actually modules in disguise.
> The solution I always try to keep in mind is that OOP can be useful if-and-only-if the data actually has a hierarchy. A single standalone class is equivalent to a basic struct passed to functions.
Not really. A basic struct does not have methods that abstract over the representation and does not support polymorphism. Also, it avoids duplicating language functionality for concepts with overlapping, but not identical functionality. Note also that structural subtyping does not require a hierarchy.
It's interesting how many comments there are, here and on YouTube, along the lines of the examples being "bad code, regardless of OOP", "not representative of a large team/project", "unmaintainable", etc. without even a link to an example snippet or repo, let alone a narrated walkthrough of existing code and possible alternatives like the author has provided.
Without concrete examples, all of these counter-arguments are in danger of a No True Scotsman fallacy. In fact, the code in the "embarrassing" video are actual examples of respected OO programmers showing how OOP should be done, which is a high bar to refute.
The author also addresses this a little, by pointing out the often-invoked circular reasoning of "my software's a mess even though I followed OOP", "if it's a mess you must not have been doing OOP properly".
I want a methodology that provides improvement on average, even with only partial uptake. Many other best-practises are independently virtuous, hence have this quality.
Object-Oriented Programming is Bad https://www.youtube.com/watch?v=QM1iUe6IofM
Object-Oriented Programming is Embarrassing: 4 Short Examples https://www.youtube.com/watch?v=IRTfhkiAqPw
I'm watching the 'is Bad' one, and honestly, it rings too close to my experience.
Need to think about this a bit more deeply!
edit: s/think/BELIEVE/
"a:b:c".split(":").first # Ruby
String.split("a:b:c", ":") |> List.first # Elixir
List.first(String.split("a:b:c", ":"))
Functional has other advantages. I quote Joe Armstrong on that: [with OO] "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." That wasn't much different with plain C though, which could do structs and be somewhat object oriented too if you coded in the right way. And you could end up with a jungle of functions as soon as you write enough modules that need each other.
So Ruby can be very easy to read because you can simply keep appending methods to the right.
In Haskell you can do the same, only you'll prepend functions on the left, so you end up reading expressions from right to left:
(intercalate ", " . map show . Map.elems) myMap
Streams.takeWhile(list.stream().map(e -> f(e)), e -> e.isNeeded())1. Expressiveness is important? Expressiveness is why I don't like Perl.
2. You can certainly implement patterns analogous to OO in functional programming with closures and first-class functions.
3. Reading in the order of execution via chaining is definitely a lot more intuitive than reading from the inside out or right to left.
I look at my code from 10 years ago and it is written with objects and late dispatch as main modeling tool and that code is terrible.
Text is so much better for evaluating arguments. When reading you can spend variable time on different parts to skim the obvious and go deep into the more difficult stuff, you can random access it later to refresh your memory, you can quote it.
Videos are probably only better in persuading people - but that requires that they watch them (and maybe get some stockholm syndrome after wasting so much time :).
https://medium.com/@brianwill/object-oriented-programming-a-...
and the HN discussion here:
Still apparently the whole argument is only in video:
>>> [Edit: I’ve greatly expanded on these ideas in a 45 min. video.]
Get used to it.
Visually scanning well-written prose that is laid out correctly (easily recognized headers with good content, good paragraph layout) IMHO is way faster than finding the meat in well-written presentations that are presented and recorded properly.
One possible counter-argument is that the resulting procedural code is more difficult to unit test. In the video Brian acknowledges that he doesn't think much about cyclomatic complexity, but I think if you were to try to test one of these long functions with a lot of branches, the setup required for each case you want to test would dominate the amount of code devoted to the actual test. The solution to this isn't necessarily OOP, but I would not want to maintain Brian's code as it stands without refactoring it.
The more fundamental problem to me is that Brian's code requires you to read it fully in order to understand it. No part of the code is difficult to understand, but it demands that I understand it in detail before I can have a summary of it in my head. I prefer for code to read more like a newspaper article, where the further down you read, the more detail you're given, but you can stop at any point and have a decent understanding of what's going on. To me this makes it easier to reason about the system as a collection of sub-systems, which is often the level at which the really important decisions are made. Again, OOP isn't the only "solution" for this, but I think it's a good tool. It does have the potential, as Brian points out in one of his earlier videos, of devolving into philosophical exercises, but I don't think that's necessarily a drawback if your goal is to make it easier for humans to comprehend your system. In designing your system this way, you're simply taking advantage of people's natural ability to think in abstractions.
The interesting part of this is that although you kind of know that positions with as little nuance as Brian's have to be wrong (because the world isn't simple), it's still important to think about why you hold your own positions instead of dismissing any challenge to them outright. I think it's good to think about why we use objects and whether we need to do it as much.
What we especially lack in programming is any evidence for our practices. The best we currently have is opinion and experience. That means a lot, but not as much as empirical evidence, and I think we tend to forget that too often.
I get the logic behind why he likes long functions that have the meat of the program in them. I've hit code bases before that have broken out bits of logic into separate functions that are badly named and defined and I ended up hopping around the program trying to work out wtf is going on.
As long as we keep the subroutines nice and tight and well-named they're an aid to understanding the program: I can guess what `writeTextToFile(text,filename)` does, and I'd rather see that in the main logic routine than 50 lines of the code that writes text to files.
I will carry on writing short functions, but it's good to know that I'm doing that for a reason, having challenged it.
It boils down to the fact that it's very easy to have unexpected state dependencies/constraints in those smaller functions, that is non-obvious by just reading them. If they're called when those constraints are not met, it is a bug.
What happens when something is recursively buried in 90% crap? Is its own 90% particularly crappy?
But of course some people want to create 10 level class hierarchies, replace every 'if' with a subtype and using design patterns ate every occasion (especially the factory, so instead of writing 1 or 2 they will have a OneIntegerFactory, a TwoIntegerFactory, etc)
One advantage into Go for example is that it reduces the potential of misuse of "OO happy" people
(a) It's an order of magnitude more difficult to write original code than to port code from one domain to another.
(b) It's an order of magnitude more difficult to understand someone else's code than something you've just finished writing.
It would be a different story had he had created the rewrite, and had a third party discuss both versions.
Having that many functions, that are called only once, means you have to make more non-local jumps to read said code. This is not ideal.
Moreover, such a break-up obscures the dependency graph in the code. Many nodes (functions) will have only one inbound edge (call). While collapsing the original graph to a canonical form will likely yield the same result on both code bases, the original code still show 3 times as many nodes. This makes it harder to see the real dependencies. Again, not ideal.
Finally, there's the possibility that the procedural version made genuine simplifications to the dependency graph. If it really reduced coupling while keeping the LoC count the same, that's a net win.
Granted, those measure are not nearly as definitive as the LoC count itself. Still, they do suggest the original code is not as straightforward as it could be.
Now to really know, we'd have to read the code.
Readability, testing? What seems odd is that there are now fewer functions, but the same LOC count, therefore apparently more code/statements. This looks like he had to actually add code to replace the original structure, which seems superfluous.
The key point is discrete. If you fail to carve the program at its joints, and no more, you'll only make it worse. I too separate functions even if they're called only once. I just require that the interface of the function be easier to understand than its implementation. That's not always true, especially for short, impure functions.
> You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body.
I don't need functions to do that. I'm not writing JavaScript. Here:
{
int foo;
float bar;
baz(foo, bar);
{
int wiz;
float woo;
wak(wiz, woo);
}
klo();
// klonk(wiz); // error: wiz not in scope
}
I can still put comments. They notoriously rot, but the same is true of function names. Plus, comments aren't restricted to identifiers, so I can write plain English:
{
// ...
{ // Waks the wiz with the woo
int wiz;
float woo;
wak(wiz, woo);
}
// ...
}You don't even need to agree with the author at the end to learn something interesting. Or even (OMG) something you didn't think about before and that will improve your super-OOP code.
I only know one problem domain where a form of an OOP is required (although it must be built on top of asynchronous messages, i.e., none of the existing popular OO implementations would fit) - agent-based simulations. It is well below the 0.01% threshold I set so generously.
And please do not confuse the OOPish language features (which are just poor man modules support in most cases) with OOP-the-design-methodology. The latter is garbage, the former is just an innocent bunch of language features.
Btw., it is funny when OO zealots are calling anything else a "religion". They should look in a mirror first. OO is a religion and nothing but a religion.
I don't know how to go about debating the merits of OOP, aside from saying it's convenient for things that... behave like objects. And of course there are multiple ways to skin a cat, so you can reply with alternate ways to code graphical widgets etc. And then I say you're putting the horse before the cart, and you say the same to me...
The only thing I'd be dogmatic about is that programming is still a complicated mess, and it will likely remain so for decades. Nobody has any of this remotely figured out, so it's probably best to be pragmatic, rather than commit oneself to purported "magic bullets" (whether they be OOP, POP, Functional, Procedural, etc).
My guess is that the real "magic bullet" will come from AI. I doubt human beings are smart enough to reason about what good programming practices look like. So until an AI comes along to tell programmers how best to design code, it's all just a matter of personal preference.
> I doubt human beings are smart enough to reason about what good programming practices look like.
You don't need to be smart to reason, after all, reasoning is a formal, mechanical thing. And there is always a mechanically derived best possible model for each and every problem domain. So it is in fact always very easy to prove that OOP is inadequate and another model is this many times closer to the formalism of the problem domain. For every problem domain out there. There is no place for personal preferences, it's all formal.
Well, I admire your optimism, at any rate.
If you want to have a paradigm that is really succesfull, it would involve using every aspect of the human mind. We are good at perceiving 3d space. We are good at instantly computing physics. We are good at perciving other human behaviour. We are good at recombining existing tools to create more sophisticated tools. If you want optimal results, without the struggle of reeducation, tailor the paradigm to the existing creature, not the inverse approach.
Of course OOP is unnecessary since you don't need it to write good software. But one could argue that all paradigms are unnecessary since you could technically write any program using any paradigm. OOP, procedural, functional, whatever. My point is that people are different, use whatever you are most comfortable with.
EDIT: Check Bob Burrough's comment to the youtube video. He worded it much better than me.
The truth is that OOP is in most cases the worst possible way to model the real world. There is always a much more adequate model (besides the single case I mentioned before). So, sticking to a paradigm that does not work at all is nothing but a religion and should be treated as such.
That's a baseless assertion. Just because you developed a distaste for a particular programming paradigm it doesn't mean that your baseless assertions are suddenly sound.
> So, sticking to a paradigm that does not work
Somehow, the software world is founded on something that you somehow claim doesn't work.
Perhaps you've taken your pet peeve a bit too far.
What the OP did is still a worthwhile exercise. And although it seems to have been an accident, he made a good choice of program to study in this fashion. Because it is an emulator, what it needs to do, and therefore much of its design, was predetermined before the first program was written. That makes the comparison with the second program somewhat less vulnerable to your objection, though we have no way of measuring how much.
You're making a good case that it reduces the effect of initial design discovery since it's based on well known hardware.
Showing that one single person can write a small procedural program that's more structured, faster, etc. than the corresponding OO code written by someone else is not very relevant for real-world projects. I'm not saying OO is great everywhere, but devs in the industry have been writing working code on large scale using OO.
Modularity isn't a mere "site effect" of OO: it's one of the main motivation factors that have lead to OO.
In fact, the main problem with these anti-OO rants made by procedural purists is that in essence they all boil down to claiming that basic OO features that are a part of any OO language can be reimplemented in procedural languages.
OO got no rights whatsoever to highjack the benefits of the modules. There are some very successful module systems that got absolutely nothing to do with any OO bullshit.
You're the only one who's trying to make that assertion. It's a strawman, and a poor one at that.
1) having data structure and its methods isolated in a module is not a bad thing. Modules provide an obvious boundary between pieces of code, so when calling some code from another module you know that you should care only about inputs and outputs and not about the particular implementation of the transformation. But when you have the same pieces of code mashed together in one module – that boundary is blurred, now compiler does not tell you that they don't interact via some shared state not named explicitly.
2) defining an interface to do a type switch. Really? Even if that interface is not exported, this still leads to more fragile code. When you rely on interface compiler will yell at you if you miss a method. But when you add a new type and forget to update one of those type switches – it will blow up in your face at run time. This is less relevant for NES emulator, since it was designed long ago and unlikely to get new entities that need to be accounted for, but doing this for no good reason can establish a habit that will bite you later in other projects.