My thoughts

I am a Programmer and run a hosting company. Occasionally i get requests for RoR. My investigation of RoR ended up with me deciding not to offer it, why? RoR requires the entire framework to be loaded into memory when running. So everytime someone requests a webpage generated by RoR the whole framework is loaded into memory even if only 1% is used to process the webpage. This is why they recommend FastCGI, because FastCGI loads into memory permanently. Thus the application framework does not have to load into memory each time a page is called, it's already there. This needs to be done for every individual user, meaning RoR is a huge memory hog. I expect to get 500 users per server (load under 1.0) and this would not be possible with RoR users without huge increases in RAM. RoR sucks from a hosting companies viewpoint.

I originally started life as a Perl Programmer. Learning the language was done by examing other peoples code and emulating the best of it. After a while other people Perl programmers started using cPan classes. I never really was able to get into the classes. It seemed to me that if I wanted to send an email, I could copy and paste a 10 line snippet, rather than bloat my app with a 100 line cPan mailing class. My choice was to use an IDE that allowed me to add custom snippets. Programming became a matter of pasting the snippets together to form the script.

I then got involved with PHP and liked it a lot more than PERL. Once again the best way to learn was to examine other peoples code and use the best of it (or write better code). Still using snippets.

Eventually I came to phpclasses, I joined, even though I am not a big fan of classes, just so i could look at others code and write my own snippets. One of the differences between perl classes and php classes is that cpan classes are already loaded into perl, to use the class doesn't involve reading disk. PHP classes on the other hand involves a disk read for every class required/included. I have seen scripts with 20 includes, to my way of thinking this substantially slows down the app (and puts more load on the server).

I guess my real problem with frameworks and classes is that they contribute towards the wasteful practice of bloatware. I also have a problem with not understanding what's going on. I believe the use of frameworks and classes leads to "programmers" that don't really have a clue how to program. It's like Lego, they just fit the blocks together without understanding anything about the blocks. At least with my snippets I am familiar with each one, I built them all from scratch.

I am open minded, but nobody has been able to convince me that classes and frameworks are better. Sure they're faster, but are they better????

I did not know about memory abuse issues of RubyOnRails. It is always good to know these hard facts about something that is being hyped a lot recently.

As for your claims that including PHP classes requires loading files from disk, this is not really accurate.

Most busy sites, like PHPClasses site, use a caching extension like Turck MMCache or others.

turck-mmcache.sourceforge.net/index ...

These caching extensions store the byte codes that result from PHP script compilation in shared memory. Next time the same script is included, the byte codes are loaded from shared memory. No disk access is necessary.

There is no problem with in having many classes or scripts cached in the shared memory, if you do not load all in every script you use. That is a problem of frameworks with excessive class dependencies, but not all frameworks impose such level of dependencies.

I can understand why people are not aware why classes and OOP in general is better.

If nobody explained to you why and you have never read about it, I understand why you may feel like this OOP class thing may sound like yet another mania.

There are several many good reasons to why OOP is a very good thing. You just gave me the idea about to tell a bit about in a future blog post. Hang on.

I would not put classes and frameworks into the same basket...
Classes are a way of thinking; Frameworks are a way to stop thinking.

Oh, it's for sure faster to use a framework when developing something new, but then... Then the nightmare begins...
In most cases the developer does not know all of the framework code and even if he does, it's just a different style of coding, different conventions are respected, etc. In terms of code maintenance - You have to change all Your habits and stick to the framework. OK, You do, but then... Then the nightmare continues... You can not fix all the bugs in an enormous framework, so You report them. Or, let's say You can fix at least the ones that affect You, but the new version of the framework will be incompatible with Your changes, and this is pure waste of time.
OK, You've reported a bug. If this is a new framework, it gets fixed approximately fast... sometimes even in less than a month. If i tell my clients that I need one month to fix a bug on a life site, I'll loose them, but maybe Yours are very patient.
OK, You've found patient enough clients, You are using the framework and You are happy with it, but then...
Guess what? Right - the nightmare continues... Half of the framework developers abandon the project to create a completely new framework. The rest of them do not know they coding and can not ask, because they are already concurrents. Even the most patient clients get rid of You as maintenance gets slower and slower. Oh no, we are not even talking about new features, the rest of the initial team has no enough capacity. And then... Well, You know - the project is abandoned at all and not supported anymore.
All the learning, bug reporting (in fact QA job), all the time lost to figure out what's gone wrong this time with the beloved framework, all this is lost along with most of Your clients, who got tired to wait forever for minor fixes or changes...
And then.... Guess what - a wise man said - "If You want something to happen - write it"...
Yes it will take much more time at the beginning, yes You'll probably make lots of mistakes if You are not very experienced developer. All this is true, but:
You are learning from Your mistakes and improve YOUR OWN coding quality and knowledge;
You can fix a bug or change something easily, as You know each character in YOUR code;
You are constantly reusing Your onw code and experience...

So if you've read enough between the lines - I don't like frameworks AT ALL :)
They are OK for Java and other enormous systems developed during years and years, but for me PHP is best suited for smaller things and frameworks could only have negative impact. Yes, even the better ones...

Best regards,

Alex

P.S.
Talking about snippets - classes could be used the same way, so it should be easy for you to break the barrier. You know all Your snippets, but I bet it occures often to change a snippet for some reason. And then what? Change it in all 1000000.... places You use it?
Classes are much better, when talking about reusability. OK, they could be bigger, but there are reasons for that - You write a class and documment it's behaviour, parameters, etc. Until the declared behaviour remains the same, You can make as many changes as You wish - they are well encapsulated and do not affect the rest of the code.