OOP considered harmful (was: C. Date on UML book)

[Mapraputa Is]

I don't think I said exactly that. In fact I think you already *do* understand OOP to a reasonable extent. What I wanted to say is that you probably need to experience it to know *when, how and why it is useful*.
Ah, you are right, you did not say exactly that. I was frustrated that I cannot get a clear explanation of how exactly OOP is better than non-OOP, and "clear" meant on my own conditions.
I don't think I know anyone who would say that OOP opened their eyes about how the world works, or the like - I know quite a few who would say that a specific experience opened their eyes for OOP, though. I am not sure whether you confused those two.
I wasn't sure if it's Ok to quote what was said in a private forum ("Moderators only", in case somebody besides moderators are reading this thread )... Heck, this person didn't say anything to be ashamed of, so I guess I can quote:
"It was here in this certification Assignment that I finally saw and understood the AWE and power of the OOP Dark Side.
How it makes it so much easier than procedural coding.
My eyes have been open, can you say Hallaluhah. can you say Encapsulation, can you say Hierarchy. I knew you could. "
Both ideas - "Encapsulation" and "Hierarchy" look at least controversial to me, that's why I perhaps overreacted to "My eyes have been open".
But I would ask you to not lump all OOP proponents together - in my experience, the more experienced ones are rather pragmatic about the virtues of there favorite paradigm. I hope I am...
Ok. I think, I calmed down to the degree I can discern more than one category of OOP proponents

[Ilja Preuss]

Originally posted by Mapraputa Is:
And that is *exactly* how polymorphism works in an OO language! It's just that the language disburdens you from handling with tables directly.
Hm. "disburdens"- and how does it achieve this?

By creating, maintaining and handling the table(s) for you.

We still have to provide all needful information, right? So instead of saying things clearly and directly, we use a bunch of artificial concepts like classes, interfaces, or, worse, "polymorphism" and "inheritance"?

Well, it seems to me as if the most direct information would be "use the function at address ABD12E4". I think, abstracting away from that might be worthwhile and even more clear. Instead of using a bunch of artifical concepts like memory addresses and jump tables, we can concentrate on the things we want to *achieve*: calling methods based on object type - polymorhism.

And regarding *exactly*, I am not sure.

Well, in fact you don't have to, because you don't have to care. If someone invents a better way of handling jump tables, or even a substitute for jump tables, you could continue to work your old style without even noticing - because of the abstratness OO lanuages provide.

Java adds static type checking to the picture, but this may not be an inherent feature of OOP.

You are right - it isn't.

"just a very convenient way" - looks much worse than "goto" to me :roll:

And how does Data-Directed-Programming does look better to you?

"To be more specific, it seems to me that the object world manages to introduce far too many distracting confusions and irrelevancies into a subject that (some might argue) is complicated enough already. Surely it would be better to avoid those confusions and irrelevancies and deal with a methodology in which the only complications are ones that are intrinsic to the topic under investigation?"

Could also be a quote of an Assembler programmer about procedural programming...

What's on your wishlist, if it is not a secret?

It's not: http://makeashorterlink.com/?K134423C1
I don't limit accepting presents to birthday and Christmas, btw...

[Mapraputa Is]

Oh my..
I thought you are kidding about "nearly hundred others"...
By the way, you can safely strike out "The Sixth Sense" - I've seen it, you wont't lose anything :roll:
"Style: Ten Lessons in Clarity and Grace (6th Edition)" von Joseph M. Williams - gee, how did you find this one? I have it and it's good! However, Michael Ernest could barely tolerate this name so I figured there may be better guides out there, but I do not know what thy are
"The Psychology of Computer Programming" by Gerald M. Weinberg is

[Ilja Preuss]

Originally posted by Mapraputa Is:
[QB]Oh my..
I thought you are kidding about "nearly hundred others"...

Well, I can't remember putting a smiley next to it

By the way, you can safely strike out "The Sixth Sense" - I've seen it, you wont't lose anything :roll:

Yeah, some items are rather callow ideas I need to think about instead of real wishes...

"Style: Ten Lessons in Clarity and Grace (6th Edition)" von Joseph M. Williams - gee, how did you find this one?

Honestly, I don't remember. Best guess would be that someone on the XP mailing list recommended it...

"The Psychology of Computer Programming" by Gerald M. Weinberg is

Well, although it is on the bottom of the list, it is in fact rather on the top of my wishes...

[Mapraputa Is]

Now this is totally off-topic, but...

Originally posted by Mapraputa Is:
"Style: Ten Lessons in Clarity and Grace (6th Edition)" von Joseph M. Williams - gee, how did you find this one? I have it and it's good! However, Michael Ernest could barely tolerate this name so I figured there may be better guides out there, but I do not know what thy are

This is not true. I looked my old correspondence and Michael E. recommended William K. Zinsser "On Writing Well". On which I responded that unfortunately Zinsser's style reminds me his (Michael's) own and I prefer rational, schematic, dry, dull, dead, mechanical Williams. On which M.Ernest advised to read John Gardner's "On Writing Fiction" instead. Here I became totally confused, why should I read about writing fiction, and left the battlefield.
Williams is very good for programmers, I think. His ideas are very well organized, very clearly and logically expressed, true paradise for the congenitally table-minded.
Other two books I like are "Stunning sentences" and "Powerful paragraphs" by Bruce Ross-Larson. These consist mostly of examples of good style taken out press and we know that programmers learn "by examples", not by reading instructions/explanations. So these two books are kinda like "patterns" in writing.
As to "The Psychology of Computer Programming", when I was reading it, I was stroked that what he wrote about "capitalistic" America was so much similar to "communistic" Russia. I guess, professional issues are very orthogonal to political systems.

[Mapraputa Is]

I distracted myself with translating aufgabe last two days.
Back to the Great RM vs. jump tables (aka OOP)
It's time to clear things a little and to add more anti-OOP rant...
First, we need to separate analysis/design (building right abstractions) and programming (implementing those abstractions). "Things with responsibilities" belong to the "design" stage, I believe. When people talk about "a model that simulates real world objects", whether they are right or wrong, they think about the "design" stage really. It is advisable to do both design and programming in terms of OOP, but it is theoretically possible to decouple those two, and for certain applications certain authorities even advise to abstract design from any implementation paradigm (Coplien). Cockburn's article Frank quoted is really about design and he (Cockburn) explicitly said: "Although you may use inheritance in solving the problem, I am going to spend less time on inheritance. If you get the basic design wrong, no inheritance structure will fix it. If your basic design is strong, you can play with the inheritance structure to make it better."
I get a feeling that "things with responsibilities" do not clash with the Relational Model...
Now when we are to implement our design, we can choose between procedural/structured/unstructured/objective/subjective programming ("subject-oriented programming" is not a joke), but where does the RM fit in? My idea was that it is rather orthogonal to all kinds of programming. It is designed to solve one particular problem - data management, and as I understand not any data but those that are doomed to unpredictable changes. (This is really a large class of data, more about it later). And finally I found a proof of such a vision:
C.Date, The database relational model, p. 121: "object functionality and the relational model are completely orthogonal to one another".
"It allows the operations needed for data access to be simpler than they would otherwise have to be." P. 90
"it avoids biasing the database design in favor of certain queries at the expense of others." p.89

This last sentence nicely summarizes the main difference between the RM and OOP, I think. While the RM is all about preparing data for unforeseen queries and reorganizations, OOP is a wonderful tool when your "objects" exhibit constant nature. Both Frank's examples: web browser and text editors fit this model. Web browser deals with texts in HTML format, and if HTML's IMG tag is placed inside P tag today, it wont be the other way around tomorrow. New functionality can be added, true, but it wont break the old structure.
The same with text editors, the hierarchical nature of the text (paragraphs, sentences, words...) aren't going to change any time soon. When your domain exhibits stable hierarchical nature, OOP should work.
In all other cases "hierarchy" means "inflexibility". See the next posts...
--------------------------------------------
"What I ought to do, is go to sleep!"
Frank Carver

[Mapraputa Is]

"Object Oriented Application Frameworks"
12.2 The Dark Side of Objects
OT is being touted, just like its predecessors, as the one true path to knowledge. It is not. Even though this book has been heavy-handed in its advocacy of object-oriented programming, all is not milk and honey in the world of OT. Procedural programming does not go far enough, and neither does OOP. We should recognize that OT is simply another step toward Nirvana.
In fact, there is a dark side to OT. The first crack in OOP's foundation is the so-called fragile base class problem. When designing a class hierarchy for a framework, we are actually designing a house of cards. Each interface between a class and its subclasses is a form of coupling. In fact, inheritance is an extreme form of coupling that would make a structured programming whiz shudder with fright. Inheritance leads to a high degree of coupling within a framework. This is bad because coupling is the root cause of the ripple effect in software. If coupling is high, a small change in one place can propagate changes throughout a large part of the entire system.
In a framework, everything is connected to a few top-level base classes. What happens when the top level interface changes? Everything depends on these fragile base classes, hence the name of the problem. Changes ripple throughout the class hierarchy, leaving one's design in a shambles. Framework designers must be absolutely sure that the hierarchy will stand the test of time, and who can tell the future?
The second major weakness of framework design stems from the static structure of the class hierarchy and the monolithic nature of inheritance. Even though objects are easily created and destroyed during a program's execution, we need more flexibility in modern systems. In reality, class hierarchies cannot be static. They must be dynamic, which means that their interfaces must be created and destroyed during execution of the system; the interfaces (in addition to the objects themselves) must be dynamic. This means that the class hierarchy of a framework can be created as the system runs.
Consider the case of a real-time system constructed as a framework. This might be a small operating system or a distributed client/server application. Here is the limitation imposed by a static class hierarchy: when a new device is plugged into the running system its interface must be made known to the application framework. For example, the system may be a desktop computer and the device may be a network interface card. How does the running system recognize the new interface? Polymorphism will not work in this case, if the device interface has nothing to override
Traditional framework technology cannot handle the dynamic interface fluctuations demanded by CORBA. In fact, CORBA interoperability goes against the grain of pure OOP because it violates some of the strict encapsulation rules of OOP.

[Frank Silbermann]

I think it's clear that OOP has expanded the ability of programmers to build and use large and complex systems. For example, I shudder to imagine what Java's Swing API would look like if rewritten for Pascal or plain old C. I do agree that OOP concepts are poorly understood and explained. For example, in C++ a "class" is a meta-object; in Smalltalk a class _is_ an object (whose purpose is to serve as a factory); in PowerBuilder every _object_ is also a class.
I think we would benefit by recasting OOP into the concepts of programming language design theory that was used to describe the progression of languages from assembler to Fortran to Algol-60 to Pascal to Ada; that is, in terms of control structures, modularization techniques, and type checking.
Take type checking, for example. Assembler provides no type checking; Fortran provides it inconsistently; Algol-60 provides it, but only for atomic data. Pascal provides typechecking for structured data types, and Ada tries to provide some degree of polymorphic typing for controlled flexibility. With Java, what we're essentially getting is typechecking based on interface definitions rather than data structures, which makes sense because sometimes its rather arbitrary whether a piece of information is to be modeled as data or as procedure. (Compare Polar vs. Cartesian coordinates, for example. They are used to answer the same questions in geometry, but often the choice of coordinate system determines whether a question is implemented as a procedure or as a data look-up.) Is it not nicer for the type checker to deal with higher-level programming concepts than low-level artifacts of the von Neuman architecture?
So if we think of interfaces as fundamental to a polymorphic typechecking system, then the notion of class is _not_ a fundamental building block of OOP, but is instead the bundling of two concepts -- type definition and representation/implementation.
Now, to change the subject, some have complained about the concepts of OOP and patterns as being too difficult -- that even brilliant people have to struggle with their application. That's not a bad thing, as long as it rewards brilliance with a big payoff in productivity. Some programming techniques, such as the use of axioms in mathematical proofs of correctness, require unusual intelligence to apply yet provide little power for brilliant people to amplify their productivity. On the other hand, if the skillful use of OOP and patterns required no great intelligence, there would be no need to pay its practitioners very much. It is only when techniques both require great intelligence for their use _and_ bring a terrific payoff in productivity (taking quality into account) that brilliant programmers will be able to demand lots of money. That is a _good_ thing!