From: Marcin Raczkowski <mailing.mr@...>
Date: 2007-10-03T05:35:33+09:00
Subject: Re: Ruby vs. PHP

Chad Perrin wrote:
> 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.
> 

Thank God someone that understands :) that are reasons why i want to use 
ruby and mix of rails/custom framework, let's face it, php programmers 
are usually not programmers at all.

Rails is great but heavy and slow.

I want to use best instead of most popular, and i asked you what's best 
in ruby, and all i heard until this post was why php is more popular, 
and CTO should have all the answers anyway. geez :)