OOPs! The Programming Blooper That Became Mainstream
Object Oriented Programming (OOP) has been a staple of software development for several decades, with its roots tracing back to the 1980s. OOP has gained widespread adoption due to its focus on creating reusable code and its ability to model real-world objects and their interactions. It is the most successful paradigm of programming because of the support by the industry. But some argue that its success is merely a coincidence. OOP, as the name suggests, is a programming paradigm based on the concept of “objects”. These objects contain data along with the code that manipulates them. This essentially enables developers to maintain, develop, and scale applications with a lot more ease as the data is organised and the code is structured to be more intuitive. Undoubtedly, OOP is the dominant paradigm, but the argument is that most of its success is associated with languages that just happen to be OOP, and not because they were OOP. The origin of OOP started with C++ in the 1980s by Bjarne Stroutstrup, which were originally just extensions built on top of C. This added more object orientation on C++ when compared to C, which is argued as one of the reasons why C++ became so popular. In 1981, David Robson, in his article in Byte magazine, introduced Object Oriented Software Systems. He said that it is now a complete departure from traditional programming methods like functional programming, that have an imperative and top-down technique. Then Java came into the picture and wanted to follow the same approach. And it did. Along with C++, Java and Kotlin reign the Android development ecosystem while Swift and Objective-C rule iOS. For web, ML, and beyond, Python, Rust, JavaScript, PHP, and Ruby are on top. All of these are heavily object-oriented. This has almost made it imperative for all developers to understand this approach. If we consider it, before OOP turned up, procedural programming was everything. Almost all of the real world applications like operating systems were originally built using languages like C. It seems as though, maybe OOP is not driving the success, but just taking the ride along. Riding the Success Train The technical reason why developers love OOP is because of its encapsulation ability. What that means is that the data is hidden from the other parts of the language. The encapsulation contains both data and the methods or behaviours related to objects. This allows complex code to be abstracted into reusable objects allowing developers to build complex systems in an organised way, while also allowing code reusability. However, abstraction is actually not a defining feature of OOP and is separate from it. Grady Booch said that abstraction is actually a complementary concept to encapsulation. This means encapsulation hides internal information, but abstraction provides an external, easier-to-use public interface to data. This can be achieved in other modules by isolating a set of data and operations on those data within a module. Moreover, when OOP first came out, and even now, programmers struggle to organise code into large meaningful objects that mimic the parts of the problem. Some even claimed that OOP required harder testing and extra care for refactoring. The ultimate goal of a language or approach is to write reliable code, simplify it, and remove bugs, but OOP is mostly hated for its complexity. Even then, OOP has been fairly well received for now. According to the Stack Overflow Developer Survey 2022, Rust, an OOP, has been the most-loved programming language for the past seven years. ‘Gorilla Holding the Banana’ A Reddit thread encapsulates the reasons why the OOP approach is invoked by so many developers. Some say that since university students were never introduced to functional or logical programming, they automatically assume that OOP is the best, and the only way forward. It is also more difficult for newbies to understand these languages as they are more rigid as they follow a specific structure, other than a free-flowing approach like functional programming. This was explained by Joe Armstrong, the creator of Erlang, as ‘you wanted a banana but got a gorilla holding the banana’. What this means is that OOP languages come with an implicit environment around them, which results in the lack of reusability. While on the other hand, referentially transparent code that does not leave anything behind is very reusable. At the same time, many developers find procedural programming with languages like C easier. The structure and rigidity offered by the OOP approach is oftentimes regarded as the problem. Moreover, it is difficult to accommodate changes and introduce new things. This even hinders the performance of the languages. The language becomes complex to learn and understand, especially when the number of objects and interactions grow, numerous interrelated objects grow, leaving the code prone to bugs and errors. Ultimately, it’s a mixed bag. Though OOP still remains the most popular, it is still complex and rigid, bringing in a love-hate relationship with programmers. Moreover, its abstraction and reusability features are not as special to it as one may think they are. But on the other hand, these are what make them so attractive. But the point to note is that the current trend is shifting towards a multi-paradigm approach, where multiple techniques like OOP and functional programming are being used within the same language. Almost all the languages take this approach nowadays and none are purely OOP, or functional, or procedural.
Object-oriented programming is the dominant paradigm, but looks like it is not driving its success, but just taking the ride along
Object-oriented programming is the dominant paradigm, but looks like it is not driving its success, but just taking the ride along
[]
["Go", "Rust", "AI", "ML", "Python", "Aim", "C++", "JavaScript", "R", "Java"]
["AI", "ML", "Aim", "Python", "R", "JavaScript", "Go", "Rust", "Java", "C++"]
Mohit writes about AI in simple, explainable, and often funny words. He's especially passionate about chatting with those building AI for Bharat, with the occasional detour into AGI.