"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."
Post a Comment
Member since:
2005-07-05
While there wasn't a plethora of examples to peruse, I thought the article was great because it showed examples of Python using procedural, object-oriented, and functional styles, and was a good, albeit brief, overview of Python's flexibility.
To me, and for the type of work I do, Python has been a huge time saver and allowed me to produce results much quicker than any other language I've used (e.g. Java, C#, Perl, BASH, C, C++, and Ruby).
Member since:
2005-11-21
Member since:
2006-01-09
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
Member since:
2007-04-23
I agree with simo, that there is no obvious need to go OO. IMO, the OO paradigm is oversold and the only places where it may have a teeny bit of merit is in very large software projects, and you would want a statically-typed language (i.e., not Python) for such projects.
And even for large projects, I think that functional programming is a lot better for structuring than OO.
Member since:
2007-07-25
Personally I would like to see some changes to the Python language with regards to the OOP. First and foremost I think all member variables should be private, either by language design, or by option default. Furthermore, I think the methods should have public/private/protected keywords. THEN python would truly be perfect.