Random Precision

Coding Horror: Your Code: OOP or POO?

From the comments:

generally, people need to use module-oriented programming, but the lack of support by most mainstream language of the day makes them rely on object-oriented programming instead, calling for all possible abusements.

My own career followed an unusual trajectory. Because of where and when I got my Master’s degree, I was exposed to Ada 83; and because of where and when I worked, I had a chance to actually apply it, before I ever did any C++ programming.

Ada 83 was the first standardized version of the Ada programming language, and it was a curious beast. It’s one of the few examples of the transitional phase in software development, after language designers had learned of the value of modularity and information hiding, but before object-oriented programming set the world on fire. (The only other example that comes to mind is Modula-2, another creation of Pascal’s designer, Niklaus Wirth.)

Pascal — the language from which Ada derived its basic syntax — ruthlessly enforced the principles of structured programming, and taught a generation of comp-sci graduates (including me, class of ‘85) the value of those principles. Ada did the same with modularity and information hiding; data and subroutines were grouped into packages, interface modules controlled interaction between packages, and the visibility of package components could be finely controlled. This appealed to me, as it reinforced the ideas I’d picked up from my senior-year courses in software engineering, using the text Structured Design, by Edward Yourdon and Larry Constantine: maximize cohesion (keep closely related things within the same syntactic unit) and minimize coupling (make sure interactions between units are few in number and explicitly defined).

The idea of all this being to make maintenance easier, by allowing program components to be modified in isolation, without breaking other modules that interacted with them. Unless the modifications resulted in changes in the (narrowly and explicitly defined) interface, changes would not propagate to other modules. (Bertrand Meyer’s “design by contract” principle took this idea further still.) That was the theory, anyway; but practice actually approximated theory, if not perfectly. Modularity is one of the few ideas that everyone (now) agrees is a Good Thing.

All the tools to do modular programming are present in C; you can declare your interfaces in .h files, and keep everything else private using the ’static’ keyword. But typical C programmers of that time didn’t know that one should program that way, and the language design didn’t make it the path of least resistance. (Top-level functions have linkage unless you explicitly say otherwise; the compiler doesn’t disallow referencing declarations in .c files or defining declarations in .h files, no support for namespaces, etc.) So it wasn’t typically done that way. But knowing Ada, and knowing the rationale behind it, made me a better C programmer; my programs followed modular conventions, and strictly controlled visibility. (And when C programming is still done these days, that is the typical practice.)

All of these principles got swept up into the meme-complex known as “object oriented programming”; and since the industry transitioned from the kinda-sorta modular C to the object-oriented C++, without a fully modular language in between, people credited OOP with benefits that weren’t really intrinsic to OOP, but were intrinsic to — for want of a better buzzphrase — module-oriented programming.

OOP was oversold. You had to live through it to get an idea of how intense the hype was. The industry was convinced that non-object programming was evil; that hybrid programming, such as was allowed in C++, made baby angels cry. So one of the design criteria for languages like Java was that everything had to be an object, for better or worse. The basic usefulness of hybrid programming eventually led to the development of the Singleton design pattern and EJB session beans, and other semantic dodges that let programmers escape the ideology in order to get their job done.

As you might guess, I am not too impressed by the object-oriented everything ideology. Inheritance and dynamic binding are useful tools, but organizing your whole tool stack and API around them is a mistake. I prefer languages that allow hybrid programming (like Python, JavaScript, Perl, and C++); though I’ll allow there’s something to be said for languages like Ruby, where the object metaphor is so thoroughly baked in that you can choose to ignore it.

This is another reason I’m intrigued by the Scala programming language; while nominally as thoroughly OOP as Java, the Singleton pattern is baked in; you can just declare an Object, using the same syntax as for declaring a class. The distinction between this and a plain old Module is inconsequential.

I’m hopeful. After nearly twenty years, the industry and the profession seem to be recovering from the “object-oriented everything” mania. It’s about time. I wouldn’t want to do without classes and objects; but I’d rather have more than that hammer to work with, so that I can deal with whatever un-nail-like projects come along.

Actors that Unify Threads and Events (Lambda the Ultimate)

Threads Considered Harmful (O’Reilly Radar)

Threads Suck (Brendan Eich)

Conclusion 1: Concurrency is massively important for the future, and threads are a lousy way of addressing it.

Conclusion 2: The Languages of the Future are ECMAScript and Scala, because (among other reasons) their creators are doing concurrency right.

Open Question: What about .NET? Obviously, ECMAScript (JScript) will work there, but will Scala be rehosted to the CLR? Or is there another language that can carry the standard (static typing + type inference + shared-nothing concurrency + closures + functions as first-class objects) on that platform?

Antonio Cangiano’s blog post, Haskell Eye for the Ruby Guy, is worth reading on its own merits; and it feeds into a series of blog posts I have brewing, and which will boil over and splatter all over this blog shortly. (Metaphors are meant to be tortured.) But one of the comments, by “Procyon”, particularly caught my eye:

There are only a handful of language that define all the current paradigms. If you know them, then you know ALL computer languages, given a couple hours to pick up their syntax.

Haskell, Scheme, C, Smalltalk (or Eiffel, or Java. OO is so overrepresented you have lots of good choices.), Prolog, Erlang, and Forth. Learn those and you will have fad-proofed yourself. All the fads for at least the next 10-20 years will just be combinations of these basic language paradigms — unless something truly revolutionary happens, but we will recognize that easily if it happens.

That’s it, in a nutshell; that’s what I’m after. I want to find out the deep ideas underlying the craft of programming, and be able to ride the ebb and flow of industry trends with some grace and wisdom.

From Procyon’s list, I still need Haskell, Scheme, Prolog, and Erlang. He also lists Forth, which I’ve never used; but I spent a fair amount of time writing code to generate PostScript, which is an NP-complete stack-based language that is clearly based on Forth. If that line item is meant to represent stack-based programming, I consider it checked off.

I learned OOP by reading the first edition of Bertrand Meyer’s Object Oriented Software Construction. Thus, I learned the principles in a pure implementation of the paradigm (Eiffel), then going on to apply that knowledge in a hybrid implementation (C++, Perl, Python, Java). I’d followed that pattern once before to good effect, learning the principles of modularity and information hiding in a (ruthlessly) pure implementation of it (Ada-83) and going on to apply it in C. Having had some success in this path, it sounds as though Haskell should be my next step: it is the purest available implementation of functional programming.

Of course, I still need to finish my Java certification goals first.