Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > lies about OOP

Reply
Thread Tools

lies about OOP

 
 
projecktzero
Guest
Posts: n/a
 
      12-14-2004
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.

 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      12-14-2004
Try comp.object.

John Roth

"projecktzero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
>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.
>


 
Reply With Quote
 
 
 
 
James Stroud
Guest
Posts: n/a
 
      12-14-2004
It goes something like this (re-hashed a little):

"Every program of any complexity written in a procedural language will have a
[half-assed] implementation of object oriented design."

On Monday 13 December 2004 07:33 pm, 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.


--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
611 Charles E. Young Dr. S.
MBI 205, UCLA 951570
Los Angeles CA 90095-1570
http://www.jamesstroud.com/
 
Reply With Quote
 
Tim Daneliuk
Guest
Posts: n/a
 
      12-14-2004
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.
>


https://www.tundraware.com/Technology/Bullet/

--
----------------------------------------------------------------------------
Tim Daneliuk http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP Key: http://www.tundraware.com/PGP/
 
Reply With Quote
 
Alan Morgan
Guest
Posts: n/a
 
      12-14-2004
In article <(E-Mail Removed). com>,
projecktzero <(E-Mail Removed)> 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.


In the world of computers, the statement "X is slower than Y" is true
for almost every value of X and Y under some circumstances.

IMHO, "loves perl" doesn't mesh with either "old school" or "cares
about overhead", but that's just me.

Alan
--
Defendit numerus
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      12-14-2004
projecktzero wrote:
> 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.


The question in your first paragraph is largely answered (albeit
indirectly) by your second. You are doing web programming. It's
highly unlikely that you currently are near your limits in terms
of either "overhead" (I'll take that to mean memory usage) or
performance, and you are almost certainly limited by bandwidth.

In other words, you're I/O bound and not CPU or memory bound, so
any fuzzy concerns about the supposed sluggishness of OOP code
are seriously misplaced.

If I'm wrong, and your company has only just been surviving in
the market, solely by virtue of the incredibly quick and
lightweight code crafted by your wizardly but dated co-worker,
then I'll happily go to work disproving his ludicrous claim.

Until then, it's hardly worth the discussion... a clear case
of premature optimization, and in this case costing your
company huge benefits in lowered maintenance costs, higher
code quality, greater reuse, access to more up-to-date programmers
than your co-worker and so on.

-Peter
 
Reply With Quote
 
Jeremy Bowers
Guest
Posts: n/a
 
      12-14-2004
On Mon, 13 Dec 2004 19:33:25 -0800, projecktzero wrote:
> 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.


OO is a huge, ginormous, amazingly large, unspeakably awesome,
can't-believe-anyone-ever-lived-without-it win... but not necessarily OO
as it is presented in Software Engineering class due to the unusual nature
of web programming.

Tell him to check out HTML::Mason, and be sure to work with it long enough
to actually use some of its features. Once he's hooked (and it really is
an awesome framework; Amazon is supposed to use it and while I'm sure it
is highly customized I can definitely see it), explain to him that the
various components are really objects, complete with quite a lot of the
object features like inheritance, even if it doesn't look it.

If he resists this and declares Mason to be "crap", then with all due
respect you've got a blowhard who refuses to learn on your hands, and in a
perfect world he'd be stripped of code responsibility and moved somewhere
where he can't hurt anything. (He may merely not like it; I reserve the
strong statements in the previous sentence for the case where he actually
dismisses it with prejudice.) In the meantime, I've had great luck in Perl
environments programming in OO anyhow, as long as you have reasonably
independent responsibilities, and eventually the advantages do not go
unnoticed. Perl gets bashed on around here (in a good natured way) but
there are certainly worse languages; generally when I want to do something
the Right Way it provides a way to avoid code duplication, though it is
usually more circuitous and complex than in Python.

Ultimately, of course, the true problem isn't that you aren't coding OO,
it is the use of Copy and Paste Programming. OO is one path out, but only
one. (Perl is strong enough that one can make a case for going functional,
though I strongly prefer a functional/OO hybrid that builds on OO but
freely borrows functional paradigms at will.)

http://www.c2.com/cgi/wiki?CopyAndPasteProgramming

The problem with web programming is that you can *get away with*
"procedural" programming because the partitioning of the problem into web
pages provides a primitive, but marginally effective partitioning of the
problem into discrete components. Thus, unless you are running
*everything* through the exact same "web page" (CGI script probably in
this case), you aren't doing true procedural; the CGI scripts function as
primitive objects themselves, enough to let you get farther than you could
in a monolithic program and fool yourself into thinking you're safe, but
not strong enough to build a large-scale system with high-quality code
(i.e., low duplication).

But you still suffer.

ObPython (serious though): Which Python framework is the most Mason like?
(I'm more interested in the component infrastructure than the exact syntax
of the files; I'm not so worried about embedding Python into the HTML. I
think it might be Zope but I haven't tried enough of them to know.)
 
Reply With Quote
 
Jive
Guest
Posts: n/a
 
      12-14-2004

"projecktzero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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.


Just how old *is* his school? I saw the light in the 70's. For those of
you too young to remember, those were menacing and sinister days, when pant
legs were too wide at the bottom, and the grotesque evil of "top down
programming" was on the land. But by '86, the Joy of OOP was widely known.
Flowers bloomed and birds chirped. Pant legs narrowed. I believe that was
the year I attended the first C++ conference in Santa Fe.





 
Reply With Quote
 
Adam DePrince
Guest
Posts: n/a
 
      12-14-2004
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


 
Reply With Quote
 
Paul Robson
Guest
Posts: n/a
 
      12-14-2004
On Mon, 13 Dec 2004 19:33:25 -0800, projecktzero wrote:

> 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?


Oh, he's probably telling the truth, in that unless you have the type of
an object defined at run time then a straight procedural call is going to
be quicker, because classic "procedural" code has a very tight mapping to
the underlying hardware.

Of course, the issue is not about raw speed - which in many cases does not
matter (and the few where it does you can work around) ; it's about
maintainability, modularity and so on.

I once worked at a place (this would be mid 1980s) where the other coders
would not accept that it was "better" to use names for subroutines such as
CalculateBillingTotal or variables such as StaffName. The argument was
"well, gosub 13000 and S$ are the same thing" .... which misses the point.

If he's that obsessed speed what is he doing coding with Perl (hell I like
Perl) which is compiled to a bytecode which is then interpreted.... why
not code in 'C' or even Assembler, then it'll be really quick ? Answer ;
you like the facilities of the language. So it is a trade off.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
lies, lies, and more lies noauth Computer Support 9 03-09-2009 12:59 AM
What Lies Beneath-Feature Article in Better Software Magazine loulou384@gmail.com Java 0 05-01-2006 06:23 PM
Yahoo! Lies: You can play Capture in Linux John Bailo Java 1 11-07-2004 04:39 AM
Lies, D^mned Lies, and Cisco's WebVPN. NS Cisco 2 02-22-2004 11:51 PM
New Epson PX/PM ink technology - Print Longevity lies confirmed! David Chien Digital Photography 4 10-24-2003 11:30 PM



Advertisments