Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

The Object Oriented Hype

CmdrTaco posted more than 13 years ago | from the sure-why-not dept.

Programming 730

bedel231 sent us a fairly lengthy and detailed article discussing the hype surrounding Object Oriented Programming and tries to claim that a lot of things taken for granted are mythical. Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points. Regardless of your stance on the issue, it's worth a read.

Sorry! There are no comments related to the filter you selected.

common misconception (3)

jon_c (100593) | more than 13 years ago | (#520232)

one common misconception is that one can not do object oriented design in C, or any language that isn't approved by the OOP zealots. this is just not true, while it may be more natural to write a good object oriented design in C++, Java or Smalltalk. it can also be done in C or BASIC.

one can create objects in C by creating a structure, then passing that structure to every method that performs on that structure. a common use could be something like this.

struct window_t win;
window_init(&win)
window_draw(&win);
window_destroy(&win);

it is also possible to perform polymorphism and inheritance with function pointers and other techniques.

-Jon

PKD (1)

matt_king (19018) | more than 13 years ago | (#520484)

not related to the article per se, but i do like your sig quote ;)

Re:Another reason ... (2)

FunOne (45947) | more than 13 years ago | (#520485)

All the things you've mentioned are compiler isssues.
FunOne

Evolving interfaces (2)

Chalst (57653) | more than 13 years ago | (#520486)

The author makes two valid (but unoriginal points): firstly that
trying to do everything with inheritance is bad (every non-novice OO
programmer agrees), and secondly that you don't support for classes
and objects to get the benefits of object orientation (but you need
first-class functions and dynamic/existential/abstract types, obvious
to the LISP world for over twenty years).

Object orientation makes it easier to manage changing interfaces.
Support for object orientation makes it easier to achieve this in
programming practice. The author seems so upset about bad designs he
has encountered caused by an inflexible, deep inheretiance that he
seems blind to the fact that OO support can facilitate good design.

Re:Is taco sad...? (1)

phillipps (59111) | more than 13 years ago | (#520488)

`...perl's bastardised version of OOP; which, BTW, sucks balls.'

Well, I'm in that category. I came first to Perl 5 (having used Perl 2..4) then tried to make sense of C++. Not pretty.

Larry's done a remarkably good job of adding OO semantics to Perl. And has had one hell of a good idea: splitting bless from creation of the object. I put this on a par with Unix's split of fork and exec, which allows flexibility unknown to other OSes.

I have used Perl a lot; and of my programs about 10% have used the OO semantics. They are handy, but not worldbeaters. There is a problem set that can use OO, but it's not everything by any stretch. If there really is a set of "objects", maybe. Otherwise not.

Just my £0.02 (worth a bit more than $0.02).

Find what you look for (1)

Mall0 (252058) | more than 13 years ago | (#520490)

This "article" is biased from the getgo, and I smell a familiar stench of elitism. This "Real programmers don't use " is getting tired. The author does allow that he is not informed on enterprise level needs/development, but from my sandbox, OOD is the best thing since slice(bread). When coding for a paycheck, freeflow art usually doesn't last/can't be maintained/extended/scaled. OOD provides a great framework if you think OOP constantly.

The real benefits (4)

SpinyNorman (33776) | more than 13 years ago | (#520498)

The article is vapid since it addresses a collection of OOP myths that don't cover the real benefits, and secondly comletely ignores the practical reality that for most people the OOP/procedural choice is C/C++ choice, and that C++ has many features (such as constructors/deconstructors) that while not necessary for OOP, are huge benefits.


Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well


Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).

Some of the major benefit of OOP, and specifically C++'s objects, are:

o It is a clean module packaging mechanism that encourages cleaner interfaces between modules

o It encourages opaque data interfaces (method access vs public access) which results in less bugs

o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.

o The self-containedness of objects does make code reuse simpler and less bug prone.

etc, etc.

The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.

Are they really myths? (1)

RobinH (124750) | more than 13 years ago | (#520499)

Myth: OOP makes programming easier and faster

I agree that this is very commonly said by OO enthusiasts, but since most people don't believe this, I don't think it qualifies as a myth.

In my experience, writing up a quick program is much more easily done in straight C, and faster too. Most people realize this.

IMHO, the strengths of OO programming only arise when you are writing a code base for *other* people to use, simply because it encapsulates everything and provides an abstracted interface. For instance, when you go to design a GUI, it's much nicer to create a button instance and pass that to a form, than to call a function that puts a button on the screen, and continually have to keep track of all the details.

I think that OOP is actually *harder* because if you do it correctly, you have to think about how others see your interface. This is something that should be done even if you are writing code procedurally, but OOP forces you to do this.

I agree though, that there are other paradigms that are just as good. Anything that promotes modularity and generalization is good. OO is one way of doing this, but normal modular programming habits, peer review, and even structuring your app as separate processes or threads will also help to achieve the same results.

Re:OOP sucks! (1)

sv0f (197289) | more than 13 years ago | (#520500)

Lisp has had object-oriented facilities for at least as long as C++ has existed (e.g., Flavors). Common Lisp is an object-oriented programming language with several unique properties. As I understand it, Common Lisp was technically the first object-oriented language that fully passed ANSI standardization. Lispers think of their language as multi-paradigm (functional, procedural, object-oritented).

OO (probably) is the future. (1)

gimpimp (218741) | more than 13 years ago | (#520501)

in university at the moment, we're taught a lot about oo programming and design. in fact - this subject come's up more than any other.
it's becoming a trend, to not only to develop your programms using oo design - but more and more new languages claim to use it too.
in my opinion, the benefits of using (code reuse, easy maintenance) it will eventually make it the standard design of all programming languages in the coming years.

OOP can be good (1)

Srin Tuar (147269) | more than 13 years ago | (#520502)

Many people learn an OO programming language in order to hop onto the bandwagon. They are actually, for the most part fairly easy to learn, and pretty soon you can be defining classes, adding members, etc.

The problem is that most people dont get far past that point. The hardest part of using an object oriented programming technique is deciding how to structure your class heirarchy. Even for a trivial program, deciding how to throw up an elegant, scalable, and expandable set of classes to implement it can be a non-trivial problem.

There are countless bad coders who dont concern themselves with that aspect of the problem, and go around creating mob's of classes that work, but are not ideal for the problem domain. Pretty soon their code degrades into spaghetti worse than procedural coding styles. Also, they tend to use the good interfaces available to them in horrible ineffecient ways (doing alot more work than needed to solve the problem).

They give the whole technique a bad name, and I think wrongly so. It is possible to gain advantage from OO code, and to minimize the drawbacks, but its alot harder than some think. Many programmers fail to make the jump from procedural style to OO style without realizing it.

The fundamental problem with non-functional programming is something called side-effects. C code is rife with side effects stemming from global data, static function variables, assignment, the environment etc. Object Oriented programming is a technique for minimizing side effects, and confining them to small manageable sections of code. This is known as "encapsulation".

When used properly, changing how one part of the program works will only break things in a small part of the program (one source file usually). This can be a tremendous benefit.

OO programming techniques, combined with C or C++, give you the best combination of application efficiency, portability, and development expediancy avaiable today.

What it wont do is turn bad coders into good ones. Actually quite the opposite: it tends to turn bad coders into horrible ones.

OOPs ;) (1)

chickdigger (220393) | more than 13 years ago | (#520503)

Every useful programming project I've ever completed was done in C or TCL/TK. I've even paused to wonder how much easier or understandable my code would have been if it was C++, and I have to say honestly that it would NOT have been. If anything, it throws in too much jargon and demarcation. I'm sure Java is an improvement in OOP, but I don't use it, so I can't comment on it. The only useful application of C++ that I'm familiar with is MFC. M$ COM model is vague and ties the developer to too much proprietary M$ crap. It is too bad TCL/TK never caught on in the scripting world. It is much easier to read than Perl, has an excellent GUI toolkit, and is easily interfaced through C constructs.

Why bother... (1)

Gruneun (261463) | more than 13 years ago | (#520504)

When I drive to work I generally go one route. However, there are days when I realize that because of traffic, weather, or just for the sake of doing something different, I go a different route.

When I write code, I tend to go with OOP. I find it's easier to explain to co-workers and easier for me to visualize restructuring whole sections of code. Then there are the days that the I don't. For whatever reason, I throw OOP out the window for that particular project. For me, the methodology is defined by the project.

I look at an argument bashing one or the other and shake my head. I don't have time to fiercely defend or attack either one... I have code to write.

Re:reusability... (2)

slim (1652) | more than 13 years ago | (#520505)

Properly implemented, code re-use can pay off immediately.

I don't know very much about OO -- I learned about it at University (in Eiffel) but it never 'clicked' and I always found OO design to be something of a strain. I only mention this to demonstrate my bias :)

However, you seem to be implying that code re-use is something you only get from OO, and that just doesn't make sense to me. I really only code in C and Perl these days, and I reuse code all the time.


--

Table-Oriented + OOP (2)

theonetruekeebler (60888) | more than 13 years ago | (#520506)

The article really hyped the idea of table-oriented programming. I've seen both brilliant and horrible example of T.O.P. since I started programming. The horrible examples were, of course, the ones where the developers insisted on absolute purism in every corner of the system. This is true in just about any development environment--the difference between reality and a model of reality is that reality usually doesn't fit into models very well, because it is a inherently a superset of any model.

And I've seen at least one OOP project go down the tubes because the designers, among the smartest people I've ever met, treated data persistence as just another implementation detail--they had been seduced by the model of a computer that never fails and has unlimited memory.

But one of the most successful projects I've seen is one where an object-oriented framework provided a transportation and communications infrastructure on which table-oriented applications could be developed. OOP gave us just right level of hierarchical abstraction to make platform-specific issues irrelevant to higher layers; at those higher-layers, the mind-boggling flexibility of table-driven rule sets provided a potent way to model business processes without trying to put everything in exactly one box.

I do believe we are heading for a convergence of sorts. The tables in question are going to be XML, with Java (or pick another OO language) providing the framework in which (and with which) to parse it.

--

This is not just OOP versus Procedural (2)

Tom7 (102298) | more than 13 years ago | (#520507)

There are lots of paradigms around. You can go ahead and choose your favorite, but let's not make this an OOP versus Procedural battle.

Check out abstract, typed functional programming in a language like SML, O'Caml, or Haskell (I find it's much easier to write abstract modules in these languages than it is to do so in an OOP language). Check out logic programming in a language like Mercury or lambda-prolog. Don't forget the zillions of other genres and subgenres.

C'mon, slashdotters, it's your responsibility to ignore the marketing hype and use technology because it's superior. Do your shopping before you fall for something because everyone uses it (procedural) or because it's buzzword-compliant (OOP).

there is something to be learned! (2)

segmond (34052) | more than 13 years ago | (#520508)

i totally disagreed with this article, but i respect the guy, why? because he is not just sprouting shit, he wrote lots of materials and preseneted them from his own humble point of view! learn, learn, learn! is there anyone in slashdot, who is willing to write half as that much to prove him wrong? nah, instead the best most of you can do is flame him with 4 line comments. OOP is not a HYPE, yes it has been overhyped, it is not the cure to all as well, it is here to stay.

OOP isn't difficult, is it? (1)

KjetilK (186133) | more than 13 years ago | (#520509)

Well, I'm not really a programmer, I do some coding once in a while, and had a course or two. Anyway, this guy seems to make a big point that OOP is difficult to learn. Well, I really never had a class without OOP, I attempted some hacking before I knew OOP, but really, it isn't more difficult to learn than any other style of programming, is it? At least, I found it pretty easy.

There is a lot of sucky OOP support out there. IDL [rsinc.com] is really bad. R [r-project.org] on the other hand, has some very simple OOP support, but it is certainly very nice, and makes the job done very nicely. I haven't really gotten the hang of the Perl OOP stuff, but then, my Perl stuff isn't really sophiscated.

Re:common misconception (1)

sumengen (230420) | more than 13 years ago | (#520510)

In C, structures can have methods (functions).

Just define your functions inside the structure as function pointers.
Sure the syntax won't look as clean as C++ but who cares.

It's a good analysis (2)

scott1853 (194884) | more than 13 years ago | (#520511)

It tends to be a little too anti-oop though.

I use OOP and procedural programming because they each have benefits. It enables me to clearly envision the flow of code and make everything modular. It also enables me to manage multiple instances of the same type of object easier. However, it's possible to implement the same functionality in procedural form. And somebody familiar with coding everything as procedures can visualize the code just as easily. If you have used procedural all your life and are familiar with it, then you can perform the same tasks as somebody that is experienced in OOP.

Using procedures, you may have a separate source file for procs related to working with strings. You could also use OOP to declare a string object, and just put all the functions within the object. Note: The above is just an example, don't EVER waste time with string objects unless you are forced to.

It's really more of a personal preference than anything else. Synonymous with your wallpaper. In the end, all that really matters is whether or not the software performs its intended function.

How about OO hardware controller programming? (1)

AFCArchvile (221494) | more than 13 years ago | (#520514)

That's what I'm doing in my Electronic Design class in college. I'll be using HPVEE to have hardware controllers do stuff. Then, I'll use it for my final project to show off a piece of equipment that fulfills a set of objectives. I'm already light-years ahead of what the big hardware design corporations are doing. Take Intel, for instance. They haven't been able to release a reliable chipset for two years!

Re:Another reason ... (2)

taniwha (70410) | more than 13 years ago | (#520517)

nope - virtual method calls are a language feature, and calling lots of little subroutines is a coding style encouraged by OO devotees.

On the other hand a compiler could spend time optimizing this stuff more (maybe more inlining of those tiny calls at least).

The one thing that is a compiler issue in my posting is the poor use of the call/return paradigm (for example using a jsr to make a call, but not ret to get back means the architecture can't do a hidden [branch target predictor] stack cache to keep the pipe moving - many modern cpus, even x86s do this)

Re:Ask Slashdot: What do you masturbate into? (1)

cyberdonny (46462) | more than 13 years ago | (#520518)

  • Into the third punchhole on the Palm Beach butterfly.

And now the price question: will it become pregnant?

Re:My view (2)

Alioth (221270) | more than 13 years ago | (#520520)

I am *not* a OOP programmer. To be honest, I've never been able to understand it.

snip

And you know what? I've never understood OOP. I just don't "get it." Sure, I understand the theory, but when it comes to real work, I've never understood it.

It's like if everyone started calling the TV a "forbick". Doesn't make any sense does it? I mean, it's a TV. Why call it a forbick?

To use a language (any language) you have to grok it, and think in that language or - in the case of OO - in that kind of style. Your example of calling a TV a "forbick" is kind of right on - the French, for example, call cheese "fromage".

You'll never be a good Francophone if you have to think in English, then translate to French, and say it. You have to actually think in French. Same with computer languages. When I first learned C, I was thinking in BASIC and translating. It didn't really work very well. (BBC BASIC doesn't have pointers for one). It was not until I grokked C and started thinking in C that I got any good at the language. Although it seems natural to think in C then code in C++ because the languages are so similar, unfortunately it won't work out very well. You have to think "object oriented" instead of thinking in non-OO and translating. Once you get to that stage, you'll truly grok OO and its usefulness.

I'm currently learning Perl. I'm trying to start off thinking in Perl rather than thinking in C++ and translating. So far, it's working OK, but I'm still doing things the C way that would be better done the Perl way, so I guess I'm not truly thinking in Perl yet!

Re:My view (2)

Malc (1751) | more than 13 years ago | (#520521)

I understand where you're coming from. Everybody's minds works differently. I found structural/procedural programming reasonably straigh forward. When I switched to OO, it felt orders of magnitude more natural, and I never want to switch back. Other paradigms were much harder for me. Functional programming, such as lisp or scheme where a real nightmare... eventually I learnt how do recursion in other languages from the experience. SQL has been the hardest challenge for me... I just don't think in sets like that! That caused me a lot personal grief and stress... I think I'm a reasonable C++ programmer, but when I had to do some stuff the database, I felt incompetent. Eventually I got my mind around that too, but I'm certainly no great SQL guru (and I doubt I ever will be).

Re:common misconception (2)

aardvarkjoe (156801) | more than 13 years ago | (#520522)

Unfortunately, a large contingent of programmers claim that OO is the only way to program, and universally is easier to write/easier to read/faster to code/faster running/etc/etc/etc. You see it in the 'language wars', where you often see "Java is better than C, because the OOP support is better." Please. You should base your style of programming on the task at hand, not try to twist it into the techniques of the current fad.

There are problems where OOP is good, and problems where it's not such a good idea. If you insist on using one or the other, pick those problems that it's suited for. I admit that I have some real problems with object-oriented programming's approach to things, but I don't want to convince people to give it up. Just don't make me do it. (That's the main reason why I chose not to do CS in school.)

Re:GUI's vs GUIs (1)

emarkp (67813) | more than 13 years ago | (#520523)

Actually you need to check your grammar. An apostrophe is commonly used to denote plural for acronyms and such, hence it is perfectly correct to write "GUI's" to mean the plural of GUI. I think you need to slap yourself in the face.

OOA article (2)

bmongar (230600) | more than 13 years ago | (#520524)

Much of this article seems to be OOA, Out Of Ass. The author states many figures such as designing takes 3 times as long with no backup. There are some points but most of the apply to missused OOA&D.

Object reuse only coming after years. Well, I work for a company that is a big user of object technologies. We have our own data access, mapping, and server objects that are our bread and butter, we can go in and have an application up in little time because we don't have to write most of the functionality, just abstract the business logic.

Buy in. That is true, if not everyone buys in the programmers will be pulling their hair out, however this is true in the development contract of many methodology.

Not everything is abstractable/in a hiearchy, true but I find in most of the work I do, it is. There are cases where some of what needs to be done doesn't make pretty objects, but that is the exception

OO is dead as a silver bullet, alive otherwise. (2)

Ars-Fartsica (166957) | more than 13 years ago | (#520530)

Like any technique or technology, OO methods must ultimately be incoporated into a larger scheme of structured and generic programming (and perhaps one day, functional programming).

Ultimately, multi-paradigm languages that can absorb new techniques as they mature, like C++ and perl, will be the winners. I have yet to see a mono-paradigm language have sustained appeal over a five to seven year period.

Spaghetti code, anyone? (2)

bgalbs (237848) | more than 13 years ago | (#520531)

Ignoring the tone of the article, which had a distinctive mid-pubescent feel, the thesis is mildly interesting: can procedural methodologies be as maintainable as object-oriented ones?

Unfortunately, the thesis was quickly replaced with some teenage-esque rants that have been noted already.

What seems to have been overlooked is the advantage of OO: code maintainence. In entreprise environments, a great deal of time is spent on project maintenance. Anyone familiar with procedural programming can testify that scanning lines of undocumented and tightly written code can be a nightmare. The old ideals of syntatic efficiency at the expense of readability, while fun and good in the hacker world, don't fit into the corporate world.

OO attempts to solve this problem by introducing a methodology that makes it easier for programmers to make their code maintainable.

This is analogous to the manager that keeps all his notes in his head versus the manager that documents his job and his notes. Both can probably do a great job, but when they move on, which one do you want to replace? I'll take the latter.

All the arguments about procedural programming being faster and easier than OO are moot: it's the nature of the beast. But OO is definitely a great tool for facilitating ease of code maintainence and leveraging past effort.

I can't believe the guy that wrote that post has had any career of significant length.

Re:I tend to agree with the author.. (2)

slim (1652) | more than 13 years ago | (#520532)

I wonder how much C++ code is actually OO, though?

I've seen any number of C++ books which are effectively C books, using cout instead of printf, with an object orientation chapter tagged on as an afterthought.

I'll bet a lot of Windows programs use OO to work with the GUI (because MFC makes them) but have an underlying program structure that's procedural to the core.

I've no doubt that OO is heavily used, but you can't get comparisoms just by counting how many programs were built with a C++ compiler.
--

Re:Anonymous hack berates OOP (5)

squiggleslash (241428) | more than 13 years ago | (#520534)

Absolutely. Let's look at OOP vs Communism:

Classes: Communism - adamantly against. OOP: For, not merely for, but in favour of more classes than you could possibly imagine.

Inheretance: Communism - opposed to. Inhereted property regarded as a prop for the aristocracy. OOP: Treats the concept with a reverence not known even amongst the Kennedies and Rockafellas of this world. Encourages, aids, and supports.

Property: Communism - private property treated as an ambonination. OOP: Supports, allows objects to have whatever properties they want, and decide for themselves what is public and what is private.

Objects: Communism - usually on the side opposing the objectivation of anyone, women, minorities, etc. Even cynically, prefers to deal with people as an anonymous mass rather than discrete objects. OOP: Pro-objectification. Treats everything and everyone as objects.

I think it's pretty obvious that our OOP berater has no idea what sie's talking about. That said, most communists I know feel the need to talk in wordy jargon to demonstrate their superior intellects. With OOP programmers making sure they use everything from 'abstraction' to 'polymorphism' in every other sentence, I can see why the author might have been confused...
--

Re:common misconception (1)

fitzimac (254985) | more than 13 years ago | (#520535)

But what you described isn't OOP. An object is defined by member variables and functions. Those functions are not members of the "object" window_t.

Wrong (4)

cje (33931) | more than 13 years ago | (#520538)

I think you need to look at the definition of an "Object Oriented" language. You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those.

Of course it "supports" them. It's just not as easy as it is in other languages. As has been pointed out before, creative use of function pointers in C can be used to implement polymorphism and "dynamic binding."

Think about it a minute. What does a C++ compiler do? It translates the (high-level) C++ code to (low-level) assembly code. Are you somehow suggesting that there is no way that the generated assembly code can implement inheritance and polymorphism because no assembly language "supports any of those?" If so, how is it that C++ programs are able to compile, link, and execute? The original C++ compiler, cfront, generated C code as output from the input C++ code. Surely the output C code was no less "object-oriented" than the C++ code it was generated from.

You can write object-oriented code in nearly any language. The difference is how much language-level support for OO is provided. Just because you can't write "virual void myFunc()" in C doesn't mean you can't generate the same behavior.

digidave's rules of OOP (1)

digidave (259925) | more than 13 years ago | (#520540)

1) When it works, it works really well
2) When it doesn't work, nobody can understand what it is anymore.



-----

Re:Article is missing a lot (1)

Malc (1751) | more than 13 years ago | (#520542)

And the one code example about persons and taxes was so contrived and bogus. OO doesn't say you have to do it this way. A good programmer evaluates the situation and does things appropriately.

People and Taxes (2)

maroberts (15852) | more than 13 years ago | (#520544)

For a code example, suppose we have an application that calculates taxes for individuals. A common object oriented approach is to create a Person class and a Tax class...

Nope, I'd just add a calcTax function to the Person class I already had. Maybe this explains why my objects seem to have a lot of functions....
:-)

To take the Tax and People example you have given, you have overlooked the fact that an object oriented approach allows inheritance and lots of other stuff. For example, if there was more than one type of tax T on a person P, one could still call a generic function T.calcTax(P) for both InheritanceTax and IncomeTax classes which inherited from the basic Tax class.

Object Orientation is not an answer to Life, The Universe and Everything. And you often find that one persons idea of an object oriented approach to a problem is totally different from another persons idea. But having said that, I find that it is easier to work out what someone has done if they have used an object oriented approach than if they haven't. For one thing, most people implement all functions of each class in a single file named after a class, something you're never quite sure of with a parameter approach.

Object orientation simplifies maintainability, by encouraging people to write in a style which may be easily understood, something many other methodologies have singularly failed to address.

new logical fallacy: the communism fallacy (1)

kellan1 (23372) | more than 13 years ago | (#520548)

i've run into a trend several times lately (once in a personal conversation, once when reading about john ashcroft, and now this) that i thought had died out in mid-60s when McCarthy was made too look like such an idiot.

its called red-baiting, and its often used "this thing is like communism, and we all know how evil communism is" (or fascism, or whatever)

its dumb folks, the dumbest sort of strawman arguement in existence, and because its such a rotten example of a strawman, i think we should rename it the communism logical fallacy (or maybe just the name-calling logical fallacy)

either way, this guy is crackpot, is arguement are poor, stacked, rambling and often incoherent, and falsely didactic.

i can't begin to imagine how such a poorly written article made it to the front page of slashdot. honestly, no idea. none. really.

kellan

FUD (1)

winchester (265873) | more than 13 years ago | (#520549)

Everyone /. screams when Microsoft puts out a piece of FUD like this about Linux. This is the same thing...pure fud. The author may have some valid points, none of which he has any arguments for which support his points, but the entire piece just screams FUD.

Please remember that nothing in this world is a panacea, there are trade-offs in every decision one makes. The same counts for OO... it's no magic solution to problems the industry faces, but it is IMHO a step in the right direction.

Re:OOP is a tool, not a philosophy (1)

barjam (37372) | more than 13 years ago | (#520550)

Either one factors to the same thing. A single entry point into the program. Java does the object thing by default because there is no idea of a "global" function. But it is still just a "main" function in a class that starts the thing. I find this feature of the language VERY useful because I can put a main function in a class I am testing and run it independant of the system I am creating. Without having to make a dummy executable file to do the same thing. So basically you have to bootstrap the program somehow (into a function). Its all the same.

Re:Author is a USENET troll/pest (4)

rkent (73434) | more than 13 years ago | (#520558)

Ha! Man, he's probably trolling around here, too. I wonder what his slashdot ID is? Probably the same one who submitted the story ;)

Wow. I think /. has been seriously trolled this time.

Re:Poor criticism (2)

VirtualAdept (43699) | more than 13 years ago | (#520561)

Agreed. Frankly, I nearly stopped reading him when he mixed up OOP with poor business practices.

Beyond that, he pointed a lot of problems with the way people design OO models that aren't necessarily a design flaw with OO. For instance, his argument about the dangers of 'IS-A'. From what I've read (Design Patterns), IS-A is pretty much regarded as less extensible than has-a. When you can use a has-a, use a has-a. If you want to use a is-a, think twice about if you really need to use one. But no, an OO language does not loose a lot of its benefits as compared to procedural when you use has-a. Modules do not have state. Objects do, which is frequently important.

I think the last straw for me regarding this article was the unclever section comparing OOP to Communism. Gee, a social movement failed, therefore a programing methodology will fail too.

--John

I come not to praise Caesar.... (1)

DirtyDevo (252137) | more than 13 years ago | (#520564)

"We are not saying the OOP is bad, per se;" Hmm...interesting URL you chose then...

Re:I tend to agree with the author.. (3)

johnnyb (4816) | more than 13 years ago | (#520565)

I don't think its a fad. Structured programming is still the model we use, even when using it within object-oriented programming.

The guy who wrote the article missed one of the most important aspects of OO, and that's _interface_ inheritance. Interface inheritance is _NOT_ subtyping, and is vastly more flexible and usable than subtyping, which seemed to be one of his big gripes. If you want to know more about interface inheritance, look at my page at

http://members.wri.com/johnnyb/comppapers/factor in ginheritance.html

I called them "feature factors" here.

People think in objects (4)

Gorimek (61128) | more than 13 years ago | (#520566)

Does OO make assumptions about human nature?

Actually it does. But it's a correct one.

One of the basic assumptions is that the human brain is built to think about the world in terms of things that have properties and behaviour. We can think in terms of procedures and execution flow as well, but we're not nearly as good at it.

Who IS this guy? Don't waste your time. (1)

jageryager (189071) | more than 13 years ago | (#520568)

He seems to have a lot to say for a guy who doesn't have anything of value to say.

I got through the first few paragraphs before I stopped reading. You don't get far in this article before you start seeing stuff that doesn't look right. He says, "Myth: OOP is a proven general-purpose technique " I HAVE seen OOP proven on several projects.

Later, he writes "Fact: OO fans have repeatedly failed to demonstrate OO superiority. They can talk up a good storm, but cannot walk their talk. " OK, name one software programming technique that HAS demonstrated it's superiority. Have any? If so, let me know so I can start using it. Superiority FOR WHAT? Every application has different requirements. It like saying "truck owners have failed prove that trucks are superior."

Those 2 gems are before the article even starts.

Don't waste your time..

Re:/.-ed within 3 mins? (1)

Malc (1751) | more than 13 years ago | (#520569)

Stop your whining... I forgot to check the box that removes the +1 posting bonus. If it is too high, it'll get modded down as over-rated, or something.

Talk about flamebait... (5)

Samrobb (12731) | more than 13 years ago | (#520579)

The article is topped off with a gif image tagged "OOP Stinks!". That should give you a good insight into the level of discourse that follows.

Of course, the author absolves himself from all responsibility for having to present anything more than an emotion-filled diatribe by stating early on:

Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.

So... his article is based on debunking "OOP Myths", which he states are not "necessarily shared by all or even most OO proponents." He repeatedly fails to back up any of his points with citations or references (and at one point, actually states "Sorry, we accidentally lost the references.") Instead, he justifies his arguments by making blanket statements like "Many OO books and even some OO fans suggest that OO only shines under fairly ideal conditions." Which OO books? "Some" OO "fans"? (Remember the disclaimer - not neccesarily all or even most OO proponents...)

Finally, some of his commonly (or not-so-commonly - take a look at that disclaimer, again) believed OOP myths are outrageous to the point of being silly... OOP eliminated the need for case or switch statements? OOP makes programming more visual? Only OOP has automatic garbage collection? Components can only be built with OOP? Only Only OO databases can store large, multimedia data? Who, exactly, does believe these myths? PHBs? Certainly not anyone with a CS education or decent amount of programming experience.

The best thing I can say about this article is that I think the author has a few good points and compelling arguments that are, unfortunately, lost amid the noise and confusion of unsubstantiated facts. If you can read it through and keep from grimacing in pain as OOP is compared to communism and the lack of research in non-OOP languages is decried, you might be able to find an idea or two that will reward you for the effort.

overboard? (1)

johndoe42 (179131) | more than 13 years ago | (#520582)

First, I'm inclined to agree with the article. There are many cases of OOP that is seriously overdone. I'll use COM as an example. What was MS thinking when they made DirectX a COM object? It would be faster and easier if it was a normal API! But there are many good uses for the COM abstraction. It allows implementation reuse and dynamic binding to objects. Yes, this could also be done without COM or OOP, but it makes it more straightforward. Many of my programs use OOP for some parts and straight procedural code for other parts. Sometimes I use OOP-like structures in my program but without classes. It depends on the project.

What I don't like is the way the article is written. It lists things that it debunks, but then makes vague claims as to why they are bad. It even compares OOP to communism (!). If the article gave real-world examples, I would like it. But it simply criticizes blind faith in OOP while requiring blind faith in the article. This is not a good way to make an argument.

In the tiger compiler book (4)

f5426 (144654) | more than 13 years ago | (#520583)

the quote on top of the object oriented langages chapter was something like:

"object: to feel distate for something"

I laughed my ass off (even if I do OO programming since 1991).,

Cheers,

--fred

I tend to agree with the author.. (2)

Omega (1602) | more than 13 years ago | (#520611)

OOP (IMHO -- I'm crazy for the acronyms today), is just a fad. Like structured programming was before it.. Unfortunately a lot of these companies today fall into "trendy" programming methodologies. Personally, I believe you should program using the style you're most comfortable and familiar with. If you're trying to fit a mold it will slow you down..

Huh? (1)

Spamuel (246002) | more than 13 years ago | (#520616)

This article is a troll, right?

The biggest problem with OOP (2)

AlgUSF (238240) | more than 13 years ago | (#520619)

The biggest problem with OOP is when people use it too much, and end up with like a million classes.
Example:
class HelloWorldClass {
HelloWorld() {
printf("Hello World!!\n");
}
};



Re:fp (1)

Quid (109485) | more than 13 years ago | (#520623)

Hmmmmm. That's really deep...
----Quid

A cop-out? (3)

TDScott (260197) | more than 13 years ago | (#520629)

Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.

So... this is based on his experiences, without research? He has based this piece of writing on merely his viewpoint? Surely, if any technical critic wishes to be taken seriously, he should back his work up with proper figures and research, rather than "myths".

Communism also looked good in theory, but its base assumptions about human nature were flat wrong!

Okay... he's comparing OO with Communism? I don't see the connection. Does OO make assumptions about human nature?

This seems far too much like a rant, backed up with a few web pages... I would not take this seriously.

oop bad? (2)

holzp (87423) | more than 13 years ago | (#520645)

Yeah yeah yeah, Yeah yeah yeah, Yeah yeah yeah I think I did it again, I made you believe we're more than just objects Oh baby, It might seem like some code OOPs!... I did it again, I played with your paradigm, got lost in the code....

reusability... (2)

GoNINzo (32266) | more than 13 years ago | (#520646)

Bleh! If I hear reusability one more time, i'm going to kill someone...

The right tool for the right job. By building such a generic tool, you ruin it's effectiveness. and the article points out that the benifits of reusability only come after years.

But he makes a great point. You can't have all OOP and no procedural skills. and you see it time and time again. If all you know how to us is a hammer, pretty soon everything looks like a nail.

--
Gonzo Granzeau

My view (2)

dbarclay10 (70443) | more than 13 years ago | (#520651)

Now, I'll be honest. About four paragraphs into the article, I had to stop. I didn't understand it.

I am *not* a OOP programmer. To be honest, I've never been able to understand it. The first programming language I learned was dBase(if you can call that a programming language), and I learned that when I was around 5 or 6.

After than, I learned assembly. 16-bit, 80286-style Intel assembly.

When I was around 16, I learned Borland Turbo Pascal. I've been using computers my entire life. I'm good. Not great, but good.

And you know what? I've never understood OOP. I just don't "get it." Sure, I understand the theory, but when it comes to real work, I've never understood it.

Now, that's not to say I've never used it. I've used it, and used it well. But I never knew why they had to call it "object-oriented". It always confused me. Whenever someone started talking about OOP, I'd have to leave the room. It didn't make any sense. It's like if everyone started calling the TV a "forbick". Doesn't make any sense does it? I mean, it's a TV. Why call it a forbick?

Anyways, I'm beginning to understand a bit more. I've been playing with Python, and I think I'm starting to grasp it.

Ah well, I'm tired and babbling :)

Dave

Barclay family motto:
Aut agere aut mori.
(Either action or death.)

OOP = Communism ??? (1)

Anonymous Coward | more than 13 years ago | (#520655)

What the fuck is this guy smoking? Why is slashdot linking to some idiot's ranting on a geocities page?

Duh,the comparison is simple! (1)

Hairy_Potter (219096) | more than 13 years ago | (#520657)

Both communism and OOP rely on the concept of classes for the fundamental flavor.

Re:common misconception (3)

SpinyNorman (33776) | more than 13 years ago | (#520665)

Sure OOP is a design technique not an attribute of a language (although some make it easier than others), but your example is bogus.

A data structure is a structure, not an object.

If you add the methods to manipulate the structure (via function pointers if you're using C), then you have an object.

Is it that time of the decade again? (1)

Orgasmatron (8103) | more than 13 years ago | (#520671)

The points he lists are all technically correct, but this is hardly new. These debates have been raging for decades now.

Tell us something we don't already know... (5)

Shoeboy (16224) | more than 13 years ago | (#520674)

Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points.

Taco,
Some of us remember what slashcode [slashcode.com] looked like before pudge and friends started cleaning it up.

Not only are you opposed to OOP, but you don't seem to be terrible wild about structured programming either. Nor do you give readibility and maintainability the time of day. Your relationship with elegant code is in the "distant admiration" category and you seem to consider sobriety an impediment to productivity.

Not that I disagree with you on any of these points, I just wanted to mention that we allready know about them.
--Shoeboy

The mans a loony (1)

Vanders (110092) | more than 13 years ago | (#520679)

He compares OOP to Communism for Christs-Sake!

The guy just doesn't seem to grok OOP in any meaningful way, and seems to have some serious issues with software development practices overall.

Maybe the guy used to date a Software Manager who liked OOP?

This is bogus ... (1)

DigitalDreg (206095) | more than 13 years ago | (#520681)

OO is about defining data and operations on that data. If the definition is tight and the operations are well defined, then you have acheived OO'ness. Thus, you can do object oriented programming in BASIC, COBOL, C++, C, Java, etc.

If the guy wants to trash specific OO methodologies, then fine. However, generalizations such as linking GUI to the rise of OO program are hilarious.

Re:common misconception (2)

segmond (34052) | more than 13 years ago | (#520684)

good point, but it is hard and not natural! just like you can say that, it is like saying one can write strucuted and object oriented code in basic, ask any basic programmer, they will agree, but what use is basic if you can't use your goto etc?

Re:Huh? (1)

TulioSerpio (125657) | more than 13 years ago | (#520685)

yes it is

Re:fp (2)

S. Allen (5756) | more than 13 years ago | (#520687)

best review of this "article" to date

Poor criticism (5)

Mr Neutron (93455) | more than 13 years ago | (#520701)

The linked article seems to have more to do with the "silver bullet" mentality than OOP specifically. Anybody worth listening to will tell you that it's just as easy to screw up a OOP project as it is a procedural project. Really, has anybody used "it's object-oriented" as a selling point since 1989 or so?

In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:

The problem is that building generic abstract modules (intended for reuse in later projects) requires roughly three times the effort as a project-dedicated (regular) module. Although no references will be given here, this figure is fairly widely accepted in the industry.
Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.

Some of the things he calls out apply equally to procedural languages, such as:

When a new language fad replaces OOP, how do you convert legacy Java objects into Zamma-2008 objects?
When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?

He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.

Neutron

Taco and OOP (1)

Joe Bananas (139967) | more than 13 years ago | (#520711)

Of cource, lookin at slashcode will tell you that Taco doesn't belive in structured programming either.

GUI's vs GUIs (2)

kyz (225372) | more than 13 years ago | (#520716)

I really want to take that guy and slap him about the face, while explaining that "GUI's" means "GUI is" or "belonging to the [single] GUI". It is not the plural of "GUI". Fool!

Winded...not like an oop program (1)

bobbabemagnet (247383) | more than 13 years ago | (#520718)

I found the article a little repetitive, but he had good ideas. The point is, do we want a better program or a better programmer? Right now, the programmer costs more than the program, so it would be in the best interest of the company to take shortcuts. If using an object oriented language makes the development process shorter, at the expense of clock cycles, then management will certainly go with oop. They lose money when the programmer takes time, but not when the program does at home. Besides, you've got the cycles to spare. However, what do you use to develop the language? obviously you can't use that language. For example, the java platform can't be written in java. (I'm not sure, but I think it's written in C). The point is, OOP is great for getting a product out fast, but it's a little dirty and doesn't do the job as thoroughly as a higher level language. Either you pay the programmer extra so they can make a more efficient program, or you pay the programmer to produce. In terms of management, which makes more sense?

"I tend to agree on a lot of these points" (1)

frinkahedron (303028) | more than 13 years ago | (#520721)

Which one? The point that OOP==Communism? Taco smokes crack.

Re:common misconception (5)

0xdeadbeef (28836) | more than 13 years ago | (#520735)

It's also true that you can do good object oriened design with a Turing Machine, implemented in the Game of Life, composed of a million midgets wearing reversible parkas, which is directed from above by an Elvis impersonator in a hot air ballon shaped like a guitar.

That isn't saying it's a good a idea.
--
Bush's assertion: there ought to be limits to freedom

Re:common misconception (4)

Anonymous Coward | more than 13 years ago | (#520738)

I agree.

OO is just a handy way of structuring large systems for maintainability. It is extremely useful for what it does, but isn't magic.

People who dismiss OO out of hand are making the same mistake as zealots who insist that it must be used for everything by rejecting a useful tool.

Structured programming, functional programming, OO etc are all extremely useful given the right problem domain. The skill is being able to look at a problem and pick the correct tool for the job. Rejecting, or choosing, something automatically can be a very good way to shoot yourself in the foot.

Re:reusability... (5)

mangino (1588) | more than 13 years ago | (#520741)

It has been a long time since I last posted to Slashdot. I can normally restrain myself, but this is just pure and absolute BS.

Properly implemented, code re-use can pay off immediately. I have worked in shops where every time we added a client, we needed a new copy of the code. Even though most of the processing was the same for the new client, we had to start out with a copy of the code. Code re-use would have bought us hundreds of thousands of dollars very quickly. (This did not ocurr at my current employer)

Properly implemented abstraction and OO along with iterative design can save a large amount of money very quickly. The key is to prototype your interfaces for the application you have in mind. Once you have done that, think of a completely unrelated use of the interface and test that. If you can handle 2 or 3 different uses, you have a good interface to start with. Rinse and repeat for the rest of your system.

People may question you immediately, however the minute somebody decides to change the system message transport from http to JMS, you should be able to convince them of the value of proper abstraction and code reuse, just change the transport class and you are done. I did this in a system where we did all of the work necessary to change the transport in less than 30 minutes. The consultant that had been working on the same problem for 3 months was absolutely amazed at quickly I made the change.

OOP is not a cure all, however its use along with proper abstraction can lead to large savings from code-reuse in a short time.

Mike
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com

Article is missing a lot (1)

Maryck (84) | more than 13 years ago | (#520744)

I am a java programmer, so obviously I'm a bit biased towards OO techniques; even so, I do recognize that OOD does have its failings and agree with several of the author's points. My major gripe with his article is that it seems to be one big rant against OO with very little in the way of decent alternatives. He lists all of these problems with OO, but never really says how similar tasks would be accomplished in a non-OO language except for some very trivial cases. Even when he talks about C, he is critical; so my question is, what techniques/languages does he suggest we use? VB? Pascal?

Unless he can answer that question, I don't think he has made a decent point for abandoning OOD.

Another reason ... (4)

taniwha (70410) | more than 13 years ago | (#520745)

(for the record I first wrote smalltalk code in the 70's, I regularly code in C++ ...)

I'm a sometimes chip designer, sometimes programmer ... a while back while working on an unnamed CPU project I did some low level performance analysis on a number of well known programs (maybe even the browser you're using now) basicly we were taking very long instruction/data traces and then modelling them against various potential CPU pipeline/tlb/cache architectures - we were looking for things that would help guide us to a better architecture for our CPU.

I found that quite early on I could figure out which language something was coded in from the cooked numbers pretty easily - OO (ie C++) coded stuff always had a really sucky CPI (clocks per instruction - a measure of architectural efficiency that includes pipe breaks, stalls and cache misses) - I spent some time looking at this (since it seemed that C++ code would probably become more common in our CPU's lifetime) - basicly C++ code sucked because it took more icache hits (because the coding style encourages lots of subroutine calls which tend to spread over the cache more filling the I$ quickly) and it took more pipe breaks (also due to the subrotine calls and returns - it turned out that some code generators did stuff that broke CPU's return stack caches causing many more mispredicts) and finally virtual method dispatches (basicly load a pointer, save the pc on the stack and jump to the new pointer) tended to cause double pipe stalls that couldn't be predicted well at all even though these weren't done much they were a real killer (if you've one a bit of modern CPU architecture you learn that with long pipes you live or die on your branch predictor's hit rate - these were very bad news)

In short C++ and more genrally OO result in code and coding styles that tend to make code that makes modern CPU's run less efficiently.

Anyway - you often hear about 'efficiency of programmers' etc etc for OO - I thought I'd add a data point from the other end of the spectrum.

What are you talking about? (1)

bobbabemagnet (247383) | more than 13 years ago | (#520749)

It's a geocities site. They can handle boatloads of traffic.

Re:I tend to agree with the author.. (1)

ProtonMotiveForce (267027) | more than 13 years ago | (#520751)

What a trenchent analysis. "It's a fad."

It's not a fad, it's been around for decades, it's been used to develop countless professional grade applications.

I have a suspicion this article was written by TopMind (a semi-kook who posts to comp.object). He's not without his points, and OO isn't perfect in every situation, but this article was just plain silly.

"It's a fad." Yeah. Sure.

No Magic Bullet. (3)

maddboyy (32850) | more than 13 years ago | (#520766)

This article can be applied to any kind of programming paradigm. Basically, the author concludes that OOP isn't any good because some developers and managers aren't applying it correctly. Well, that's the case for procedural programming, declaritive, functional, etc. Yes, OOP will not solve the problem of rushed projects, poor management, or stupid programmers; neither will any other programming style though.

Programmers just need to be familiar with multiple programming practices and languages. Programmers need to know when just hammering out some _properly_ planned procedural code will fit the case better than some _properly_ planned OO code. There is no magic bullet and because of this, I think it's a bit pointless to say that one programming style is leaps and bounds better or worse than another.

I really wish the author had the confidence in the claims to actually site some hard facts and not some made up claims. Most of the article just seems like old rehashed FUD from the dawn of the OOP movement. The author mentions all of these failed business apps and blaims OOP for their problems. I guess IBM, Oracle, NASA, and some of the other big software shops are a bunch of idiots for doing any OOP. But of course this guy must be an expert on software design practices and that's why he has a Bell Labs URL.

Not Objective (1)

Maurice (114520) | more than 13 years ago | (#520770)

I just had to look at the name of the article html file to know that this guy is just ranting. It's called "oopbad.html"

OOPs! (1)

z33d (225023) | more than 13 years ago | (#520775)

object oriented programming is gay!

Re:I tend to agree with the author.. (2)

squiggleslash (241428) | more than 13 years ago | (#520801)

Aw now come on! This "Fad" has lasted at least ten years. I remember in the late eighties magazine article after magazine article about how OO was about to change the face of programming as we know it, Zortech's C++ compiler and the massive uproar that followed.

I agree it's overrated, and used predominantly because it's trendy not because the people proposing its use necessarily have made considered decisions, but a fad? I think we commonly agree now that the Internet is not a fad, just how long does a form of programming have to be mainstream before it, too, is no longer treated as one?
--

my own 2 cents (2)

segmond (34052) | more than 13 years ago | (#520805)

I am not a huge OOP fan, but I firmly do not believe it is hype, yes, it has been OVER HYPED, but when you take the hype out, it is still worth it. OOP is not the solution to everything.

I was weaned on C and assembly. I learned to write structure code, C and assembly fits fine perfectly, I can sit down and hack C freely without thinking of the problem ahead. Doing so with OOP approach is next to impossible, OOP makes you work, I hate it most of the time, and that is the reason why most people hate OOP, if you have the hacker mentality, you will hate OOP approach.

But, even with the hacker mentaility, OOP can still be good, anyone here who has done GUI programing with C, C++, Python or Java knows that language that totally dominates is the languages with support for OOP not C. If you have done programming with CORBA, you will appreciate OOP just as well. Look at Orbix for example, the fastest CORBA ORB that I know, the dirtiest to hack for, look at other ORBs supporting C++, not the fastest in terms of execution speed, but much much painless to code for.

Some people might want to argue about speed, but in this age we live, it is no longer about the speed of execution, but of development, at least in my case.

It all depends on how you view OOP (2)

garoush (111257) | more than 13 years ago | (#520806)

If you take OOP as a "silver bullet" solution for your development problems, than yes, you have fooled yourself. What a lot of people missed out about OOP is the fact that OOP does nothing but "unifies" common programming practices and provides a common "language" and communication gateway for developers to use when they are working on their projects.

Without OOP, we could all be talking about MVC (Model/View/Controller), call-backs, iterates, etc. in a completely different language and yet not understand each other which result into communication breakdown.

For those who are not familiar with OOP my suggestion is to read the "Design Patterns" book. The book doesn't talk about anything new or revolutionary. On the contrary, all the stuff in the book (and most other OOP books) are things that were covered over 30+ years ago. All what the book does is "unifies" those practices so that the next time when two developers are working on a call-back design, they don't just give it their own invented "cool" name or "cool" implementation.

Folks, OOP is no different than what you would find when you talk to an electrician (or any other well establish engineering field). In those fields there are "standard" language, process, and practices that get carried out and communicated. It is time for the software filed to standardize too.

Finally, regarding the payback of using OOP that the article pointes out -- there are countless research and study that show that on medium to large projects, OOP is the way to go.

Is this TopMind from comp.object? (1)

ProtonMotiveForce (267027) | more than 13 years ago | (#520812)

This looks like his drivel. OO isn't perfect, but this pathetic bit of sophistry and oversimplification looks very familiar.

OO Design Techniques - OpenSource and more... (2)

Rotten (8785) | more than 13 years ago | (#520815)

OOP is always what comes after an OO Design.
Yes, OO Design is far superior than other Design techniques, but sometimes is also harder. Why? Because you have to give your designers the WHOLE PICTURE since the BEGGINING OF THE PROJECT.
The Designer comes to play a key role here.
In my poor experience (counted in years, not decades ;)...non OO Design Techniques actually gave shorter design times, but when the design team was gone (working in the next project) coders have to start to work out ugly hacks in order to make the system work like the customer wanted.
Whit OO Design, you can present your customer a nice graphical interpretation of the system behavior BEFORE EVEN IMPLEMENTING A LINE OF CODE. And yes, my mom can understand those UML diagrams...it's easy.

At the implementation level, OOP and NON-OOP are good in their own category. But wait! A programming languaje is as good as the programmer using it.
I've seen nasty things using OOP and real good things using plain old C.

So, to this point, we can see that OOP is very design dependant.
The rehusability grail is very design dependient. I can make a "CAR" class, or I can make a "VEHICLE" class. That's up to the designer. But when the same group of programmers/designers/software engineers have to write a "BUS" class, because the "CAR" is quite different...well, REUSABILITY my ass. Stop everything and start over again. (up to some level, the CAR experience will be usefull, but not transparently and automagically reusable).

So, I won't blame OOP, I tend to blame OO Designers. And yes, I think that most commercial projects (small to medium) don't get benefits in using the OO combo.

OO Techniques (Design and Coding) could be a big benefit to the OpenSource Community.
I remember www.theClassRoom.org, nice idea.
Collect classes from opensource projects and present them to the Community for reusing.

Have you ever seen a image bank? Well, I think of many good uses for a class bank.
Search, read license, copy, paste, use, extend, submit to the community. The real Open Source spirit.

Suspect rhetoric (2)

hyacinthus (225989) | more than 13 years ago | (#520817)

I happen mostly to agree with the thesis of this article, that OOP has been applied indiscriminately as a programmer's panacea. The head of development at my previous job was a tremendous proponent of OOP, and he urged us all to read DESIGN PATTERNS and write up detailed class hierarchies. If there were any savings in effort and reduction in complexity, I didn't see them; instead, I saw a proliferation of classes and a disposition to spend more time drawing up nice-looking diagrams than in grappling with real problems.

But I don't care for some of the rhetorical tricks this article uses. Graphs without units or cited source, e.g. the "productivity comparison" which laughably charts "results" versus "time" for OOP technique and the highly specific category of "other". The bandying-about of general claims, with the excuse, "Sorry, we lost the references." The scarcity of citation throughout the document (and _no_, a URL link to another website does not count as another citation; I'm talking about citation from _real_ sources with good credentials.) Belabored, if not ludicrous, analogies (OOP and communism??) And of course, the obligatory venom towards academia.

One day, I hope, "computer science" will not be an oxymoron. But mostly I see stuff like this article--intelligent to a degree, propounding arguments which merit some consideration, but in the end, just as much a "religious" document as the OOP texts the author disparages.

hyacinthus.

Where OO is good. (2)

rkent (73434) | more than 13 years ago | (#520819)

First of all, I laughed out loud when the article pointed out the futility of a lot of OO "training" programs, like modeling heirarchies of shapes ("SQUARE is a subclass of RECTANGLE..."). I mean, how often have you ever needed to CODE that?! So, good point there.

But, that does kind of relate to the domain where OO is maybe best: GUI programming. This is a point acknowledged in the article, so I won't try to use it as a counterargument. Overall, that page does a pretty good job of claiming that OOP is overhyped, and not perfect for every situation. The author's not saying it sux0rs.

However, I think there is one important domain that was missed: database interaction. The author makes the point that a lot of seemingly OOP-related problems, like employee types, etc, are maintained by accountants in database relations, and not by coders in their programs. BUT, there are some great frameworks for interacting with database rows & relations as Objects! Here I'm mostly thinking of Apple's EnterpriseObjects, but please enlighten me about your favorite one.

In my experience, using code-level Objects to access database rows instead of raw SQL can be a helluva timesaver in many situations. And, to free engineers from controlling the data schema, EO even comes with a data modelor that can automatically generate Obj-C or Java classes to manipulate your database data.

IMHO, than rocks. I've written server scripts with raw SQL statements, and trust me, this is much easier. Even if we don't reuse it for 30 years. The main problem I see is that EnterpriseObjects in particular has like 6 billion layers of abstraction, so the performance is never quite what you'd like. It seems like there'd be some kind of compromise, though.

Author is a USENET troll/pest (5)

h_jurvanen (161929) | more than 13 years ago | (#520839)

For a long time now USENET groups like comp.object have been tormented by the author of that article with his constant barrage of FUD and inability to construct meaningful arguments. For an idea of what I'm talking about, check out his posting history [deja.com] .

Herbie J.

geocities... (1)

TWX_the_Linux_Zealot (227666) | more than 13 years ago | (#520842)

It's on a geocities server... expect it to be slow; at least, geocities sites generally seem to be slow as far as I can tell...

"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."

Re:common misconception (1)

tssm0n0 (200200) | more than 13 years ago | (#520845)

one common misconception is that one can not do object oriented design in C

That's not a misconception at all. I think you need to look at the definition of an "Object Oriented" language. You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those. You can't do things derive a new type of struct from another type of struct.
These few requirements created by the "approved by the OOP zealots" make OO programming into OO programming... you can write code in a non OO language that looks a little like OO code, but its not gonna behave the same way.


Ok, the spelling may suck, but the message is there...

Code Reuse (1)

destrago (120003) | more than 13 years ago | (#520848)

I've done quite a bit of C++ programing and never once in my life have I reused code through inheritance - it's actually more cumbersome to do it that way.

Polymorphism (3)

slamb (119285) | more than 13 years ago | (#520849)

The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.

That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.

That allows me to have the same easy IO operations on top of many different kinds of streams:

  • OSStream - what the operating system considers a stream. Can attach to a given fd, etc.
  • FileStream - derived from OSStream, adds the ability to open a named object. (kind of a misnomer, could be a FIFO or whatever.)
  • StreamSocket - also derived from OSStream, blends with a lot of socket functionality.
  • PGLargeObjectStream - a PostgreSQL BLOB (binary large object). Basically, like a file but stored in a PostgreSQL database instead of using an inode. Handy because filesystems have limited number of inodes, not good for lots and lots of small files.
  • SSLStream - a SSL connection, requires another open Stream (probably a StreamSocket) to connect.

Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.

This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.

This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.

Re:common misconception (1)

Malc (1751) | more than 13 years ago | (#520850)

I call that object-based programming, not object-oriented.

OOP is a tool, not a philosophy (1)

Have Blue (616) | more than 13 years ago | (#520873)

I have encountered many places where OOP is placed as the main priority for any programming task. Make it object-oriented and all problems become easy etc etc etc.

OOP is a tool, like any other language feature. If the problem you are trying to solve could be easily done with a collection of interacting, self-contained objects, go for it. If not, use something else.

For example [entering the flamebait zone], I have never seen the point of making the entire app a class. Can someone explain to me how this is better than a simple main function?

Re:Huh? (1)

Malc (1751) | more than 13 years ago | (#520877)

It read like trolling rant. Perhaps written by somebody who's been doing it one all their life, and now finds that they can't or aren't willing to adapt.

Re:reusability... (1)

TulioSerpio (125657) | more than 13 years ago | (#520879)

I always dream of a Programing enviroment that let me program in all paradigms/lenguages.

image program functions in haskel, calling from samlltalk or C++ or Java or Delphi or whatever conbination.

All in the same Compiler-debugger.

Re:reusability... (1)

Chokolad (35911) | more than 13 years ago | (#520880)

> But he makes a great point. You can't have all OOP and no procedural skills. and you see it time and time again. If all you know how to us is a hammer, pretty soon everything looks like a nail.

Huh ? What is object in most OOP languages ? It is data AND methods. If you don't have procedural skills - how can you code methods?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?