I think the biggest problem with the procedural way is that it can get so messy - where’s that variable, did I declare that, where was that again…Maybe I am just a mess, but OOP provides nice abstraction and handling of data AND is neat and tidy. You can say that you have an elephants memory and all, keeping multiple pages in your head but come back a week or a month later and it be all scrambled for you. OOP on the other hand will get you working in no time. Basically what it boils down to is that human beings are OOP not procedural and so it goes.

Of course there’s the bad messy programmer and good tidy programmer and then there’s Murphy’s Law.

Somebody writes an informative article that basically says “even though OOP code executes slower you should use it anyway” and OOPifiles get all bent out of shape.

Otherwise this was an interesting post on performance tuning.

You are comparing algorithms to methodologies in most of your cases which makes any conclusion impossible.

Agreed, especially with”makes any conclusion impossible”. Keeping focused on PHP, the assumption that “OO => slow app” is particularily acute, which I was attempting to question. Or perhaps what I was challenging was the reverse: procedural “PHP => fast app”.

Talking purely in terms of end results, the untestable experiment I’m trying to suggest is if we gave two, equally talented, developers a problem to solve of significant complexity using PHP, the developer that applies OO is more likely to deliver something that performs well and scales consistently. And that’s not a direct result of OO directly but rather “side effects” that arise from the human side of development.

I’m trying to suggest is if we gave two, equally talented, developers a problem to solve of significant complexity using PHP, the developer that applies OO is more likely to deliver something that performs well and scales consistently

First, I seriously doubt that there would be much difference the performance or scalability either direction, given two equally talented developers.

However there is one thing about those two apps that the pro-OOP crowd never like to admit. That is that if you gave the code to a sampling of PHP programmers, the vast majority would go for the procedural code because it is simply easier for most PHP programmers to understand. And that’s why there are so many successful PHP apps with procedural code.

I think the one problem with OOP that never gets mentioned is that it is a methodology driven by consultants who make their living on “the new.” You only need to read the SitePoint forums to follow the fads: Use inheritance, no it’s bad now. Use get/set, no don’t use them any more. Nouns or verbs, who knows which is best yet? Not clear on MVC, that’s OK because it is so vague that it can be neither accepted or refuted, only discussed endlessly.

The main problem that those few who chose the OOP version of your “untestable experiment“ app above is that they would criticize it for only using DataObjects instead of Domain Model - So 2004!

Seriously, I think your make a good point that performance isn’t everything. Applications need to run, but they also have to be built, maintained, changed and extended. That is why good design, regardless the methodologies, is so important. However, I just have not heard much of the positions that you are “challenging”. In fact, I think most non-beginner PHP programmers seem to understand that it is things like algorithm choice, database design, and optimizing SQL that actually make real differences in PHP apps. OO vs Procedural is really only on the radar of a very few OOP pundits.

And that is why I like the basis of your article and the article on performance. The idea that PHP apps need to be designed to balance the fact that they must be built, maintained, changed, extended and run is an important one.

In fact, I think most non-beginner PHP programmers seem to understand that it is things like algorithm choice…

I agree and really think this is more the heart of the issue. Your two talented developers may in fact end up using a very similar algorithm.

So what is it about OO that may cause one to come up with a better algorithm (single-pass as opposed to multi-pass in this case)?