Please login or register.

Login with username, password and session length
Advanced search  

News:

You need/want an older version of sNews ? Download an older/unsupported version here.

Author Topic: Larry Ullman... on OOP vs Procedural Programming:  (Read 9404 times)

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6020
  • Semantically Challenged
    • snews.ca
Larry Ullman... on OOP vs Procedural Programming:
« on: February 19, 2008, 05:28:48 pm »

Larry Ullman is the author PHP and MySQL for Dynamic Websites (Peachpit Press) and several other credible publications. I've subscribed to Larry's e-mail newsletter for some time now and find his insight on various topics to be quite good reading.

The following is Larry's take on the use of OOP - Object oriented programming - vs procedural programming, shared here with anyone interested in reading it.  :)

Object oriented programming (OOP) is a great mystery to those that aren't familiar with it. In procedural programming (which predates OOP), you create variables, functions, and statements. When the code is executed, it goes line by line in order. If a function is called, its code is executed, then the flow is returned to continue after that call. OOP is an entirely different kettle of fish. In simplest terms, variables and functions are wrapped inside of a "class". In your code, you then create an instance of a class, which is called an object. Then all of the work is done through the object. (This is an oversimplication; classes can be used without objects and there's much more to it but...) Some programming languages like Java, JavaScript, and Ruby always use objects, whether you know it or not (in JavaScript, when you create a function, it's secretly defined as part of a hidden global object; in Ruby, everything is an object, even the number 2!). Other programming languages, like PHP and C++, allow you to program using either procedural or OOP style or a combination of the two.

If you're using a language that supports both procedural or objective programming, which route you go depends upon many things. One consideration is your work environment: If you work on a team, where different people might be playing different roles on the same project, OOP makes a lot of sense. Or if you find yourself frequently doing similar types of projects with repeatable elements, OOP would again be a good candidate. But there's really no hard and fast rule as to when you'd use OOP or procedural programming. The truth is that anything that can be done procedurally can be done using objects and vice versa.

In terms of strengths and weaknesses, you'd have to perform benchmarks to verify this, but I would generally say that procedural code is faster to execute and requires less memory, as there's less overhead. OOP offers code that's easier to use and maintain, and can be less prone to bugs (because certain protections are in place). That being said, all of these assessments are up to debate, by the way; you'll get many different opinions on this topic.
I suspect what it really comes down to is that hard-nosed OOPers think that OOP is the only way to go and those that don't really know OOP think "what's the big deal?"

I would say that even though OOP is tougher to learn and much harder to master than procedural coding, it's worth your time to play with some. The nice thing is that a little bit of knowledge is all it takes to use the hard OOP work that other people make available (like PHP's PEAR and PECL). If you do decide to use OOP, there are two things I'd caution against doing. Frequently I'll see people try to define their own classes that do something for which there's already a really good option (or several). Interacting with databases is a common example here. I understand if you're trying to learn OOP, you practice, but if the goal is to use a really good X widget in a program or script, that goal will often be best accomplished by using other people's established work rather than trying to create your own from scratch (it's kind of like deciding you'd like a good car, so you'll build one from scratch yourself). The second thing that's common, particularly with beginners, is philosophically-terrible OOP:
not understanding or implementing the full purpose and mentality behind OOP. I did some work for a guy (this was a PHP project that he, a PHP developer himself, outsourced to me) and he was really big on OOP. Or so he thought. But he had no sense of what OOP was, really just throwing all his functions, no matter how unrelated, within one class. This may not mean anything to you if you don't know OOP, but it's equivalent to painting stripes on a horse and calling it a zebra (I'm a man of a thousand metaphors). Bottom line: If you're going to use OOP, use it right. If you don't want to use OOP, or just aren't doing so right now, don't sweat it.
« Last Edit: February 19, 2008, 05:36:15 pm by Keyrocks »
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

centered

  • Guest
Re: Larry Ullman... on OOP vs Procedural Programming:
« Reply #1 on: February 22, 2008, 01:02:42 pm »

Good article.  Makes me back away from the OOP bandwagon a bit more after reading this.
Logged

lessismore

  • Jr. Member
  • **
  • Karma: 0
  • Posts: 67
Re: Larry Ullman... on OOP vs Procedural Programming:
« Reply #2 on: February 23, 2008, 09:33:11 am »

Thanks for the article.

Consider coding for hardware design, such as HDL for ASICs, where tons of stuff happens at the same time (ie, input pin levels changing state simultaneously). Think of this as trying to code a PHP web page where a user could hit every link or button on the page at the same time - how would you code that in a sequential language?

In cases where the job is concurrent, non-procedural code is required.

If cases where the job is sequential, why use a tool for non-procedural code with all it's overhead?

Conclusion: it's all about the right tool for the job.
Logged

Joost

  • Guest
Re: Larry Ullman... on OOP vs Procedural Programming:
« Reply #3 on: February 23, 2008, 12:45:51 pm »

Thanks for the article.

Consider coding for hardware design, such as HDL for ASICs, where tons of stuff happens at the same time (ie, input pin levels changing state simultaneously). Think of this as trying to code a PHP web page where a user could hit every link or button on the page at the same time - how would you code that in a sequential language?

In cases where the job is concurrent, non-procedural code is required.

If cases where the job is sequential, why use a tool for non-procedural code with all it's overhead?

Conclusion: it's all about the right tool for the job.
Is it possible? Simultaneous processing? At some level it is a sequential process anyway, that is what I so far, learned.
Logged

lessismore

  • Jr. Member
  • **
  • Karma: 0
  • Posts: 67
Re: Larry Ullman... on OOP vs Procedural Programming:
« Reply #4 on: February 23, 2008, 10:02:24 pm »

Is it possible? Simultaneous processing? At some level it is a sequential process anyway, that is what I so far, learned.
I'm not a VHDL guru (but I did get paid and the ASICs went to mass production) - but I'll try to answer.

Yes, simultaneous - think of blobs of hardware in the same system running in parallel.

You are correct VHDL has sequential processing too - you can force that.
You are also correct at some level it's sequential, but you cannot always control the order, example:

sig2 <= in_3 OR sig4;
sig1 <= in_1 AND in_2;

the order of the above two lines in the code is irrelevant - both statements operate concurrent (simultaneously).

I come from a C background and think of VHDL like a C program with no main(), all functions running at once and lines of code in f()s which may not operate sequentially (gross oversimplification).

Back on topic, although VHDL is not an OOP language per se, it is an example where the non-procedural thought process of OOP makes sense in a real-world application.

I'm actually not a big fan of OOP as too often it creates bloat and the "information hiding/abstraction" only makes it harder to understand and test.  However, the concepts are worth learning and using when/where appropriate.
Logged

Joost

  • Guest
Re: Larry Ullman... on OOP vs Procedural Programming:
« Reply #5 on: February 23, 2008, 10:31:42 pm »

Many thanks lessismore, for explaining this. :)

Logged