Someone claimed that OOP made it easier for programmers to develop large applications from components. I have been thinking about this claim for the last several weeks. There are two parts to this claim. One is that programmers began to develop large applications more easily from components at the time OOP became popular. Two is that OOP was the what allowed ease of development.
I am not certain either claim is true. I did find it hard to believe that OOP could be responsible for improving productivity. When I think of OOP what comes to my mind is virtual method specialization/dynamic dispatch.
Dynamic dispatch is a scary programming technique.† When you call a virtual method, you never know what might happen. This makes it difficult to reason about such code, and code that is hard to reason about is hard to maintain. Dynamic dispatch has its uses, but they are relatively limited. I feel that OOP style encourages this dangerous technique, and it ends up being abused. How could a programing technique that is so dangerous be responsible for improving programmer productivity?
I discussed this question with several of my friends to get their opinion. My conclusion from this discussion is that it is OOP’s encapsulation technique that improved productivity rather than its dynamic dispatch.
Back before structured programming, in languages such as BASIC and FORTRAN all state was global and people were GOTOing anywhere and everywhere. This spaghetti code was very difficult to reason about and thus very difficult to maintain.
When structural programming became popular, programmers working in C and Pascal used local variables in procedures to limit the scope of some state. Entry and exits from procedures clarified control flow. People were not forced into the structural style, in C you can still GOTO wherever you want, but programmers were encouraged to use this style.
With structural programming, global variables were still common in software. Then OOP became popular and languages such as C++ and Object Pascal were developed. The OOP style encouraged encapsulation of these global variables and this all but eliminated global variables. People were not forced into this style, you can still access your friend’s private members, but programmers were encouraged. Also, it is possible to use encapsulation in C; however, it is difficult because the could not easily enforce private access to members.
If you allow me to speculate, I think the next programming revolution will be stateless/pure/immutable programming. In OOP, objects can hold pointers to data that someone else can change out from under you. This makes code difficult to reason about, and hence difficult to maintain. Anyone who has worked with immutable data can probably appreciate how much easier such code is to work with and maintain. By stateless/immutable programming I mean having interfaces that appear stateless, so “pure” is the best word to describe what I mean.
I don’t think typical programmers will be working in a strictly pure language such as Haskell. They will probably be working in some language that simply encourages this style of programming. However, I will stick to programming in Haskell for the time being.
(†) I should tread lightly because Haskell’s typeclass system provides dynamic dispatch. For various reasons, I find this technique is less problematic in Haskell because of how it is typically used. Firstly, most class methods are invoked when the instance is known at compile time. In such cases, there is no dynamic dispatch. Secondly, there are usually informal laws that class instances are required to satisfy. This makes it easier to reason about those truly polymorphic class method invocations. Though, the Haskell community could stand to do better in way of documenting these informal laws.