A while ago I came across this youtube video, which broadly denounces the programming paradigm known as “Object Oriented Programming”. (OOP)
If you’re not a programmer, you might not get a lot out of it. Author Brian Will is deliberately talking to other coders and so the whole thing is fairly dense with jargon and theory. That’s fine. I’m going to translate bits of it for the purposes of our discussion here. In fact, this series is aimed at non-coders and casual coders who are curious what all the fuss is about and what people are talking about when they say “Object Oriented Programming”.
Depending on who you ask, this video is either obvious, slightly controversial, or deeply heretical. The author certainly seems to believe they are about to say something likely to induce backlash. And indeed, with just over one-third of the people giving the video a thumbs down it does seem to be an unpopular opinion. After watching the introduction I was prepared for the screed of an iconoclastic madman. But by the end I didn’t find anything particularly objectionable. In fact, his final guidelines basically describe the coding style I’ve developed over years of working in both new and old coding paradigms.
I might quibble over a few points, but I think Will is pushing back against a bit of orthodoxy that doesn’t get challenged nearly enough. This debate has popped up now and again over the years and it usually ends with a bunch of people talking past each other and arguing in circles. This is partly because it’s tough to challenge entrenched ideas, but mostly because programming is not one job, but dozens of different jobs.
One Paradigm to Rule Them All
People often make blanket statements like, “Code should be X” or “NEVER do Y because it’s too slow” or “Stop doing Z, because it’s insecure”. These statements will strike some people as preposterous others as completely obvious, depending on what domain they’re working in. One of the major problems with discussing programming is that far too often we talk about it as if it was a single discipline. Imagine if people who repaired stuff were all simply referred to as “mechanics” without ever bothering to specify if they work in automotive, aerospace, HVAC, electrical systems, security systems, robotics, or civil engineering. It would be chaos.
People working on financial software have security and precision needs that would seem absurd to someone making a videogame. A videogame programmer has performance concerns that would seem unreasonable to someone working on data collection and analysis. Someone working in social media is probably really worried about distributed systems and scalability in a way that would seem alien to someone working on embedded systemsRoughly, an embedded system is a fixed set of programs used to drive a device. The operating system of a camera, television remote, CD player, or weather satellite are all examples of embedded systems..
Which is fine. The world of programming is getting bigger all the time. As computing power gets cheaper we keep finding new and inventive uses for it. And yes, there are different languages for different jobs in an attempt to address these differing needs. But often people discuss programming in this abstract theoretical sense that disregards all of these differences and assumes the problems they experience are universal to all programmers.
Look at any debate over coding theory and you’ll see a couple of engineers slugging it out without either of them ever specifying what they do for a living. If pet owners discussed their animals the way programmers discuss their craft, the debate would look like this:
“I suggest grooming your animal with a typical hairbrush at least once a week.” (Woman who owns a dog.)
“I am so sick of seeing the same useless suggestions given again and again. A hairbrush is designed FOR PEOPLE. Repeat after me: DO NOT USE HAIR-BRUSHES FOR GROOMING PETS. You’ll want to use something long that will enable you to reach the difficult high areas on the animal’s back. They sell long-handled brushes at the hardware store. Use one of those, and scrub the animal with warm soapy water before rinsing it off with a hose. Alternatively, sell your pet to someone who knows how to care for it properly!” (Guy who owns an elephant)
“Nobody here is thinking about safety. Sure, go ahead and blast your pet with a hose and see how long it takes for them to bite you. SAFETY is the most important part of pet care, not cleanliness! All that scrubbing won’t do them any good if you end up dead in the process.” (Guy who owns a cobra.)
“It’s always amusing to see just how many people overthink pet care. I suppose it’s easier to read articles online than to learn what your pet needs by getting to know them. Do you know that your pet is perfectly capable of grooming THEMSELVES? Amazing I know, but they managed just fine for millions of years before humans came along. Leave your pet alone and just enjoy the cuddles.” (Lady who owns a cat.)
“Did you seriously suggest “cuddles”?!!?! Your pet is not a toy! Leave it in the tank where it belongs and enjoy looking at it. It will live longer that way. Idiot.” (Dude who owns fish.)
Kids These Days
Contributing to the problem is the fact that the people who teach programming are for the most part not the people who actually do programming for a living. The people teaching kids to solve problems aren’t out in the real world solving real problems. Programming is typically taught by mathematicians and academics, not by seasoned veterans of the profession. We end up teaching kids to create new code for a world of abstract problems.
What you’re taught in school:
“Write a program from scratch to find the first 1,000 primes larger than three digits and print them out using English words instead of numerals.”
What you’re asked to do once you get a job:
“Our accounting reports are generated by 100,000 lines of spaghetti code. It was written in a mix of C and C++ by a long line of transient programmers over the course of three decades. Get in there and figure out why the even-year reports are always off by one day. Fix the problem as fast as possible, while changing as little as possible.”
While I’ve never been to university myself, I’ve certainly talked to quite a few university-educated programmers. And I’ve never once heard of students being asked to work on an existing codebase. I’m not saying it never happens, but anecdotally it’s not common, even though that’s what you’ll be doing in the vast majority of jobs.
This is not to say that academics are numbskulls or that we don’t have anything to learn from them. You could boot Professor Smugbones out of the university to go write “real” code for a few years. But during that time, he wouldn’t be teaching anybody. And it would take some time to distill all of that practical experience into some sort of curriculum. And by the time it was being taught in class, parts of it would be irrelevant because while half of this vocation is mired in the tar pits of 1975, the other half is experiencing radical and transformative change every couple of years.
The book Teach Yourself C++ in 21 Days is a pretty good example of this problem in action. It’s more interested in teaching you Object-Oriented Design than programming in C++. For example, it’s doesn’t really dig deep into dealing with header files, using external libraries, dealing with C-style strings, or memory management, even though those are complex topics that greatly impact your work and are required to make anything genuinely useful. Wrangling libraries, header files, and development environments will probably be a huge part of using C++ for most people. Instead the book spends about a third of the page space explaining how object-oriented programming is supposed to work.
The book uses funny example programs like: Hey look, you can make a base class called “mammal”. And from that we can derive the class “pet”. And then we can derive a class for cat”. And check it out, you can then do Cat.Meow () and Cat.Sleep ()! Cool, right?
Maybe this is helpful to programming newbies, but when I read the book 15 years ago I spent the whole time scratching my head and wondering how any of this could be used to solve Real Problems. I’ve never seen (or heard of) a problem that allowed for a clean, intuitive structure as clear as Mammal»Pet»Cat. Objects in a program are very often only sort of similar. Two things will share a lot of superficial similarities but in practical terms they end up being totally different in behavior. They’re similar enough that Dogs and Cats do similar things – like Sleep () – but they do so in different ways, at different times, and in response to different situations. A lot of the same concepts appear again and again, but they don’t share any code and it leaves you wondering why we spent all of that page space on Pets and Mammals, trying to connect two dissimilar systems because of cosmetic similarities.
(Note that I’m just as prone to domain bias as anyone else. Maybe there really is some discipline out there where things like Mammal»Pet»Cat is amazingly useful. But I haven’t seen it yet, and so a lot of the features of object-oriented programming come off like someone trying so hard to be clever that they forget they’re supposed to be solving problems, not building abstract frameworks for aesthetic reasons.)
I’m not saying that Learn C++ in 21 Days is a bad book or that academics don’t have anything useful to add to computer science. The only reason the profession exists at all is because some professors invented it on the blackboard decades before guys like me showed up to pick through their discoveries and build our careers off of them.
Academics tend to come up with a lot of ideas, both good and bad. Academia is where ideas are propagated. It’s up to the software engineers to sort the good from the bad and figure out which ideas are worth propagating and which aren’t. That sort of exploration takes time.
To put it another way: With each new graduating class there’s a steady flow of knowledge coming from the university to the private sector. But we need to make sure some information flows the other way. Videos like the one Brian Will made are part of that process of sorting the good from the bad and sending the information upstream for the next generation.
Next time we’ll talk about what OOP is and why we need it. (Or don’t, depending on who you ask.)
 Roughly, an embedded system is a fixed set of programs used to drive a device. The operating system of a camera, television remote, CD player, or weather satellite are all examples of embedded systems.
Silent Hill Origins
Here is a long look at a game that tries to live up to a big legacy and fails hilariously.
Games and the Fear of Death
Why killing you might be the least scary thing a game can do.
Spec Ops: The Line
A videogame that judges its audience, criticizes its genre, and hates its premise. How did this thing get made?
Push the Button!
Scenes from Half-Life 2:Episode 2, showing Gordon Freeman being a jerk.
Trashing the Heap
What does it mean when a program crashes, and why does it happen?