As one of the (relatively) older people in Software Development, I've seen a good deal of the history of the profession, and one of the perennial things we are forced to live with are the holy wars over various things. We've got Editor Wars (Emacs vs vi), OS Wars (Windows vs Mac vs Unix), distro wars (Ubuntu vs Fedora vs Gentoo), and so on.
But the biggest wars are those over the programming paradigms - Declarative programming (DP), Functional programming (FP), Object-oriented programming (OO), and the others. So it's always amusing to read the various viewpoints from the various camps, and quite often I learn something useful from them.
However, not all are so valuable - this post, from a Erlang partisan, is an almost classic example of elevating personal preference to moral imperative. He (?) takes various straw men about OOP and proceeds to tear them apart, claiming that this then "proves" OOP is a bad idea.
I'm not usually prone to point-by-point rebuttals, but this one was too egregious not to try.
Objection 1 - functions and data should not be bound together
This shows a total misunderstanding of the premise of OOP. The objects exist to collect the data and behavior that modifies that data. If you have an object modeling a car, and you want to track fuel consumption for that car, where better to place that than with the car, so that any individual quirks about fuel burn rate for that specific car are contained there? An FP alternative would be to have a fuel-burn function, but that would have to be able to handle every possible fuel burn option, making it a very complex function; if only a few vehicles needed certain options, the OOP solution would keep those options close to where they are used.
Objection 2 - everything has to be an object
While not true in most OOP languages, the point is clear. However, the example he gives is for time, and he suggests using the Erlang type declarations. Now, I know very little about Erlang; in fact, I know effectively nothing about it. But this set of functions reference a conceptual time object - the real time clock of the system, and only return values from that object.
Objection 3 - OOPLs spread data type definitions all over the place
This one does have a grain of truth - you can't put everything in your OOP program in one file. However, it provides an encapulation - you don't need to know the inner workings of everything if you have a well-defined interface to those things. He also makes the spurious claim that if you need a "ubiquitious" data structure, you must inherit from that class to use it. This shows a lack of awareness of how OOP works - inheritance is only part of the mix - composition is more useful, and does not require inheritance to work. In fact, composition is part and parcel of earlier structured languages and their data structures.
Objection 4 - Objects have private state
Spoken (typed) like a true FP partisan. "State is the root of all evil", yet "in the real world, state abounds" Why then do we wish to eliminate state, if it is part of the things we wish to control? He claims that revealing all the state is good, but using monads to allow the programmer to avoid knowing about state is also good. You can't have it both ways - either there is state, and it needs to be managed, or you need to avoid it altogether. OOP allows the programmer to use state when desirable, and to hide it when convenient, much like the real world - I do not need to know all the details of state when I buy a soda from a vending machine, but it's very useful to me should I be repairing that machine.
He then wraps it all up by dismissing OOP because he sees no evidence it helped people learn faster, or made code reuse easier. Arguemnt from incredulity is hardly convincing.
OOP is not a panacea, by any means, but it is a strong tool for partitioning a problem set into disparate sections for working on it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
No comments:
Post a Comment