Fog Creek Software
Discussion Board




OOP is POO spelled backwards

This is not an attempt to start a flame war - I just found a link to this on webword.com and found it very interesting, and somewhat "Joelesque"... May be worth a read.

The title is "Object Oriented Programming Oversold"

http://geocities.com/tablizer/oopbad.htm

B
Tuesday, April 02, 2002

Interesting, if polemical, article (i mean, comparing oop to communism, that's just childish).

And yet, it really doesn't convince me of anything other than the fact that the author Really Doesn't Like OOP.

Arguments like "OOP doesn't map onto relational databases" really aren't very useful. I mean, I might as well say "Table-based programming doesn't map well onto object-oriented databases."

Tools are tools. They are good for some jobs, bad for others. When I was writing scientific simulation software, I had great luck with C. Writing web applications, I have much better luck with Java. YMMV with any set of tools/languages/OSs/etc.

Matt Christensen
Tuesday, April 02, 2002

Interesting article.
"If every problem is a nail, its great to have a hammer."

James Ladd
Tuesday, April 02, 2002

[Insert requisite 'right tool for the right job' comment.]

Considering my bias toward the kinds of programs I tend toward writing, what would I do *without* OOP?

Well, I would certainly use C.  It's tried and true, there have been many compiler optimizations for it, there are popular libraries that use it for real things, and the code runs fast.

So, now I want to write a program with it that requires a data structure more complicated than an array or matrix.  A linked list, perhaps.  So I make a little struct and call it listnode.  Now, I'll definitely need to do somewhat repetitive tasks on this structure to get any good use out of it.  I wouldn't want to rewrite the same for loop every time I need to traverse the list, among other things.  So I write a function that takes a pointer to my listnode struct, as well as whatever other parameters said function needs, and then every time I need to use it, I just call the function with a pointer to the "thingy" that I want it to act on. 

For the sake of argument, let's call this "thingy" by a more reasonable name.  Oh, I don't know, how about "Object"? 

So my little linked list program is moving along quite nicely, but now I'm running into problems because the names of my linked list operations are also used for some of my binary tree library's operations.  Sure, C is smart enough to figure out what function I really mean based one parameter matching, but it sure is making my code harder to follow.  As it turns out, the program I'm writing needs to use a linked list and a tree in the same algorithm, and I have all sorts of similar calls to functions named "insert" and "traverse". 

I have to take a good look at the first argument to each function to remind myself just what the heck I'm really doing.  I wish I could change the notation for this sort of function call in C.  It would be easier to see the relationship between a data structure and it's functions if I could put the structure's identifier right before the function name, and have that function assume an imaginary 'first argument' equivalent to that data structure's address. 

It would be a sort of namespace clarification, and what's really going on would be the same as the tried and true C way of doing things.

Wait a minute... I just made C++, and *gulp* Java to boot.  Sure, it's full of icky OOP, but at least I can tell at a glance how the data and operations relate.

"Ok, Patrick, nice word game.  What if I hate C too?"

How about something drastically different?  How about Perl?  Perl has scalars, hashes, and arrays as built-in data types.  You might even want to call these "thingies", or some other reasonable term.  Scalars can contain references to other variables, so they act kind of like C-style pointers.  We can go through the same thing as with C, and build complex structures.  And again we can send references to these structures to the functions that need to act on them.  And we can also fix the ugliness of these calls by changing the notation a little.

It doesn't have to be Java to be OOP, and it doesn't have to be slow or cumbersome either.  It's the natural progression of syntax for keeping our minds on the right track while we focus on what the real problems are.

Patrick Lioi
Tuesday, April 02, 2002

i actually read some of the guys ramblings.  it seems that OOP has helped me even in small projects.  just my experience.

the only case where i don't use OOP anymore is "quick & dirty scripts" that i'm using as a stop-gap before i finish the more structured OOP version.

but to each his own.  i kind of think super genius programmers might be able to code large projects without OOP-but for us regular guys, strong typing and OOness enforces structure we need.

Razib Khan
Tuesday, April 02, 2002

Dont forget that OOP is a mind set, and that there are languages to help express that mind set. OOP is not a language !!

Remember the early c-front stuff, it converted C++ code into standard C code and then compiled it.

James Ladd
Wednesday, April 03, 2002

I'm on the fence about this. Some, but not all, of the article's point agree with my experience. My code mixes object-oriented and procedural coding, since that approach seems most productive. Or, my background (1 year programming in Java after 6 in C) may be the reason.

There are three major aspects of OOP:
1)  Encapsulation
2)  Interfaces
3)  Inheritance of concrete classes.

I rarely use inheritance, for the reasons stated in the article. However, encapsulation is a valuable organizational technique, especially when you have multiple people on a project. Interfaces make my code much more clean. The article's objections to interfaces and encapsulation were rather weak.

On other hand, the constructs in the _Design Patterns_ book often seemed more complicated than procedural coding. A middle path seems best for now.

Jared Levy
Wednesday, April 03, 2002

I admit to not reading the article closely, because it reads too much into the Philosophy of OOP that I just get overloaded with disagreements.  From the article:

> However, why build in a complex organizational paradigm
> like inheritance when its real-world use is quite limited? It
> just invites misuse.

This is one case -- he argues that inheritance is bad because it implies everything fits within a hierarchy.  As if it imposes a Worldview on the programmer.

But the reality is that the programmer imposes the worldview.  We're not battered slaves to OOP; instead we use its features, which are in the end meant to improve readability and maintainability.

Why do we impose hierarchies on companies and other organizations?  Because it simply makes them easier for us to understand!  It makes up for the failings of humans.  OOP is a constraint, and it's meant to be one.  Just like limiting your use of GOTOs is a constraint.

I think articles like this are good in questioning everyone's move to OOP; programmers should have a choice of bondage.  But the article could have driven home the point better.

Jessie
Wednesday, April 03, 2002

I think this article can actually relate to Joels latest filler.


Perhaps OOP is one of those things that is still ripe for simplifying.  OOP is the SGML and somebody is yet to create the HTML.

OOP is just too complicated for some people.  I know you guys have got it, and It's just finally starting to click for me.  It has taken me 2 years to get this far.

I learnt Java easy enough, and passed the SCJP exam without really understanding the OOP mindset.  Strange thing is that you don't realise your misunderstanding until you do finally get it in a flash of inspiration.

It was reading Code Complete that did it for me.  I tried applying the techniques described, and then I'd realise - This is what OOP makes easier!

I've read Tabelizer's ideas for Table Orientated Programming I think it is a decent stab at creating something simpler but with similar advantages.

Ged Byrne
Wednesday, April 03, 2002

About the article's point that OOP doesn't map to relational databases.  It wasn't a fundamental flaw of OOP - it's just a matter of making a serious attempt to solve that problem, instead of demanding that it be handed to you the moment OOP was invented.  Take a look at Castor (http://castor.exolab.org/), which maps from java objects to relational databases, among other things.

Patrick Lioi
Wednesday, April 03, 2002

There definitely is a lost art of writing good procedural code - or even *thinking* procedurally in this world. There were two years in my professional life in which I, again and again, stumbled upon various better and worse implementations of singletons in C++. When I had the chance to ask the original designer/programmer what's the advantage of a singleton to a set of functions (all the data was hidden anyway in all cases), the replies were always along the lines of "that's the OO way of doing so", "there's no other way of doing so" and "that's the only logical way of doing so". I haven't yet met a single example that would convince me that in C++, a singleton class object is in any way better than its implementation in plain C-style code.

There's a lot of conusion between OOP, the paradigm, which can be applied at any level in any language, and specific OOP implementations. And the inherent ill-defined status of OOP doesn't make this any better.

More often than not I find that "well written" (in the common OO sense) programs are 10 times longer and inferior to non-OO or pinpoint-applied-OO programs. I've tried to point others to this difference, but this seems to be a lost war. Oh well, I'll just keep putting this to my advantage as I have done for the last few years, and produce better code in shorter time.

OOP definitely has its place; But it isn't universal and it isn't as far reaching as the industry-at-large would like us to believe. Get familiar with as many tools as possible, and use the right tool for the job.

If you find OOP the answer to everything, you probably don't grasp procedural programming, declarative programming or functional programming. If you're excited about template metaprogramming in C++, you probably don't grasp Lisp (I'm not sure I grok Lisp, but "abomination" is the word that comes to my mind thinking about C++ MP). If you think Java or C# are innovative, you should probably have a look at Python.

You wouldn't think of, say, writing a CGI script in assembly language or Fortran even though it's perfectly possible (and possibly more efficient, space and runtime wise). To a varying degree, this is true for every tool/paradigm and every problem - and OOP is NOT the right tool for EVERY problem, even if does work out OK for most.

Ori Berger
Wednesday, April 03, 2002

The main advantage to OOP for me is that it allows you to group data declarations (i.e. structs) and the functions that work on that data.

With procedural programming, you might have a group of functions called FileCreate, FileOpen, FileWrite, etc, that work on a FILE struct and take a pointer to FILE as their first parameter.

OOP allows you to declare that these functions and the FILE struct are related. In addition, you achieve that other code cannot directly use private data in FILE, and there are lots of other niceties, such as inheritance. But the main point is to group data and related functions.

Regarding a singleton object, I think it's better than a group of functions working on global data because procedural functions are tightly coupled to that global data, and a singleton object is not coupled to the global variable that holds a reference to it. Plus, you can logically group the functions as an object. In a way, it implicitly documents how the functions work together.

Frederik Slijkerman
Friday, April 05, 2002

It seems to me that the article has all the characteristics of paranoia:

(1) Circumstantial evidence is taken as proof.
(2) Research is halted at a superficial level.
(3) No alternative explanations are offered or are poorly evaluated.
(4) Emotional interpretations are expressed in lieu of facts.
(5) Keeps changing the rules.

The ultimate example is the challenge: given the any code, its easy to beat up on one aspect that was not taken into consideration. It's easy, for any A and B, to critic code written in language A compared to language B, on a feature that is advantageous to B. So what?

Pierre B.
Saturday, April 06, 2002

(* Arguments like "OOP doesn't map [well] onto relational databases" really aren't very useful.*)

Relational databases are an indispensable tool for business applications. Network databases and hierarchical databases, which are a better philosophical and structural fit to OOP, have been rejected by the market, and rightly so IMO. Thus, whatever paradigm you use for biz apps, it should fit well with relational. OO does not. They are bound to different base philosophies and different "structure shapes". More on this below.

(* We can go through the same thing as with C, and build complex structures. And again we can send references to these structures to the functions that need to act on them. And we can also fix the ugliness of these calls by changing the notation a little. *)

How about use a database instead of trying to manage complex structures via application code? I have managed to completely avoid the use of arrays and linked lists with the right tools, and never missed them. They don't scale well in complexity, and putting an OO wrapper around them does not solve this.  I also see no problem with putting algorithms or references to algorithms in tables if need be (if your tools support that). Also, LISP has been mixing data structures and algorithms a decade before OOP did it, I would note.

(* but to each his own. i kind of think super genius programmers might be able to code large projects without OOP-but for us regular guys, strong typing and OOness enforces structure we need. *)

Odd how you appear to associate OOP with strong typing. What about Smalltalk and Python programmers? Are they not "real"?  Exactly how OO allegedly helps with "larger projects" has never been clearly shown to me. I only get vague brochure-talk.

(* Don't forget that OOP is a mind set, and that there are languages to help express that mind set.*)

If that is the case, then realize each mind is different. If OOP can be shown to be objectively superior, that is fine; but please don't claim that just because it may map well to your own mind that it maps well to everybody else's also.

(* Remember the early c-front stuff, it converted C++ code into standard C code and then compiled it. *)

A misleading comparison. C is a rather primitive, ugly language IMO. Its popularity is due to machine speed and portability, not its software engineering features. How about comparing LISP to LISP++ (sarcasm). Further, OO design often does in code what should be done in or via the database. If your goal is to keep reinventing the database from scratch in your application code, which OO fans often do, then perhaps OOP is better. However, I question that goal to begin with.

(* The article's objections to interfaces and encapsulation were rather weak.*)

I don't remember outright objecting to them, other than perhaps saying that the definition of "encapsulation" is a little vague. Sometimes it means physical grouping of related things, other times a gatekeeper to the "innards", usually defined as state or data.

(* This is one case -- he argues that inheritance is bad because it implies everything fits within a hierarchy. As if it imposes a Worldview on the programmer. But the reality is that the programmer imposes the worldview. We're not battered slaves to OOP *)

I did not say that OO equals inheritance. OO fans vary widely in their use of inheritance. I am only criticizing that aspect of OO design there. I clearly state that in my article. It is not my fault that OO "gurus" cannot agree on anything.

(* Why do we impose hierarchies on companies and other organizations? Because it simply makes them easier for us to understand! It makes up for the failings of humans.*)

Well, if I happen to see "beyond" hierarchies, then why should I be tied down to their limitations? Some say that I don't "get OO", but perhaps the problem is the OO fans don't "get" sets or perhaps don't "get" relational. If my legs are not broken, why should I be sentenced to a crutch? BTW, most hierarchies in companies are not "clean" hierarchies in many cases. Ever heard of "matrix" organizations?

(* OOP is a constraint, and it's meant to be one. Just like limiting your use of GOTOs is a constraint. *)

I can personally see the value of limiting gotos, but not in forcing everything into rather global tree taxonomies.

(* About the article's point that OOP doesn't map [well] to relational databases....Take a look at Castor....which maps from java objects to relational databases, among other things. *)

OO-relational mappers tend to require that you are dumb down relational and/or your classes to get them to "match". Otherwise, they require extra effort to manage. IOW, a "translation tax".

(* OOP is NOT the right tool for EVERY problem, even if does work out OK for most. *)

That admission is a good step to a more open debate. But, OO fans cannot seem to agree on when and where to mix paradigms.

(* The main advantage to OOP for me is that it allows you to group data declarations (i.e. structs) and the functions that work on that data. *)

There are many ways to group functions and "structures" besides OOP. But my techniques tend to hide "structures" from the app developer, so it is less of an issue. Besides, why is f(x,a) worse than x.f(a)? Further, many dynamic languages allow one to put function references or even functions in "structures", giving an object-like array. Plus, I tend to use databases for persistence instead of files, so making a better file API is not going to be a very good sales technique on me.

(* It seems to me that the article has all the characteristics of paranoia:*)

To the armchair psychologist who wrote that, you did not give specific spots where my alleged mental brake-downs occur. Thus, I cannot fix any of them. I would note that many of those deficiencies are found in the OO world in my observation. OO is a black art, not a science by any stretch. Why should I be held to a higher standard than OO fans?

(* The ultimate example is the challenge: given the any code, its easy to beat up on one aspect that was not taken into consideration. *)

You are welcome to add whatever "consideration" is missing. My "challenge" is to bring in just that kind of feedback.

-The author-

Tablizer
Saturday, March 01, 2003

u al suck x 1120000000000

eaten by rice doubled thrice
Monday, May 31, 2004

*  Recent Topics

*  Fog Creek Home