Object Oriented Programmer’s 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.



Russell O’Connor: contact me