Max Gross

software engineer, web developer, cat companion

I remember learning about object-oriented programming in some of my earliest computer science and programming classes.

To me, the paradigm of OOP is a simple and alluring one: A business application is often filled with things. Users. Emails. Network sockets. These are nouns, and actions happen with them. It makes so much sense to abstract them as email.send(), doesn’t it?

If only it were that simple.


The more that my day-to-day work has been software engineering, the more that I’m convinced that object-oriented programming has gotten it all wrong. Software programs are not about things; software programs are about actions.

An accountant does not open Excel for the spreadsheet, but to perform calculations. A dog owner does not open the camera app for the images, but to take photos.

Even the stuff closer to the metal is about actions: grep is about searching, not text. git is about change tracking, not files. The x86-64 instruction set is literally a set of actions.


With that in mind, I have been increasingly struggling to think of situations where object-oriented programming would make sense in a day-to-day basis.

Maybe a monolith, so an instantiated object will always remain available in memory? Or in a utility package, as a form of encapsulation, so the implementation details are hidden from external users?