When I have seen large rewrites fail, it's often because of an all-or-nothing rather than iterative or staged approach. At my previous company, 2 different managers approached the migration of a massive VB6 project. The first tried a total rewrite in C#. The code was ingenious and better in many ways, but ultimately it failed after many wasted man-years, and he was let-go. There was just too much hidden wisdom in the spaghetti code to replace it quickly and easily. A wiser manager, and friend of mine, managed the rewrite, but in stages. He would carve out a chunk, and have it replaced. He's a director there now.
Summary: (1) He's a better programmer now, having internalized RoR best practices, and can apply it to raw PHP code, (2) Decreased load issues, (3) All company code can be PHP, and it sounds like there was a lot of legacy code that didn't play well with Rails portion.
Would have been nice to read more about the mismatch points between Rails and legacy code. Was this a legacy DB structure that couldn't be loosely coupled to the Rails side, e.g., exposed as an internal REST service?
I also wonder if others can just as easily extend his code than if he had used a well-documented framework like Rails. In any case, it's impressive he rewrote the whole system (doesn't look like a small web app) in 2 months.
I haven't been on news.YC very long, so maybe that was mentioned as an issue a while ago. When Rails first came out, there was a paucity of documentation. The book "Agile Web Development" came out to meet the need. Now when I go into a bookstore or search through Amazon, I'm shocked by the number of books on Rails and Ruby. Truly amazing. Then there are the self-published outlets like peepcode.com, flexiblerails.com, etc. Rails and Ruby coders are also active bloggers and IRCers. The folks at Caboo.se, in particular, have been working on internals documentation. (http://www.caboo.se/documentation)
In the rails API docs (api.rubyonrails.org) next to each function you can click 'show source' to see what's going on under the hood. I hardly have to do this.
But when I do, it's usually just 5-20 lines of code that's not that complex to grok. (but you're right, not many comments inline) It would not be fun to try and decipher RoR internals as a new ruby programmer.
There's also the caboose edge API documentation. It's updated 3x per day from the most recent rails edge code and has all the private (#:nodoc) methods exposed:
The title's kind of misleading. It's not like the guy gave up on Rails, he even said that for future projects he would love to use Rails if it was designed for Rails for the ground up.
It sounds like he was trying to using Rails to retrofit on to an existing PHP DB schema, which is an obvious nightmare and probably a stupid idea in the first place.
Its really not as bad as you might guess. It takes some time up front to go through each model and tell it what the actual table name is, what the actual primary key is, and etc.
Once that is complete though, its pretty much Rails business as usual.
This might not be practical for all applications. But, in looking at CDBaby, I would find it hard to believe that their data is all that complex.
I think this article gets to the heart of the matter. Coding in Rails is much nicer. But PHP is still a very easy and capable language, and will continue to be the BEST language for large-scale Web Apps for many years to come IMHO.
Coding in another language like Ruby helps improve programming skills tremendously. But then it makes sense to apply those improved skills and learned design patterns to code PHP apps.
Neither you nor Derek Sivers has made a case for PHP being the best language for large-scale web apps. In fact, Sivers only makes one argument for PHP: it's "small and fast". The rest of his arguments are either against Rails or against switching platforms for part of a production system that still needs to integrate with the old platform.
Unsupported blanket statements don't contribute anything useful to the discussion.
Sorry you're right I didn't make any kind of a case. In making claims I prefer statistics to theoretical proofs. I would rather take a quick look at the statistics of large-scale web apps than make any kind of formalized argument about which is better: PHP or Ruby.
I don't have any numbers off hand(I will find some when I have some free time) but I would assume PHP has 10x more large scale websites than Rails.
That's case closed for me. Although Rails is nice and fun. But if I have to make a business decision today, its PHP all the way.
So your argument can be summarized as "I guess PHP is the best option"? That still sounds like an unsupported opinion.
Let's assume you're right, and that there are ten times as many "large scale" (whatever that means) websites running on PHP as Rails. That might mean that an equal number of people have tried building large scale websites using PHP and Rails, and that ten times as many failed using Rails as PHP. Do you think that's the case?
5 minutes of searching on Google fails to return any conclusive numbers, but PHP certainly seems to be several times more popular than Rails. PHP has also been around for 13 years, while Rails was first released to the public just three years ago. Both have been gaining popularity since their introduction, which suggests an explanation for the greater number of large scale PHP sites having nothing to do with the suitability of the tools: PHP has been around longer and has more users. If you want to measure like that, you should be programming in Java, not PHP.
The number of projects attempted and failed with a given toolset is a much better indication of its suitability than overall popularity. Even that can fail though. I suspect a greater proportion of Rails projects succeed than PHP, but I don't think Rails is the reason in a direct sense. I think the sort of people who choose Rails are more likely to succeed than those who choose PHP.
" I think the sort of people who choose Rails are more likely to succeed than those who choose PHP."
I'm sorry I don't quite get you here. Could you clarify this statement...cuz it sounds a hell alot like the elitist BS that is being peddled around by Rails fan boys as of late.
I had this crufty old php4 app that started gathering dust because it was so painful to touch.
The thought of rewriting all of it in ruby was just too painful, as well. (and not worth the effort) Like Derek's story, it wasn't just the customer-facing site but all of the little helper scripts, admin control panels and everything that were in PHP.
He used MVC and DRY practices not common in PHP but is still very possible(I know I use them). Very nice! I would give kudos to Martin Fowler's Active Record pattern which can be found in (phpclasses.org). Very nice library and easy to use as well. I'm willing to wager the author is taking advantage of PHP5.
He mentioned using a feature only available in PHP 5, so yes.
PHP definitely can be used in a reasonably professional way, you just won't get a lot of examples of it being used that way in books or in code you'll come across on the Internet, usually.
Probably most of the people who know how to use PHP as well as it can be used work at Yahoo.
Sadly that's true. There aren't many good examples of using PHP the professional way. That being said I can somewhat relate to the author(coming from PERL/PHP jumped to Rails and back to PHP). I loved the way Rails was constructed and how it approaches web app development not to mention. I definitely think most web development frameworks should take a page off it's book.
This is yet another article comparing a framework to a language. Aside from #2 and maybe #4, his points would be equally valid comparing Rails to Ruby without a framework. Only #4 is an argument against starting a new project using Ruby, and I think it's a bad one; programmer time is almost always orders of magnitude more valuable than machine time.
Edit: I took a look at the site in question. It's simple, fast and mostly well-designed, but the fact that it required 12k LOC and 2 months when he had the best possible functional spec (a working, but internally messy old version) doesn't give me much faith in his abilities or recommendations.
I've never tried rails. But I know that PHP can get messy, and if Rails does clean it up I wouldn't say that rails cant do anything that PHP cant. Because clean code is something that enables faster development (theoretically speaking) and more innovation. Of course, probably each has its own use. In some cases the scale gets unbalanced, it can happen.
