OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd. In a typical working day I probably use a half dozen languages - C, C++, Java, Python, Awk, Shell - and many more little languages you don't usually even think of as languages - regular expressions, Makefiles, shell wildcards, arithmetic, logic, statistics, calculus - the list goes on.
Unix programmers divide all programming into three parts -- policy, mechanism, and glue. Mechanism is code that tells how to do things, policy is code that tells what to do -- and glue is the stuff that binds policy and mechanism together. The punch line: glue is evil and must be destroyed, or at least minimized. Your typical huge honkin' C++ application with classes stacked twelve deep is an un-maintainable mess because the top two layers are policy, the bottom two are mechanism, and the middle eight are glue. And the trouble with glue is that it's opaque -- it impedes your ability to see clear down through the system from the top, or clear up from the bottom. You can't debug what you can't see through, because you can't form an adequate mental model of its behavior. This is very closely matched by the separation of mechanism, policy and glue. "Mechanism" is roughly equivalent to the data "model", "policy" is roughly equiva...
Comments