Linked by Amjith Ramanujam on Wed 13th Aug 2008 16:47 UTC, submitted by BlueVoodoo
General Development "Often it is difficult to make the transition from procedural scripting to object-oriented programming. This article explores how to reuse knowledge from PHP, Bash, or Python scripting to transition to object-oriented programming in Python. The article also briefly touches on the appropriate use of functional programming."
Thread beginning with comment 326869
To read all comments associated with this story, please click here.
oo-overuse
by simo on Thu 14th Aug 2008 08:08 UTC
simo
Member since:
2006-01-09

so twice the lines of code and no extra functionality other than it uses the buzzwords "generators" and "oop".

useful.

Reply Score: 2

RE: oo-overuse
by deathshadow on Thu 14th Aug 2008 13:06 in reply to "oo-overuse"
deathshadow Member since:
2005-07-12

As a long time fan of object oriented programming, having done the whole 'object' thing a decade and a half ago in Modula and Smalltalk - and who has spent three decades in the computer field starting out hand coding ASM...

This comment is SPOT ON - because it's become 'fashionable' to throw objects at EVERYTHING, even when it makes little or no sense to do so.

Objects are great in COMPILED languages when the datasets are complex enough where 'self handling' makes less use of memory and allows similar datasets to be processed. If you've ever made your own binary tree code, you know how much objects simplify that sort of thing.

They make little or no sense in INTERPRETED languages like php or python, where the extra code does NOT get compiled down, the overhead of extra variables, allocating and de-allocating heap space drags it to a crawl, and in general it overcomplicates the code.

I mean look at the object code for that - you now have a class to parse, two function calls (init and the actual function) instead of one, 3 self variable references, two extra variable assignments, one inside - much less the time taken to assign the class on the heap... Slow flat bloated rubbish.

Compare - orignal Python disk-monitoring example:

Functions: 1
Function Calls: 1
Variable assignments outside loop: 2

The 'object oriented' version:

Functions: 2
Function Calls: 2
Variable assignments outside loop: 6

Seems like programmers have forgotten the simple lesson that the less code you use, the less there is to break. Function calls are inherently slow - assigning new variables in an interpreted language is inherently slow, and objects are even slower.

A GREAT example of this is some Javascript I'm working on right now - I'm creating a new semantic markup skin for SMF (Simple Machines forums) because the code of the default skin is... dated to say the least. Their 'new' code for SMF 2.0 uses this stupid 3.4k javascripted object MESS just to handle the 'upshrink' header - twice the size of what they had previously and easily six times what's needed to do the job. (set a cookie, change a class) - and the stupid thing STILL requires you to manually trap onclick.

My rewrite uses two functions to their six, uses three local variables and a dozen or so DOM references to their endless horde of DOM attached variable calls - they've got almost as many variable references as they do lines of code! While it ends up being 1.1k, half of that is designed so that it parses the document classes looking for the 'control' elements to attach the 'onclick' method without having to put it in the markup.

Part of the issue is because they seem to be using AJAX to store the value also in the clients session database, which makes the damned thing slow as molassas to boot. Cookies are ok, you can use them to store a state variable on a forum... AJAX, it's becoming the new frameset - and no that's not a compliment.

People are throwing objects at problems where it's just not appropriate, resulting in fat bloated slow crap code that makes VB look lean.

A lot of this seems to stem from the obsession with recycling code - no matter how fat, bloated or slow the end result is, or how much more work it ends up being in the long term shoe-horning the wrong code into doing what you want instead of starting over from scratch...

Because a lot of times the best option is to throw it all out and start over.

Edited 2008-08-14 13:08 UTC

Reply Parent Score: 6