It’s almost a cliche at this point, but since there’s still an argument I feel like I need to pick a side: OOP has outlived its usefulness.
That’s not to say it was never useful or that the people working on OOP languages were bad engineers or even that it still doesn’t have projects it’s a good fit for, but the scope and nature of a vast majority our projects has blown past it, and the same things that made it useful are now liabilities.
Most arguments for retaining OOP blame developers for using it poorly and … yeah, okay, sure. I’ll give you that one, but I challenge you to show me a paradigm that isn’t used badly sometimes. And when OOP is used badly, the results can be catastrophic. When you have a hundred developers working on the same project that contains a million lines of code, shared mutable classes are a landmine. Here’s something uncomfortable that more developers need to admit:
Any language or paradigm, done perfect, works well.
But we’re not perfect: we’re people. Projects these days are larger and more complex, and the human memory has hardware limits that they’ve long since blown past. Somebody is going to get lazy, or have a bad day, or not be able to talk to a senior developer at a critical moment and push ahead with something they shouldn’t, and it’s going to send the whole jenga tower crashing down.
The more complex a project is (and the more developers it involves) the more likely you are to run into an imperfect piece of code. OOP was designed for a time when writing code was limited to universities and garages, but now it’s got a huge chunk of global GDP resting on its shoulders and I don’t know whether it’s safe for it to take the strain.
Also, just to get this out of the way: Alan Kay’s original dream of OOP languages wasn’t like this. Kay is an incredible scientist and I’m not here to stomp on his legacy. Eric Elliot has already covered it with more insight and detail that I could dream of, but classes and class inheritance aren’t part of OOP as it was originally conceived. The most problematic part of the paradigm came along later and made itself into one of the three pillars, but the house was standing up fine without it.
I’m also not against the idea of OOP entirely: it’s a good fit for certain projects. It has been the defining paradigm of the last 20 years of computer science and—as far as I’m aware—hasn’t been responsible for any plane crashes or nuclear meltdowns. It has been responsible for a lot of spontaneous swearing from the IT department, but so has a bad draft in fantasy football. OOP works well on small to medium projects, especially with a close-knit team with a lot of testing and oversight. When you’ve got six hundred developers in coworking spaces on four continents who only communicate with each other via Git Commit, that’s when things get hairy.
Java has mandatory OOP and looks like it’s not going anywhere for a long time, but possible competitors like Kotlin have multi-paradigm support and I think we need to start looking towards these languages to help make the transition. Java really is the biggest issue: it’s immensely popular and replacing it is going to cost absurd amounts of money, but its dominance is slowly being chipped away. FORTRAN and COBOL defined a generation and a lot of younger developers probably don’t even recognise them.
There’s so much resistance to the idea that OOP might need to go. We’ve all got twenty years of college courses and C++ codebases and good times that it’s hard to look back on poorly. It’s always hard to say goodbye. Maybe we need to do: we have more options than we did in the 90s when Java first rose to prominence, but we’re clinging desperately to old paradigms that just don’t work with the code we’re writing.
If you are looking for a software engineering job in Kolkata, CodeClouds is always hiring talented professionals. If you think you have what it takes, head over to their career page and learn more.