Hi everyone,
In My Humble Opinion, I think CakePHP made PHP bondage-and-discipline.
The first time I heard about RubyOnRails, CakePHP, PHPonTrax, JavaOnSails &c… I thought: “Hey! it’s no novelty, actually there’s a book named ‘Design Patterns’ that deals with all that stuff of Active Records and so on… What’s the need of such things?”
I never paid too much attetion to them, in fact I related them to the dreaded COBOL - but Ruby and PHP are not as verbose as COBOL-fingers.
As everybody knows, a well respected hacker will never admit to have learned COBOL - but unfortunately I have learned it in College, so I am not a hacker (yet 
). Hey! Hold on! It was just a semester in that bloody Mackenzie’s (yes, we have a Mackenzie in Brazil) and I’ve abandoned it in the middle of the discipline.
You know, COBOL has a very strict structure on how programmes should be engineered and written. There are only two level of tabs, and those DIVISIONs on each you define variables, file descriptors, io masks - this sort of pedantic way of programming.
But COBOL enabled brain-dead people to develope all types of commercial softwares. COBOL was written in english and supposedly an english-speaking person should be able to create, read, understand and modify any routines made by someone else. COBOL even had paragraphes.
This characteristic could only be achieved if everyone did everything in a single and common way - I should be guided, through the language syntax, to write the same solutions in the same way as you would do. Gosh, was COBOL the computer’s NewSpeak?
Well… Time has passed, those dinosaurs mainframe were gradually replaced by new servers, and the languages evolved into a more structured and more free syntax, like C.
The issue with C, Perl, PHP, Java and all-alike, is that you can always do the very same thing in a different way, opposed to COBOL which is bondage-and-discipline.
The phisolophy of “Convention over Configuration”, or whatever you call it, is just a modern way to enforce bondage-and-discipline on programmers. Convention itself is harmless, Kernighan and Ritchie have the blessed ident style and so Java people, GNU people.
The problem rises when Convention replaces Freedom - a forced standardisation of programming which affects almost every aspect of coding: naming style, code organisation and even the “best practices”.
Someone thought to consolidate all those Design Patters in a single project and give a name to it. CakePHP was inspired by RubyOnRails, both share some features - and both turned vanilla languages into bondage-and-discipline.
RubyOnRails and CakePHP are not only tools which would help the developer to be more productive - oh no… they’re schools of thoughts. They have a way on doing things which are considered “best practices” and should be followed closely.
Bondage-and-discipline is not Bad And Wrong. It is a leverage for those who are more pragmatic in solving problems or creating fast-food solutions - to problems which the kernels are the same among near 80% of them.
I like CakePHP… But I like PHP better. Sometimes I want to have freedom to model a solution according to a very special line of thoughts that oftenly is not the same of CakePHP. Now I have arrived to the point I wanted.
As CakePHP makes PHP into bondage-and-discipline language, programmers - specially the begginners - tend to adapt their solutions into CakePHP frame… Sometimes the best step is something quicker and more direct, but CakePHP, RubyOnRails or [your language of choice]on[transportation of choice] forces flowing or spliting the solution into meaningless parts.
In an exaggerated representation: “Hey, I just want to print out a formatted number! Why create a helper_to_format_number method in the PrintHelper class?” or “Why am I iterating all the result set in Model class into an array to iterate again in the View?” Or even, “I must structure this data into that framework-structure to output using the MagicalOutputHelper class…” (which likely would take longer to do).
I don’t if I am being clear here. These frameworks are wonderful tools - actually I develope a tool for CakePHP named dbdesigner2cake - but I don’t twist my solutions logic to fit the CakePHP’s mold. Don’t you even bother to talk about that vendor directory on CakePHP, because few things just won’t work; some third-party modules count on the fact that’s being run standalone or isolated - not within a framework.
There are situations that RubyOnRails (that’s gonna ache on the Ruby Envy guys) and CakePHP just won’t do, they’re closures with programmers stuck inside.
Design Patterns should be used a la carte. “Oh God! My code is messed up, let me organise it using MVC”, “Ahan, I am just doing CRUD here, I guess Active Record will fit just fine”, and so on.
Perhaps there’s something to learn with DJango guys, they actually stated they’re against auto-magic. As they don’t hide the magic behind the stage of an all-mighty framework, the programmer DOES HAVE the option to use or not one of the magics available without being considered too unelegant. Or extend it to make it able to do the desired functionality. When the framework is too magical simply there is not sockets to connect an extension…
These frameworks do the dirty work for the programmer charging a price: less flexibility and freedom of choice of how to do things. Is this good? I don’t think so…
I love CakePHP productivity, but I dread that it will make all programmers to code all the same code. Oh you don’t agree… If you want to make a blog with the too-obvious table Posts on it, unless we’re talking about different frameworks, on CakePHP the model class would be exactly like this:
<?php
class Post extends AppModel {
var $name = “Post”;
}
?>
See? There are thousand of ways on naming, invoking and accessing a database table in PHP. But in CakePHP this is the only way.
The same applies to [Your Rail Framework Of Choice]. Or even [Your language-of-choice] made bondage-and-discipline.
UPDATE: I found in Technorati two blogs supporting my point of view:
http://www.jonlee.ca/switching-from-rails-back-to-php/
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
