Oo Has More Dials

One of the reasons ObjectOrientedDesignIsDifficult is because ObjectOrientation has MoreDials.

This page is perhaps redundant with the page I just extracted from ObjectOrientedDesignIsDifficult: IsObjectOrientationMoreComplex. Of course, maybe this is a better name. I'm not always so good at naming things. -- francis

I intended this page to represent only one argument that AlistairCockburn presented, with the further intent of refuting only this one argument. There may be other reasons/arguments that IsObjectOrientationMoreComplex. Is that sufficient to keep this page alive? I trust your refactoring skills, do as you see fit.

Why don't we do this: Take a look at IsObjectOrientationMoreComplex, and see if that page is either broader than what you had in mind for this page, or just about the same. They seem the same to me, but there could easily be a useful distinction here that I'm not getting right now. If you want to draw a distinction between the two pages, then by all means we can do that. Or we can merge the two pages, keeping this name, or that name. I'm flexible. -- francis

[EditHint: move stuff related to this from ObjectOrientedDesignIsDifficult]

I disagreed with this argument on ObjectOrientedDesignIsDifficult, though perhaps it was misinterpreted on that page. The argument can be represented as: OoHasMoreDials, MoreDials => more difficult, therefore OO is more difficult. My counter-argument wasn't based on denying that OoHasMoreDials. Instead it was based on denying that MoreDials => more difficult. The EssentialDifficulty of design is the same (in my opinion) regardless of what language you're using. The AccidentalDifficulty arises from a mismatch between the programming language and the human brain's ability to contort itself to follow the language. MoreDials has nothing to do with it, since those dials may make human-centred programming more or less difficult.

Let's look at this analogy in aircraft. A private propellor airplane has less dials than an airliner. This is because an airliner is more powerful, has better safety features, and can haul more people. But, an airliner takes far longer to learn. Applied to OOP, this would imply that OOP is more "powerful", such as being able to write larger applications that are maintanable. If this is so, perhaps we should clear up the scope. Private planes are fine for private use such that more dials wouldn't help them much. In other words, is OOP overkill for smallish projects? And, how does this fit with procedural or RelationalWeenie claims that large applications are a smell anyhow and should be split?

The developer field is becoming like sports where people wear out, burn out, or are pushed out after about 12 years. Something that takes a decade of experience to "get right" is going to be problematic in such an environment.

{It's not that it takes a decade to "get right"; more like it takes a decade to achieve effortless skill, perspective and wisdom, i.e., mastery. That's about right, if you think of a typical programmer's career development consisting of three to four years of training (that's how long it takes to "get right" or become usefully employable, regardless of paradigm), then roughly a decade achieving mastery over the programming craft before moving into a management, senior architect, or academic role.}

WhirlLanguage has only two dials, so it should be easier to learn than OO.

From my industry observation, it appears that it takes a long time to even "get right", not merely master.

{Alas, every industry is awash in individuals who never achieve competence, or who take unduly long to come close to it. In software development, the choice of paradigm won't have the slightest effect on the habitually ineffective employee. They'd be just as marginal writing code with Lego blocks (which you can do, by the way -- see http://mindstorms.lego.com/en-us/Default.aspx) as with OO, procedural, functional, logic, whatever languages.}

[Well, dials aside, OO has a problem of being intuitive in a bad way. Too many people start applications as domain simulators. And there are quite a few design patterns one needs to grok before OO becomes useful. And, even knowing those design patterns, they can be painful to apply because typical OO languages don't offer effective abstractions for them (if there were effective abstractions, they wouldn't be 'patterns' because they'd simply be refactored and abstracted). Typical OO languages also have a difficult time with concurrency, synchronous and asynchronous IO, reentrancy, reactivity (DeprecatingTheObserverPattern), working with large data sets, and especially any combination of these. In many ways, OO makes developers jump through quite a few hoops to get useful work done. There is also much confusion between subclassing and subtyping, and so on. I would agree with the observation that OO takes a long time to "get right", even among intelligent and competent developers.]

{Load of shite. It's straightforward to "get right", especially when treated as better procedural programming instead of a distinct paradigm (which, obviously, it isn't). It goes deeply wrong when concurrency, synchronous and asynchronous I/O, reentrancy, and especially design patterns are given inappropriate priorities, or force-taught by ignorant academics instead of being learned at the side of educated practitioners. Programming doesn't just benefit from apprenticeship, it requires it. (It goes wrong when idiots are hired, too, but nothing helps that.) Only rank beginners start applications as domain simulators, and a sound apprenticeship approach wipes out such nonsense in days.}

[I have observed much easier success with alternative paradigms - ComplexEventProcessing, DataCentricPublishSubscribe?, FlowBasedProgramming, DataFlowProgramming - mostly because in these cases the language and architecture is taking care of the very difficult challenges of: managing concurrency, fetching the necessary data, maintaining caches, directing the output data at the right time, etc.. Unfortunately, most of the world seems to think there are only three paradigms: procedural, functional, and OO.]

{Sure, developers are really using ComplexEventProcessing, DataCentricPublishSubscribe?, FlowBasedProgramming, and DataFlowProgramming in production programming in any appreciable numbers. Stop spouting made-up nonsense and join the real world. You young pups who think you know everything after (at best) having seen a year or two of one narrow-viewed job would be wise to listen to your elders who have been dealing with your kind for decades. If you worked for me, I'd crush your arrogance by making you do Gantt charts all day long until you exhibited an appropriate degree of humility, and then I'd make you do debugging -- no new code -- for a year. After that, maybe you'd know something instead of thinking you know everything.}

{Then I'd fire your ass and outsource your job to Russians.}

[Wow, you seem cranky, old man. You talk a lot but all I hear is that 'young pups' don't have a monopoly on arrogance. Most of my experience with OO was on the job, in three different jobs, as a latecomer to each, for late cycle changes and maintenance - so my understanding of how OO architectures turn out in the hands of 'experienced practitioners' comes from observing several such architectures. In every case, developers were struggling with concurrency, observation, caching, and synchronous + asynchronous IO. Where they tried to avoid it, it just came back and bit them later when some other component of the application needed concurrency. My impression is that this is a common problem when combining data from multiple input sources and maintaining responsiveness - which describes a very common class of applications. Maybe an apprenticeship would have helped them, and helped me. But it seems we're short on wandering OO masters, and it seems you'd be the sort of harsh, foolish master that lashes out at his apprentices and teaches nothing. How many Russians are you paying at the moment?]

[I agree that OO as better procedural is one of the better approaches - one that, notably, deprecates a variety of traditional OO technologies (deemphasizing inheritance, for example). Indeed, simple procedural + good multi-process architecture (DCPS, CEP, RDBMS, FBP, web service, etc.) would be one of my recommendations as alternative to OO. I've seen engineers whip up and integrate useful DCPS apps in just a few hours. More importantly, I've seen engineers become comfortable and productive with the technology in just a few weeks.]

Maybe the problem is that it's too hard to know when you are doing OO wrong because there are so many different ways to do OO wrong that experience from the last wrong way is less applicable. Thus, experience takes too long to push you toward the right way.

CategoryOopDiscomfort