On Sep 23, 2007, at 2:21 PM, jtaber wrote:
By now, unless you live in a cave, you've all probably read the new
Digg/Slashdot article ref CDBaby and their return to PHP from
Rails. But the author misses several things besides the effort
being a disaster in project planning and mgmt.
It's true you can easily set up model-type classes in PHP. In fact
I prefer these over Rail's model classes. But for most other
stuff, it's just a case of more effort, complexity, time, and thus,
money. The owner makes some good points about ease of PHP
deployment but really misses some of the key problems we had with
PHP :
1) Lack of Built In Testing - I guess there are some external tools
like UnitTest but nothing as easy as in Rails. And sites without
testing, well....
There are hordes of PHP unit test packages. PHPUnit, SimpleTest. I
don't believe Rails' testing is any better or worse than PHP-flavored
offerings.
2) Lack of Good Redirecting - Rails uses a great front-end
controller and it's simple to call redirects and linktos from
anywhere. PHP has some real restrictions with redirects (ie before
html output, etc).
You can buffer output if you need to. It's not a PHP-limitation: that
location *header* has to come before anything else. There's nothing
PHP or Ruby specific there. Code it up different if you want.
3) Lack of Good Data Protection/Integrity - simple things like
built-in protection against injection attacks
Who cares what language you code in to prevent SQL-based attacks? I
don't see how Ruby or PHP would really differ at all. You could
probably create a safe website in BASIC if you wanted to. I don't
think you can say that Ruby is "safer" than PHP or Java or whatever.
4) ORM - actually this is more questionable but ORM comes in really
handy in things like views where you don't need to do lookups/
retrieval to show something like invoice.customer.name
You can't have ORM with PHP? I've been using packages that do that
for a long time. Most frameworks come with something, and there are
stand-alone packages like Doctrine and Propel.
The lack of these things make us much more productive in Rails or
Django than in PHP.
Rails and Django are not languages. Please compare apples to apples.
It's like saying Scrum and XP are more productive than English.
I think the choice of PHP over Ruby is a deployment based issue. I
don't see how Ruby (or Python, or whatever) has a significant
advantage over PHP just by virtue of the language itself. I realize
Ruby has some really nice features, but the bells and whistles there
don't make much get-it-done difference in the long run. You can write
applications just as easy in either. I can get things done if
everything isn't an object, without lambda functions or whatever. Sorry.
That said, I think its great to keep up on things. I've developed
applications in Rails, and there were lots of things I liked (and
brought with me back to PHP).
For me, it's a matter of familiarity and preference, and a
realization that Rails (and Ruby) is still very new and is dealing
with some growing pains. Besides, if you pick a good PHP framework,
you get all the MVC goodness that comes from Rails methodology, and
the stability and ubiquity that comes with PHP. For me, I've been
enjoying the productivity the Rails methodology boasts of for
years... in PHP.
-- John
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
