Just in time to fit to Michael's observation, I'm feeling like talking about Java and Python, again; nothing particularly deep, though, I'm afraid. You see, Ian Bicking ponders on application development models, PHP, and Zope. (And little Python too.) The point was, or the point as I twisted it to fit my universe, that implementing a software in a pure object oriented fashion does not give as much leeway as implementing it partly imperative way, partly object oriented. In imperative and iterative way, you pile functionality to the software and find the objects through experience during the development. And the abstractions needn't always be objects, they can be plain routines too.

This is exactly what I've been going through developing in Java versus in Python. Finding regular functions and procedures and modules, as opposed to objects, is just so much easier and natural to me. As you write code, you see that this chunk of code really is something you are going to need in some other context later; fine, let's put that into a routine. The great thing about this is that you don't lose anything with it. In fact, the code is generally more readable after such refactoring. The name of your routine succintly says what the chunk of code in it is supposed to do.

Whereas in a pure object oriented development, you generally need to think what this routine belongs to. Sure, you can slap the routine in Java to a static method and do the thing in a imperative way, but this is not the way Java programs are supposed to be structured; and I'm talking just about that. This gets into my way all the time. It's nice when things finally click and a thing can be stuffed into an object, but often they don't.

In other words, object orientation is a nice way to structure your program, though not necessarily the best way, but it's a poor way to figure out how to solve a specific "algorithmic" problem. The first thing that I do when I'm faced with a specific problem is to connect the dots from end to end (if that's possible), ie. to make sure that I can do the whole thing. Often skeching solution to the problem requires so much code that I need to restructure my code. This most often pretty easy in the imperative way, as I've explained.

I am willing to accept that I'm a poor object oriented programmer, but I think there's more to the issue than that. But I don't know.

...

As for PHP, I agree with Ian that PHP's strong point is specifically the fact that you can so easily slap a snippet of code to a web page, to, say, print a date on the page, and organically grow it by slapping more snippets to the page. I've found PHP rather icky to program with, but maybe that's just an attitude. PHP might not be a great programming language, as far as programming languages are considered as such, but it's definitely a great tool for a broad set of problems.