Genius is taking something complex and making it simple; stupidity is taking something simple and making it complex; Enter OOP languages such as c# and Java.

Exposing a method; consuming a class; delegates, events, virtual methods, encapsalation, operator overloading, derived classes, base classes, constructors, destructors; How about kiss my ass with the terminolgy from demented digital geeks and speaking plain English to start with. I guess that would make this all too easy and boring.

OOP fails on all 3 points. OOP doesn't fail a little, it fails a lot.

Code reuse is way down on the list as being important; speed should not even be a consideration because this is more than ever processor/hardware dependent.

Within 10 years OOP will be phased out by the next big IT hype job. It will likely be all drag and drop. The best developers will be those who got their first set of Lego's at 6 months old.

editor's note: I'm not sure what you initially intended to do with that link, but as posted it ended up kind of broken. I hope my edit is suitable.

In the late 80's and early 90's, we were all very serious about being Software Engineers, and along with that came our single-minded focus on standards, rigor, process, replicability and metrification. As the Software Development Manager of a very large government enterprise, my aim was to dramatically reduce the costs of development. These costs included not just the original investment in development, but all costs associated with it over its entire working life.

With this aim in mind, we become very very efficient as developers, despite the fact that we still had a lot to learn about the science. The quality of the software we produced was very high, as demonstrated by the fact that much of it is still in use. This is especially interesting given the fact that we did not have any of the things we now regard as essential to software development, ie the Internet, or the vast array of fundamental libraries like Apache Commons or any of The Great Frameworks we have been talking about. We were still inventing all of that stuff.

So, what happened? What happened was Windows. Suddenly, our users didn't care about high speed data entry optimizations, or even reliability and usability – if it didn't look like Windows, they didn't want it. Having Windows on your PC was a status symbol – you were important. In a flash, Windows was everywhere throughout the whole organization, and you couldn't get budget approval on an industrial strength DOS/CUI application to save your soul. The market for CASE Tools and CUI 4GLs vanished, because no one cared about the costs of development any more, so long as it worked with Windows.

Of course that's an oversimplification, but all of us had to learn how to program with Windows as fast as possible, and an entire world of basic knowledge and professional best practice got left behind in the mass exodus. Still, human beings have not changed, and once again we are dealing with the problem of complexity. Back then, we solved the problem of complexity using standards, tools and methodologies specifically designed to dampen down and resolve that complexity. Today, by contrast, we are compounding complexity through unrestrained promotion of diversity, by multiplying tools, languages and frameworks, and dare I say it, by being completely uncritical of amateurism.

Diversity and choice are very good things in their place, but diversity can easily collapse into chaos, and too many choices can lead to intractable confusion and dissatisfaction. As we are now discovering.

you really need to find a more positive and constructive way to react to criticism; get over yourself.

To whom, exactly, was that directed?

Rod:

"Why does it seem like everyone thinks (s)he knows this stuff, when it's pretty clear that they all fail to grasp it?" — Because whoever does not project the appearance of knowing this stuff, gets shoved out of the company.

Good point.

How about this for snarkiness:

f(a,b,c) is not object-oriented. However, a.f(b,c) is object-oriented.

That sounds about right, if snark is where you're going.

I'd say that, in practical terms, "object oriented programming" is the inevitable perversion of what what the inventor of the term intended — perversion, because what he really intended was more like "message oriented programming", and inevitable, because this is really what we should have expected as a result of having called it object oriented rather than message oriented.

development:

Also see Why Object Oriented Programming (OOP) is not always good

Thanks. I'll give that a look.

Ed Kirwan:

Travis is, presumably, bemoaning unneccessary complexity, rather than an architecture's necssary complexity; an architecture must, afterall, entail some complexity in specifying how a program is to be structured, how quickly external events must be serviced, how data are to be persisted, how load-modules are to be deployed, etc.

Yes, I very clearly got the sense he bemoaned unnecessary complexity. It is always possible for a building to be over-architected just as a program can be over-architected. With software, though, we have far greater practical potential for that, in part because there is much more focus in the software programming world on inventing fantastic new development methodologies that actually enable this kind of sprawling complexity.

The result of all this is that we often see unnecessary complexity in software design to a degree that we don't see in building design — and that's what he was talking about.

Are you saying that architectures cause a worse separation of concerns than would be the case if they did not exist?

What I'm saying is that bad software design (i.e., software "architecture") via misapplied object oriented programming principles is making things worse.

If we side-step the possible misplaced modifier, Travis appears to be working with applications that don't do anything. I've never seen an application that doesn't do anything, that does perfectly nothing.

I took his statement to mean "Without doing anything new".

Or perhaps they were both exaggerating.

I get the impression you're either engaging in satire or over-thinking what was said in a manner similar to the way a lot of software is over-architected.

Correct me if I'm wrong, but you seem to be dividing agency into human factors and non-human factors, and particularly that human factors contribute most to software's balooning complexity.

I skipped over the step where I might have made it excruciatingly clear that the problem — as well as the solution — is in how design principles are applied, given two sets of design principles that aren't just completely wrong-headed, rather than in the design principles themselves. Furthermore, you seem to have overlooked the obvious question of whether more modularity and less complexity is always good. While it is usually good, from a starting point of the way things are typically done, there are limits beyond which one reaches at point of diminishing returns, if not actual counterproductive overapplication of what was previously a good thing.

. . . but as much as you're apparently overthinking all this, I rather suspect you're capable of realizing that yourself, and are being intentionally obtuse to try to undermine what others (myself included) have said.

Given that structured programming mitigates spaghetti code, can we infer from your statement that OOP makes structured programming less attractive than some non-OOP programming technique?

You can infer that if you want to — but I don't think that's really a reasonable inference.

Object oriented design is, in some ways, basically a form of "structured" programming. It allows one to implement separation of concerns more "easily" (for some definition of "easy") than straightforward imperative, weakly procedural design. That gives your program a greater appearance of order at first glance, though if misapplied it won't help things as much as one might think because:

1. Each of those implementations of separated concerns may contain a smaller discrete mess of spaghetti.
2. The whole collection of implementations of separated concerns may be tied together in a manner that is reminiscent of spaghetti.
3. If the concerns are separated in a manner that does not fit into a consistent, conceptual theme for the design of the system, tighter coupling and more complex inter-object relationships are unavoidable.

The spaghetti code becomes more "attractive" because one can recognize that there was a lot of effort put into designing class hierarchies and there is a rigidly specified structure to the program, but that doesn't mean it's actually conceptually clear. If it's not conceptually clear, you basically have spaghetti code again — just a different recipe for spaghetti.

I guess maybe it's actually linguine code.

I'm curious to understand whether you're implying that a causal thread runs through these three points.

I might call it more of a causal chain, if I was inclined to go this metaphorical route — but I think such a metaphor breaks down if examined too closely.

are you saying that software is getting bigger and more complicated because concerns are not separated in as meaningful a way as they could? I will presume you are suggesting causality here, that insufficient separation of concerns causes unneccessary complexity.

It is one causal factor, within the context of object oriented design, at least.

The logical link between the first and second point raises the question: are you suggesting that encapsulation itself leads to a less meaningful separation of concerns than some other programming technique?

No. I'm suggesting that people who employ encapsulating programming techniques poorly produce less meaningful separation of concerns than those who do so well — and that, as a style of encapsulating programming technique that everybody thinks (s)he understands well, the object oriented approach to programming is often abused toward that end.

Congratulations on having written an interesting article and thank you for it.

I hope you have a moment for some comment.

To begin with, you quote Travis's writing, 'My point is that the architectural complexity of these applications inhibit a person's understanding of the code.' This sounds a little like saying that the complexity of the blueprint of a building inhibits a builder's understanding of that building.

Travis is, presumably, bemoaning unneccessary complexity, rather than an architecture's necssary complexity; an architecture must, afterall, entail some complexity in specifying how a program is to be structured, how quickly external events must be serviced, how data are to be persisted, how load-modules are to be deployed, etc. If this is his point (I did not read his article), then it is a fair one, but I'm a little uncertain as to how this melds with your thrust, ' … that software is getting bigger and more complicated without actually separating concerns in as meaningful a way as it could.' Are you saying that architectures cause a worse separation of concerns than would be the case if they did not exist?

To the next line of the quote, 'Without actually doing anything, applications are becoming too complex to understand, build, and maintain.' If true, this is surely a shocker. If we side-step the possible misplaced modifier, Travis appears to be working with applications that don't do anything. I've never seen an application that doesn't do anything, that does perfectly nothing.

What might that look like? I presume it wouldn't look like anything, as if I can see it, it arguably does something: it presents itself to my senses. Applications that do nothing must be completely invisible. They don't appear in GUIs. They reveal themselves not even to task manager snapshots of our running systems. They just sit there, buisily doing nothing. Who is writing these applications?

And whoever is writing them, they seem to be doing a poor job, for these applications that do nothing are becoming too complex to understand (building and maintaining them is perhaps a lesser issue). This is an extraordinary indictment of our IT industry. We note that they are not yet too complicated to understand, they're just on their way to becoming too complicated to understand. This conjures images of genuinely concerned individiuals, fretting, sweating, somehow fully aware of the furious juggernaut of incomprehensibility thundering towards them as they produce more and more perfectly useless code, yet powerless to leap out of its way.

Assaf continues this IT-scandal exposé by revealing that research in the field of software uselessness has advanced to a point of some sophistication: some of these void-technologists are even building layers that, ' Clearly … cancel each other out.'

Or perhaps they were both exaggerating.

And this was exaggeration, then his point must be taken somewhat lightly, which is a shame as then we're not quite sure what the point was.

Chad, while not guilty of the above, you yourself perhaps have some points to defend.

You say that, ' … people are the proximate cause – people who don't know what the hell they're doing. These people accept all the marketing for OOP, which states that it'll make your code more modular and more stable and just generally better. It won't.' Correct me if I'm wrong, but you seem to be dividing agency into human factors and non-human factors, and particularly that human factors contribute most to software's balooning complexity. Yet in just the paragraph before you claim, ' … certain older development philosophies (like "the Unix philosophy") that provided significantly better modularity and significantly reduced complexity.' Doesn't this credit non-human factors (the philosophy) with success rather than the very human factor of the Unix programmers themselves?

You then proceed to assert that OOP, ' … sure does make spaghetti code a lot more attractive.'

I'm afraid I don't have a definition of what spaghetti code is, so let's take Wiki's:

Spaghetti code is a pejorative term for source code which has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled. Spaghetti code can be caused by several factors, including inexperienced programmers and a complex program which has been continuously modified over a long life cycle. Structured programming greatly decreased the incidence of spaghetti code, and is widely regarded as one of the most important advances in programming history.

Given that structured programming mitigates spaghetti code, can we infer from your statement that OOP makes structured programming less attractive than some non-OOP programming technique? Could you explain how?

Also, and again correct me if I'm wrong, allow me to tease out the overall flow of your article. You suggest that OOP's encapsulation enables large software development but this development can create such large products that the individual pieces themselves are of poor quality. You then suggest that software is getting bigger and more complicated without actually separating concerns in as meaningful a way as it could, and finally that people who don't know what the hell they're doing are the cause of this. I'm curious to understand whether you're implying that a causal thread runs through these three points.

You make your third point admirably clearly: people are the cause of software's becoming bigger and more complicated without sufficiently meaningful separation of concerns. If we could examine with the second point, are you saying that software is getting bigger and more complicated because concerns are not separated in as meaningful a way as they could? I will presume you are suggesting causality here, that insufficient separation of concerns causes unneccessary complexity.

The logical link between the first and second point raises the question: are you suggesting that encapsulation itself leads to a less meaningful separation of concerns than some other programming technique? If so, can you recommend a superior approach?

Ed Kirwan

it all depends on which class you want to put f in.

There is an idea based on table inversion (row-major vs. column-major) that I would like to convey.

The procedural switch(i){case 0:f0();break; case 1:f1();break; case 2:f2();break;}

could become the object-oriented i->f()

and somehow I don't remember, this is a table inversion. Multiple switch statements would be the other table dimension. The functions are the table members. So really

switch(i0){case 0:f00();break; case 1:f01();break; case 2:f02();break;}
switch(i1){case 0:f10();break; case 1:f11();break; case 2:f12();break;}
switch(i2){case 0:f20();break; case 1:f21();break; case 2:f22();break;}

becomes

i[I]->f[I]J

except that f[I] are all polymorphed together so they all inherit from the same parent function.