This was a totally legit critique of the shitshow that is “enterprise software development culture” IMHO. It wasn’t for showcasing what a good programmer Casey is, but how bad the software development process at large companies has become.
Of course not, because it was just a proof of concept created to prove that microsoft is bad at software (no shit).
This proof-of-concept directly lead to Windows Terminal getting a more performant text rendering engine:
I enjoyed the talk. Every craftsman and professional should show interest in understanding the history of their craft, lest he becomes one of those “practical” men John Maynard Keynes spoke of[1]. Often the ‘harder sciences’ and disciplines are the more likely to fall into this trap. Go through an undergraduate course in most engineering/science programs, and you will rarely hear anything about how we came to believe and think the way we do.
In more “soft” disciplines, such blinders can be unnecessarily limiting. Software engineering (defined as the practice of designing and building software) is such a discipline.
As an example: See how many people don’t even understand Dijkstra’s “goto considered harmful” paper. The paper is well known. But what is less well known is that it is for most purposes defunct in the modern era. Dijkstra won. Aside from C’s setjump/longjump, I don’t know of any modern high-level language that allows for unrestricted goto. Yet people will reference this paper as evidence of why you shouldn’t use goto in C. (There may well be other good arguments, but dijkstra isn’t one of them).
It’s a fair criticism to say that Casey is clearly biased against Object Oriented Programming, and that it colors his thinking. You should take his arguments with some lumps of salt. It still is valuable to see presentations of history that most people don’t even give you, and I think history is too valuable to leave to academics.
I think Casey does fail to show why Object Oriented programming became so popular. If it was/is as bad as he says, it is an incredibly important question to show why and how it became popular despite it’s ill-suited nature to software engineering. That is a talk that i would like to see.
I have some ideas, but it would require research. Suffice, i think engineering management, and what businesses valued came into play. Businesses Value software as a capital good, and so want software that can be maintained and changed into the future. OOP promised this, though it’s delivery might be less than desired.
I think it’s a fair criticism. And one that is worth asking ourselves individually. Is my favorite past time constructive or destructive?
“Practical men who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist. Madmen in authority, who hear voices in the air, are distilling their frenzy from some academic scribbler of a few years back” Quote by John Maynard Keynes: “Practical men who believe themselves to be quit...” ↩︎
Your overall recap is on point. Wrt this point, here’s a different way to look at it. You could keep focusing on identifying what’s wrong with OOP, or you could instead work on identifying alternative patterns that provide clear advantages in one situation or another.
As an example, see Andrew’s talk about DOD:
In it you will see that he doesn’t waste a single word talking about OOP being bad, and instead focuses entirely about the good properties of DOD.
So after you know about this approach, then the next time you have to design something, you can make a more informed choice.
I’ve written some parsers for the languages related to Zine and, while I have yet to go full DOD, I’ve stayed away from many OOPy patterns, not because I focused on what’s wrong with them but because the alternative provides advantages that are relevant to my use case.
As an example my parsers put all AST nodes into a single array list and use indices into the array instead of pointers, which means that I have:
The day that I’m doing something where these properties are not as important (I like Zine being faster than any other SSG I know of), then I might go OOP if it makes sense, why not.
I personally think the answer is basically the GUI transtion in the early 90s.
There was this nice joke on X that the only good fit for OOP is GUIs, and I think there’s some truth to that. I was “lucky” enough to witness the mainstream adoption of OOP. Graphical OSs were taking over, but Win16/Win32 development was incredibly annoying. Then these nice toolkits came along (MFC etc) along with widget hierarkies that made it… well, make sense, while C++ provided decent performance.
The documentation was also absolutely stellar. Widgets were reusable, easy to wire up visually, and it was all pretty darn productive.
Problem is, this early success of OOP made people think it was a panacea while in fact it is just a decent paradigm for a few select domains.
Personally I still consider it a mediocre approach that lead to a mediocre result and will take Ghostty over whatever happened there any day of the week.
I would say that it’s the public backlash that lead to that and, sure, refterm helped (make the crowd of onlookers angrier), and maybe the microsoft people copied some of that code, but in my opinion that’s still not that we should be aiming for.
I think you deserve way more respect for having made Sokol, than you would have if you stopped at some kind of “refgamelib” proof of concept only to support your compulsive tweeting, even if that led to somebody else making a better lib :^)
One application where I find classic OOP makes sense is in industrial control systems, though in combination with S88. There’s a real correspondence with physical hardware, and this is where I feel interfaces, inheritance, and mild polymorphism can be beneficial.
But then again industrial systems are simple state machines. OOP does help slightly with code reuse, but an ideal PLC program shouldn’t be so complex that it necessitates OOP to be maintainable.
Edit:
There are bigger battles in PLC programming. A good chunk of PLCs making the stuff we consume daily are still programmed with ladder diagrams, where you don’t even have loops and you’re forced to express everything as combinatorial logic.
OOP definitely works and solves real problems, not just GUI (mitchell just wrote about that) but also things like transparent-networking (RPC and friends) and developing in parallel, or even in advance:
Let’s say you just won a (business) contract but you’re shipping just a small part in the bigger release, and guess what, some of the teams/vendors get behind the schedule and you don’t have their code yet (or sometimes it’s not even disclosed) so you need to work against the interface.
It is certainly not ideal, but I know for sure it’s better than not shipping anything. Things are very different in enterprise. Sorry for a little off-topic but I always get a bit heated up whenever people think that doing things differently ~= wrong. And it’s not about discussion here but rather about the general OOP anti-hype (which IMHO is not any better than the previous pro-hype)
BTW: The 90-00s era of GUI was IMHO golden, you could buy packs of pre-made components, you could subclass them easily and do some changes here and there and everything worked great. I hope it’s just not that it’s so long and that brain prefers to keep positive memories but I think we lost something there…
The Lua programming i’ve done makes me read that as “I awlays get a bit heated up whenever people think that doing things differently [does not equal] wrong.”
You have that same thing with Dear ImGui (which is as anti-OOP as it gets), except that a ‘component’ is just a function with a couple of Dear ImGui calls in it, but as simple as it is, it works wonderfully to build big applications from small reusable UI ‘components’.
I think the main problem with modern UI systems is that most of them are created by large teams in corporate environments, and this scenario simply tends to produce shitty software - OOP or not doesn’t matter in this case.
I think hype in any direction can easily become misguided.
From various things I have heard from Casey, it doesn’t seem to me like he is against OOP in all cases, for example he has mentioned that it can be useful for api/responsibility boundaries, I think he is mostly against it when it is used in a dogmatic way, without reflecting on the real tradeoffs and considering the alternatives.
I think one of the main problems with OOP is that it allows you to do anything, for example if you want you can implement an emulator and then run your actual code in that, that is an incredibly useful ability, but if everyone implements their own emulator for every problem, that can easily lead to slow code. So basically it requires restraint, so that you don’t end up using it too much, but only in cases where it really is a good fit.
Basically don’t use an interface if tagged unions and switch statements are all you need, so that you end up with a simpler program that is more likely to be performant by default (just by not adding unnecessary abstraction).
If your problem is much more complicated, then it may be useful here and there to have some more abstractions, but even then it makes sense to limit that in some way, so that you can retain sub-parts of the solution that can be implemented in more simple ways. And if you do add abstractions you should be careful about how you add them, so that you don’t end up slicing your problem in a way that makes it more difficult.
I like the sort of thinking of multi-paradigm languages like what is described in the book “Concepts, Techniques, and Models of Computer Programming”, that basically any programming language can be seen as constructed from a small set of kernel/core language features, which result in a computation model that has different tradeoffs. It does a good job at describing how certain features (concurrency, state) make some things easier, while at the same time making other things harder.
Through reading, thinking and experimenting with those concepts from the book, it helped me with getting new perspectives for thinking about problems/solutions (even if you don’t end up using a multi-paradigm language).
It also has this diagram that categorizes languages based on features The principal programming paradigms.
I think discussions around programming languages and paradigms would be more useful, if we actually broke it down to more fundamental features and concrete problems.
For example whether something has:
and whether the problem you are trying to solve actually benefits from the presence or absence of certain features.
All those combinations of features have different tradeoffs and some part of a program may be better written with one set, while another requires other features; and then those different program parts can still interact and share data, one embeds/uses the other etc.
I think the point Casey is trying to make across all of his content, is that OOP shouldn’t be as dominant as it is. He tried to show that it isn’t as performant, which is true in most cases, by doing an amazing talk where he explains that OOP makes you think in terms of objects, instead of groups of objects, and that even that wasn’t enough because what you really should be thinking about, is not groups of objects, but systems of groups. He tried to show that it doesn’t even bring most of the benefits people claim it brings (flexibility, composability, readability). But people kept saying it’s because you are doing it wrong silly! So he tried to look at the history of that technique and show that no, in fact even the people who created it, or popularized it, were actually describing what we are seeing today.
Ultimately what I think he is trying to say, is that OOP isn’t good or bad, it’s just a technique it has its uses, but it’s clearly not the right tool for most software, and it leads to bad or suboptimal solutions all of the time, which is frustrating. People should just be less dogmatic and try new ways to solve problems.