From: Chad Perrin <perrin@...>
Date: 2007-10-03T05:22:04+09:00
Subject: Re: Ruby vs. PHP

On Wed, Oct 03, 2007 at 12:57:07AM +0900, Richard Conroy wrote:
> On 10/2/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> > This thread has gone on so long that I've forgotten the original
> > *business* question that was posed. But I *do* remember that it *was* a
> > business question, and not a linguistic one. Therefore, I think that the
> > Google and Amazon experiences, both of large web enterprises that
> > started small(ish) are highly relevant.
> 
> Well thats what has shaped my answers. In particular the OP wanted
> to push his custom Ruby (non-Rails) solution over a custom PHP
> solution on a customer.
> 
> The reasoning behind building another Ruby Web Framework from
> scratch on the customers' dollars instead of using the already
> excellent ones out there seemed a bit flawed to me. In which, case
> a Warts-n-all PHP solution may have suited the customer better
> (who according to the OP is not tech-savvy).
> 
> (Chad - this was the point I was getting at when I was saying
> PHP beats Rails)

I don't think saying that PHP serves the customer better is such an open
and shut case.  I also don't see how building a Ruby web framework from
scratch wastes customer dollars any more than building a PHP web
framework from scratch.

Based on what I've seen here, most of the arguments against doing what
the OP proposes are based on:

  1. PHP is more popular, so getting more (on average, low quality)
  programmers familiar with the technology is easier.

  2. PHP is more popular, so migrating from one shared host to another is
  easier (even though shared hosting probably isn't what's intended
  here).

  3. PHP is more popular, so managers are less likely to balk at it.

  4. Rails already exists, so it's better to build a new framework than
  to build a new framework.  (One of those two is in PHP, the other in
  Ruby.)

I'm just not buying any of that as technical reasons to choose PHP
instead of non-Rails Ruby.


> 
> > 2. The LAMP stack is a major force in web applications. I'm not quite
> > ready to say, "Nobody ever got fired for deploying an RHEL LAMP web
> > application", but I think you have to be pretty close to that.
> 
> The LAMP stack is an instance of 'The Pit of Success' - by following the
> easy, well-known, route to implementation of one (even dogmatically),
> your solution will probably Just Work with predictable amount of effort.
> 
> That previous statement generates a lot of warm fuzzies to corporate
> stake holders.

. . . which is a great reason to use LAMP if that's the only way you're
going to get the contract.  It's not such a great reason if you're
looking for the best technologies to use for a given project.


> 
> > So I think a home-grown non-Rails Ruby solution is a non-starter here
> > for a number of reasons. It's not "Ruby vs. PHP", it's "Rails vs. PHP".
> 
> And no disservice to the non-Rails Ruby frameworks out there. Certainly
> pure-Mongrel handlers, Merb & thread-safe ORM sounds like a fun
> implementation to me.
> 
> But be nice to your customers.

. . . even if it means using what's best, rather than what's most
popular.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of others
we should be glad of an Opportunity to serve others by any Invention of
ours, and this we should do freely and generously."