I can''t think of a good reason, other than it''s legacy code which hasn''t gotten around to being changed to RoR. http://rubyonrails.org/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 http://37signals.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 http://basecamphq.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 http://backpackit.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 http://www.loudthinking.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 See this post - "PHP Easter Eggs": http://shiflett.org/archive/191 Joe -- Posted via http://www.ruby-forum.com/.
Joe wrote:> I can''t think of a good reason, other than it''s legacy code which hasn''t > gotten around to being changed to RoR.Use the right tool for the job. PHP is excellent for glueing some includes together with some HTML and CSS. For the record, the RoR website also runs Python. I don''t see what the big deal is, to be honest. -- Jakob Skjerning - http://mentalized.net
Jakob L. Skjerning wrote:> Joe wrote: >> I can''t think of a good reason, other than it''s legacy code which hasn''t >> gotten around to being changed to RoR. > > Use the right tool for the job. PHP is excellent for glueing some > includes together with some HTML and CSS.So is Rails. And Ruby. And Perl. And SHTML. And many others.> For the record, the RoR website also runs Python. I don''t see what the > big deal is, to be honest.It''s like Sun running .Net. Or Microsoft running Linux. A front page is trivially easy in Rails... Joe -- Posted via http://www.ruby-forum.com/.
While I agree with your point, I''d rather have David and the team keep working on Rails then convert their website over. I''m sure that if someone wanted to volunteer to do all the work, they would give it some thought. Bob Silva http://www.railtie.net/> -----Original Message----- > From: rails-bounces@lists.rubyonrails.org [mailto:rails- > bounces@lists.rubyonrails.org] On Behalf Of Joe > Sent: Sunday, February 05, 2006 1:21 PM > To: rails@lists.rubyonrails.org > Subject: [Rails] Re: Ruby on Rails and other sites use PHP? > > Jakob L. Skjerning wrote: > > Joe wrote: > >> I can''t think of a good reason, other than it''s legacy code which > hasn''t > >> gotten around to being changed to RoR. > > > > Use the right tool for the job. PHP is excellent for glueing some > > includes together with some HTML and CSS. > > So is Rails. And Ruby. And Perl. And SHTML. And many others. > > > For the record, the RoR website also runs Python. I don''t see what the > > big deal is, to be honest. > > It''s like Sun running .Net. Or Microsoft running Linux. A front page is > trivially easy in Rails... > > Joe > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Sun, Feb 05, 2006 at 10:21:01PM +0100, Joe wrote: } Jakob L. Skjerning wrote: } > Joe wrote: } >> I can''t think of a good reason, other than it''s legacy code which } >> hasn''t gotten around to being changed to RoR. } > } > Use the right tool for the job. PHP is excellent for glueing some } > includes together with some HTML and CSS. } } So is Rails. And Ruby. And Perl. And SHTML. And many others. } } > For the record, the RoR website also runs Python. I don''t see what the } > big deal is, to be honest. } } It''s like Sun running .Net. Or Microsoft running Linux. A front page is } trivially easy in Rails... It''s more a matter of eating your own dog food. If what you are promoting (particularly relevant for rubyonrails.org and 37signals) isn''t good enough for you to use yourself, why should anyone else use it? There is also something to be said for forcing people to use what they are working on. Look up the history of the transition from SunOS to Solaris. } Joe --Greg
David Heinemeier Hansson
2006-Feb-06 02:56 UTC
[Rails] Re: Ruby on Rails and other sites use PHP?
> It''s more a matter of eating your own dog food. If what you are promoting > (particularly relevant for rubyonrails.org and 37signals) isn''t good enough > for you to use yourself, why should anyone else use it? There is also > something to be said for forcing people to use what they are working on. > Look up the history of the transition from SunOS to Solaris.I agree. You should eat your own dog food. So for web _applications_ we built specifically for rubyonrails.org, we wouldn''t dream of using anything but Rails. Thus, we use Typo (weblog), Hieraki (manuals), and i2 (wiki). All open-source Rails applications. For wiring together static pages? I rather like PHP. I wouldn''t recommend anyone to use Rails for something as simple as wiring together a couple of static pages with headers and footers. If rubyonrails.org was to get a real content-management system running, then yes, of course we should be using Rails (unless there was a good existing system in another language). Note that we also use Python for Trac and I think Perl is involved with running the mailing list. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
David
> For wiring together static pages? I rather like PHP. I
wouldn''t
> recommend anyone to use Rails for something as simple as wiring
> together a couple of static pages with headers and footers.
Why is PHP better than Rails at that simple but frequent kind of tasks?
That''s why people keep saying : "eat your own dog food". If
you do, then
you''ll feel pain in places you normally never exercise, and maybe
you''ll
want to start acting on it.
Alain
> -----Original Message----- > From: rails-bounces@lists.rubyonrails.org > > David > > For wiring together static pages? I rather like PHP. I wouldn''t > > recommend anyone to use Rails for something as simple as wiring > > together a couple of static pages with headers and footers. > > > Why is PHP better than Rails at that simple but frequent kind > of tasks? >Why is a hammer better than a screwdriver at hitting nails ? You could weld a screwdriver onto a hammer, but the end result would be a tool that''s better at using screws and worse at it''s core functionality: hitting nails. Would this be a better tool ? (it would also have a bigger learning curve and more accidents would happen with it, and a lot of beginning carpenters would get confused and start trying to hammer screws) Hobbyists use swiss army knives - pro''s don''t: they have the right tools for the job and know how to use them in order to get a better result faster. My 2 cents... Piet.
This question of PHP vs Rails comes up more than enough, and it therefore needs to be seriously addressed. I used to work for a company specializing in PHP web development. Towards the end of my employment I was advocating the development of a PHP framework based off of Rails and Cake (the open source PHP framework inspired by Rails). I spend a little over 2 months putting together a prototype of a PHP like Rails. The endeavor has illuminated many fine points of this distinction. In an attempt to answer the question of "Why would anyone prefer PHP over Rails or visa versa?", I present the following with an emphasis on the implementation. 1. Ruby over PHP a) the PHP parser is too inflexible. - The biggest caveat of PHP is that methods cannot be added on the fly to classes without compiling in a special library called runkit, located at http://php.net/manual/en/ref.runkit.php. In other words: classes are closed upon definition. If one wants to create an active_record like ORM then one is determined to include runkit when compiling the php parser or write class definition files to the hard drive on the fly. b) PHP references are kludged in PHP4. It is common to pass by reference in C and C++ in order to save memory and utilize return value optimization. In my implementation of a PHP version of Rails I ended up splitting an "ActiveRecord" into two classes: a Factory and an Object class. Each object instance would have as a data-member a reference to its Factory in an effort to not duplicate the sql_generation methods. The Factory instance would also contain all of the instances of its objects, hoping that each object would simply be a reference into the Factories container. As a bug, when the objects filled up memory so did the reference count... I belive this is fixed in PHP5. c) is possibly two counts: an overbearing responsibility upon global methods in PHP, and the fact that PHP''s object.c class is designed to do everything. Addressing the later first, I acknowledge that both PHP and Ruby have base object classes. Their distinction is that, in Ruby the object class is designed to provide methods to all inherited objects, whereas in PHP the object class is designed to also contain data: for example, there is a minimal distinction between PHP''s array data structures and PHP''s object data structures; the two are almost equivocal and it is therefore tiresome to distinguish (in code) between objects, arrays and hashes (what PHPers call associative arrays). As a result there is a lot of type checking in PHP. I suspect that this equivocation is the main reason for the plethora of global methods. d) finally, I find that the simplicity of Ruby''s to_s style methods put the language above and beyond both Java and PHP. However, I fear that I am not expert enough to defend this adequately. It may not be hidden that I loath PHP, and mainly because of the presence of (c). However I also feel that PHP has its place. Let me elaborate. 2. PHP over Ruby a) PHP''s learning curve is close to nothing. Switching mentalities between Java, C and C++ to PHP is admirably easy. Most CS graduate students only have experience in the three canons of development languages listed above. The better education includes experience in Scheme, or Lisp, for the shear breadth of syntactic understanding. Most of us do acknowledge the importance of pseudo code and see that all implementations are just divergent from that initial "pseudo" logic. However, as a precondition, some development environments cannot cater to a heightened sense of programesque. In other words, there is a need for non-CS people to write web based programs and PHP satisfies that need. I do, in an elitist fashion, consent that Ruby is the superior language over PHP. However I also realize that PHP satisfies a niche that is difficult for Ruby to semantically attain (however it is certainly possible to attain a php (read global) like semantic). 3. A little bit about Rails Insofar as I can tell, PHP has another upper hand over Rails/Ruby, and that is the support PHP has within Windows Servers. One of the major setbacks I encountered in a PHP version of Rails was the esteem of the dispatch.fcgi. Windows servers are mainly processed based (as opposed to thread based), and therefore prefer to spawn another parser for each request rather than handle an error in a thread. PHP has done an awesome job making a fastcgi port of their parser. PHP''s fastcgi is oriented towards ever .php file rather than just one dispatcher. I would love to see Ruby duplicate this effort in their own fcgi such that it can run different dispatch.fcgi''s. Such a framework as Rails is possible in PHP, however because of the implementation restrictions of PHP, developing a "Rails" for it should be tiresome, if not mind wracking. However, I do not think there should be a Rails equivalent developed for PHP solely because the language fits a different niche; if I were to describe it, I would say that it is the quick, easy and dirty. Regards, Travis Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060206/7ef6e486/attachment.html
>>> For wiring together static pages? I rather like PHP. I wouldn''t >>> recommend anyone to use Rails for something as simple as wiring >>> together a couple of static pages with headers and footers. >> >> >> Why is PHP better than Rails at that simple but frequent kind >> of tasks? >> > > Why is a hammer better than a screwdriver at hitting nails ? > ... > Hobbyists use swiss army knives - pro''s don''t: they have the right > tools for > the job and know how to use them in order to get a better result > faster.Yes, this is the meat of the matter. It''s about using the right tool for the right job. Rails for a simple static website is what we call "overkill". Yes, rails is capable of performing this "simple but frequent kind of task", but why would you use it for that? It''s more akin to using a sledgehammer to drive a finishing nail. David makes an excellent point about the variety of technologies employed on the rails site. Actually, I think that reflects positively on the rails community as a whole. This is not about starting some rails religion (sorry perl guys). It''s about pragmatism. Get it done in the best way possible in the least amount of time. -Derrick
Thanks Derrick, By far a better post than mine. It is at base a pragmatic issue. On 2/6/06, Derrick Spell <derrickspell@cdmplus.com> wrote:> > >>> For wiring together static pages? I rather like PHP. I wouldn''t > >>> recommend anyone to use Rails for something as simple as wiring > >>> together a couple of static pages with headers and footers. > >> > >> > >> Why is PHP better than Rails at that simple but frequent kind > >> of tasks? > >> > > > > Why is a hammer better than a screwdriver at hitting nails ? > > ... > > Hobbyists use swiss army knives - pro''s don''t: they have the right > > tools for > > the job and know how to use them in order to get a better result > > faster. > > Yes, this is the meat of the matter. It''s about using the right tool > for the right job. Rails for a simple static website is what we call > "overkill". Yes, rails is capable of performing this "simple but > frequent kind of task", but why would you use it for that? It''s more > akin to using a sledgehammer to drive a finishing nail. > > David makes an excellent point about the variety of technologies > employed on the rails site. Actually, I think that reflects > positively on the rails community as a whole. This is not about > starting some rails religion (sorry perl guys). It''s about > pragmatism. Get it done in the best way possible in the least amount > of time. > > -Derrick > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060206/2258c5ae/attachment.html
Piet, Derrick, David and all
>> For wiring together static pages? I rather like PHP. I
wouldn''t
>> recommend anyone to use Rails for something as simple as wiring
>> together a couple of static pages with headers and footers.
Please explain WHY and HOW PHP is better than Rails, to somebody who
doesn''t know PHP.
If it''s really better, then it may be worth learning but so far, nobody
has explained why they think PHP is better.
Alain
On 2/6/06, Alain Ravet <arav2132@biz.tiscali.be> wrote:> Please explain WHY and HOW PHP is better than Rails, to somebody who > doesn''t know PHP. > If it''s really better, then it may be worth learning but so far, nobody > has explained why they think PHP is better.To put a header in using PHP: include("header.php"); To put a header in using Rails: Generate a rails application Create a layout Create your controllers Create your views etc. The point is that Rails is a framework for building web applications, and PHP is a programming language. You don''t need the large overhead of a framework for putting some headers and footers on a few pages. Instead, use a single line of PHP and forget about it. Does that Help? Josh
> > Please explain WHY and HOW PHP is better than Rails, to somebody who > doesn''t know PHP. > If it''s really better, then it may be worth learning but so far, nobody > has explained why they think PHP is better. >Beauty is in the eye of the beholder. There are lots of programming languages today, and there will be many more in the future. At the end of the day the tools we are discussing end up producing some type of HTML or equivalent. How you get there is up to you. Better is a very subjective term. I think it is an apples and oranges comparison as Rails is a Framework and PHP is a language. I have used PHP, ASP, ASP.NET, Java, and perl... Lately I ride the Rails. The diversity of my toolbox allows me to see value in the Rails framework. If you have never used PHP, and don''t feel the need to... don''t. ~ Ben On 2/6/06, Alain Ravet <arav2132@biz.tiscali.be> wrote:> > > Piet, Derrick, David and all > > >> For wiring together static pages? I rather like PHP. I wouldn''t > >> recommend anyone to use Rails for something as simple as wiring > >> together a couple of static pages with headers and footers. > > > Please explain WHY and HOW PHP is better than Rails, to somebody who > doesn''t know PHP. > If it''s really better, then it may be worth learning but so far, nobody > has explained why they think PHP is better. > > Alain > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ben Reubenstein http://www.benr75.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060206/0ec832c7/attachment-0001.html
On Mon, Feb 06, 2006 at 10:56:02AM -0600, Josh Charles wrote:
} On 2/6/06, Alain Ravet <arav2132@biz.tiscali.be> wrote:
} > Please explain WHY and HOW PHP is better than Rails, to somebody who
} > doesn''t know PHP.
} > If it''s really better, then it may be worth learning but so far,
nobody
} > has explained why they think PHP is better.
}
} To put a header in using PHP:
}
} include("header.php");
}
} To put a header in using Rails:
}
} Generate a rails application
} Create a layout
} Create your controllers
} Create your views
} etc.
}
} The point is that Rails is a framework for building web applications,
} and PHP is a programming language. You don''t need the large overhead
} of a framework for putting some headers and footers on a few pages.
} Instead, use a single line of PHP and forget about it.
}
} Does that Help?
I now understand what you mean by PHP being better than Rails for this.
I''m
not clear on how PHP is better than straight .rhtml files, however.
} Josh
--Greg
On 2/6/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:> I now understand what you mean by PHP being better than Rails for this. I''m > not clear on how PHP is better than straight .rhtml files, however.I''m not sure .rhtml file will run without the framework... not too sure about that. Josh
On Mon, Feb 06, 2006 at 11:09:34AM -0600, Josh Charles wrote: } On 2/6/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote: } > I now understand what you mean by PHP being better than Rails for this. I''m } > not clear on how PHP is better than straight .rhtml files, however. } } I''m not sure .rhtml file will run without the framework... not too } sure about that. Under Apache, you need mod_ruby (and appropriate configuration), but then they do. I have used it with Apache2. } Josh --Greg
Josh
> To put a header in using Rails:
> 1/ Generate a rails application
> 2/ Create your controllers
> 3/ Create your views
> 4/ Create a layout
> 5/ etc.
Well No: you just need to 1,2 and 3
> 3/ Create your views
Fair enough, it''s the content, as in PHP
> 1/ Generate a rails application
Yes, that''s required.
> 2/ Create your controllers
You wouldn''t need this step if ''rails myapp'' would
create a controller
by default.
I''d also prefer the empty Rails app to come with a index.rhtml, instead
of index.html.
> 4/ Create a layout
> 5/ etc.
No, nothing else is required.
So, all it would take is for ''rails <your_app>'' to
generate a controller
by default, and replace ''index.html'' by
"index.rhtml".
Maybe we''re still here because core people don''t feel _this_
pain, as
they keep using PHP for those "trivial" tasks.
Alain
On 2/6/06, Alain Ravet <arav2132@biz.tiscali.be> wrote:> Josh > > > To put a header in using Rails: > > 1/ Generate a rails application > > 2/ Create your controllers > > 3/ Create your views > > 4/ Create a layout > > 5/ etc. > > > Well No: you just need to 1,2 and 3The Layout is the most important part, as it mimics the header a footer bevahiour that we were discussing, which was the whole point of my message. If you just have a few static pages that require headers and footers, of course go with PHP, because it''s alot simpler. Rails is an *application framework* which means (gasp!) it''s meant for building web applications. For simple header and footer work, Rails is too much. It''s like using an abrahms tank to kill a horse fly.> So, all it would take is for ''rails <your_app>'' to generate a controller > by default, and replace ''index.html'' by "index.rhtml".Actually, it would be a little more than that. It would mean removing index.html completely and letting dispatch.cgi do it''s magic. routes.rb would need to be able to connect to this automatically generated controller as default. Replacing index.html with index.rhtml doesn''t gain you anything as rails would never be invoked. Josh> Maybe we''re still here because core people don''t feel _this_ pain, as > they keep using PHP for those "trivial" tasks.
Phillip Hutchings
2006-Feb-06 20:10 UTC
[Rails] Re: Ruby on Rails and other sites use PHP?
On 7/02/2006, at 5:38 AM, Alain Ravet wrote:> Please explain WHY and HOW PHP is better than Rails, to somebody > who doesn''t know PHP. > If it''s really better, then it may be worth learning but so far, > nobody has explained why they think PHP is better.PHP is not ''Better'' than Rails. PHP is just easier and less resource intensive for some tasks. Take putting a standard header in every file for instance. You can do this with Rails, it isn''t hard, but then you''re running a Rails application for a two page site. Rails takes substantial amounts of RAM, especially compared to PHP, and once you have 10-20 customers on one machine you''ll see. (based on a memory usage of ~15MB per application instance) PHP shares the engine between multiple sites, one block of memory for all customers. You can then put hundreds of sites on one machine. Also you only need two files - the content page and the header page, plus mod_php installed. Rails needs a whole bunch of support files and a fastcgi runner. If I have to create a database driven web application I''m leaping straight to Rails, it''s much nicer. If I need to do 5 pages with common headers and a contact form PHP is easier. Plus there are many more PHP programmers than Ruby/Rails programmers. -- Phillip Hutchings phillip.hutchings@sitharus.com http://www.sitharus.com/
softwareengineer 99
2006-Feb-06 20:13 UTC
[Rails] Re: Ruby on Rails and other sites use PHP?
Phillip Hutchings <sitharus-rails@sitharus.com> wrote: Plus there are many more PHP programmers than Ruby/Rails programmers. I don''t think that will stay true for long. Frank --------------------------------- Brings words and photos together (easily) with PhotoMail - it''s free and works with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060206/43b9027e/attachment.html
softwareengineer 99 wrote:> > */Phillip Hutchings <sitharus-rails@sitharus.com>/* wrote: > > Plus there are many more PHP programmers than Ruby/Rails programmers. > > I don''t think that will stay true for long. > FrankI do... Rails may be "the best thing since sliced bread" for building web apps, but 90%+ of the web aren''t actual web applications. If all you need is some dynamic server-side stuff sprinkled around your largely static web site, you shouldn''t be using Rails. That where things like PHP, ColdFusion, what-have-you, will always be better tools. And that''s not a bad thing. Leave the web application building to the web application developers. Leave the simple dynamic stuff to the web designers and "HTML coders" out there. Division of labor, at this level, is a good thing, IMO. -Brian
Brian
> I do... Rails may be "the best thing since sliced bread" for
building
> web apps, but 90%+ of the web aren''t actual web applications.
If
all you
> need is some dynamic server-side stuff sprinkled around your largely
> static web site, you shouldn''t be using Rails.
Once again, it''s not an explanation, just a fact stating:
"Rails is less good at this because PHP is better at this".
I don''t think that PHP is too complex, but it''s one more tool
to
install, configure, optimize, maintain and master.
Honest technical question in search of an honest technical answer:
can''t
Rails be optimized in that area too, or is it just a "we don''t
feel like
it because we use PHP for those cases, and it just works for us.".
Just imagine if Rails would not handle web services efficiently and you
needed it. Would you be happy with a "use Java, it''s better at web
services"?
When working in Java, I would used to use Tomcat as an app AND as a file
server. It was not the fastest, but it was fast enough for my needs.
Over time it improved. Why would I have bothered putting Apache in the
equation?
Same story here: "Two tools good; One tool better".
Alain
PHP and Perl/CGI have the advantage that they are there on every web server. For many small applications it is a requirement to run on an existing server without a lot of installation and administration effort. Or it is a requirement to pick a hosting provider without being bound to the additional constraint of having rails running. Sometimes it is much better, to run a perl script to add certain headers and footers to a web page of static html. This can even be done by a cron job. Why worry about recalculating the page for every viewer? I would not consider it a good idea to build a complex application in PHP, but it has been done successfully, just consider wikipedia. How is this scaling issue: Would it be an option to write such a heavily used application as wikipedia in Ruby on Rails or would it require so much hardware that wikipedia could not exist like we know it now? Best regards Karl Brodowsky <bk1 at ...>
Phillip Hutchings
2006-Feb-06 22:11 UTC
[Rails] Re: Ruby on Rails and other sites use PHP?
On 7/02/2006, at 9:13 AM, softwareengineer 99 wrote:> > Phillip Hutchings <sitharus-rails@sitharus.com> wrote:Plus there > are many more PHP programmers than Ruby/Rails programmers. > > I don''t think that will stay true for long.Lets hope you''re right :) -- Phillip Hutchings phillip.hutchings@sitharus.com http://www.sitharus.com/
Phillip Hutchings
2006-Feb-06 22:17 UTC
[Rails] Re: Ruby on Rails and other sites use PHP?
On 7/02/2006, at 10:06 AM, Alain Ravet wrote:> Honest technical question in search of an honest technical answer: > can''t Rails be optimized in that area too, or is it just a "we > don''t feel like it because we use PHP for those cases, and it just > works for us.".Rails is opinionated software. Rails does web applications, it does nothing else. It doesn''t do the simple cases, you can use eruby direct from mod_ruby, you can use SSI, you can write your own Ruby CGIs. This is what makes Rails such a pleasure to work with, the domain is chosen and it won''t expand, unless you use plugins. PHP is a mess because it tries to be everything to everyone. It just won''t work. The language is clunky and the class system is appalling, but it handles the basic cases well. Rails works with full-blown applications. It does it well. Running a small static page with Rails is slow and a waste of resources, but an application that has to be maintainable and makes sense for a MVC architecture works very well. Think of what you''re doing, choose the tool. There''s a reason why POSIX compatible systems have a whole heap of tools but don''t have one tool to do everything. -- Phillip Hutchings phillip.hutchings@sitharus.com http://www.sitharus.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2234 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060206/83e6863a/smime.bin
On Feb 6, 2006, at 2:10 PM, Phillip Hutchings wrote:> Plus there are many more PHP programmers than Ruby/Rails programmers.This may be great if you''re trying to hire a programmer, or get help. But then again, maybe not. If RoR is as productive as people here claim, then hiring one good, hard-to-find RoR programmer would actually be better than hiring three good, readily available PHP programmers. I seriously doubt (s)he would command three times the salary of a PHP programmer, so I should save money. Secondly, there would need to be less corroboration with the smaller team, so (s)he would get more done. (The Mythical Man-Month effect) Sometimes less is more. Less code is definitely better. If anyone thinks more is better, remember that roughly 94% of the world uses the Windows operating system. Okay, maybe that IS the better option, if you''re into writing viruses. ;-) Doug