lies about OOP

[Adam DePrince]

On Mon, 2004-12-13 at 22:33, projecktzero wrote:
> I know this might not be the correct group to post this, but I thought
> I'd start here.
> 
> A co-worker considers himself "old school" in that he hasn't seen the
> light of OOP.(It might be because he's in love with Perl...but that's
> another story.) He thinks that OOP has more overhead and is slower than
> programs written the procedural way. I poked around google, but I don't
> know the magic words to put in to prove or disprove his assertion. Can
> anyone point me toward some resources?
> 
> We do web programming. I suspect that OO apps would behave as good as
> procedural apps, and you'd get the benefit of code reuse if you do it
> properly. Code reuse now consists of cutting and pasting followed by
> enough modification that I wonder if it was worth it to cut and paste
> in the first place.
> 
> Thanks.

Code reuse is not copying and pasting.  This truly misses what code can
be.  Code isn't, well shouldn't be, a static entity that written once
and forgotten.  It is gradually enhanced, generalized, factored,
improved, optimized, rethought, etc etc.

A Properly Written (tm) application will have each abstract concept
implemented just once; in a properly written application a single change
is propagated throughout the system.  In what you describe, a change
entails hunting the code you have pasted and changing it in a number of
locations.  Depending on the size of your program and how badly your
application begs for code reuse, you can find yourself changing your
code in hundreds of places just to change a single data structure.  

Seriously, ever put off changing an array to a linked list, a list to a
map, or some other similar change simply because you don't want to the
coding and testing?  In a proper OOP application, different parts of
your program will *ask* for some abstract task to be performed, but only
one small part will actually deal with the details of doing it.  Change
that and nothing else knows any better.

The "overhead" of OOPLs is bogus.  C++ was explicitly designed so that
each and every OO operation was as fast as or faster than faking it in
C.  Do you use structures in C with special functions to act on them? 
Then you are already using objectish methods ... only proper C++ object
methods will be no slower, but a good deal cleaner.  

Even in instances where this is the case, for instance, comparing early
smalltalk interpreters to your friendly C compiler, it is almost always
the case that the expressive power and abstraction of an OOPL allows for
the use of greater algorithmic sophistication.  So, sure, your C linked
list searches might beat my Smalltalk linked list search, but in the
same amount of programmer time I'd be able to implement something
better.  

I really don't care to prove my point, only to point out that if your
assertion that this individual does not understand OOP is true, then he
his point likely isn't coming from knowledge and experience, but fear of
the unknown.  

Now, if you said that your co-worker was old school and into functional
programming, I'd agree to disagree and point out functional programmings
weaknesses with respect to complexity and the ability to partition
knowledge.

Forget goggle.  Go to Amazon and get some texts on OOPL.  Learn C++,
Java, Python for that matter.  Practice casting problems as classes in
Python and submit them here for praise and criticism.

Lastly, Perl is an OOPl in its own right ... like Python and quite
unlike Java, it doesn't jam its OOP-ness down your throat.


Adam DePrince