tecznotes

I've been following the chatter about Ruby On Rails for the past few months with some interest: I'm primarily a PHP developer because it's the first language I learned in any serious capacity, and has continued to serve me well for five years running. My ears always prick up when I hear about someone's favorite development environment, so I occasionally buy books on topics like JSP, Python, or even Lisp to keep myself informed on what I've been missing out on, and whether it's time for a switch.

Today, Jason at 37Signals posted a pithy response to Geert Bevin's criticism of RoR, and I feel as though something may have been lost in the shuffle. Geert makes two good points about development frameworks:

It's utterly ridiculous to compare how long it took you to bash a simple application together. ... I think that driving a web application from a database structure is totally backwards.

...which reminds me why I always seem to stick with PHP, no matter how good the books I read sound. RoR's breathless evangelism shows how fast and easy it is to write a web application, but glosses over two reasons that I shy away from frameworks-du-jour:

1. Frameworks are often advertised on the basis of their design philosophy, and seem to promise that this will effortlessly translate into elegantly-architected applications. Not so: any framework flexible enough to handle all the potential situations in which it may find itself will also be flexible enough to support terrible design decisions on the part of its users.
2. Design is what happens after a framework or environment has been chosen. PHP is often derided as a primitive or childish language, but I've found it flexible enough to support pretty much all the weird stuff I need it to do with a minimum of fuss, which includes building personal frameworks not unlike RoR.

If I were man enough, I guess I'd be a Perl guy.