Unintentionally hilarious?

So, uhhh, is your rewrite done?

Good for you for sticking with what suits you. We sure have different tastes, but I'm glad you ultimately judged things by real-world metrics rather than religious convictions.

In my view, your love of SQL and your focus on your existing tables were the big barriers here. Writing a procedural system in an object-oriented framework is a poor match. Treating the database as the main focus, rather than an implementation detail is, from the Rails perspective, the wrong approach. And Rails is very opinionated software; it does its thing well, but if you want it to do something else, it's not a good match.

And I'd note that integration is only a problem if you're integrating components via the database. In effect, you've duplicated the schema everywhere, making it impossible to change. Integrate via APIs rather than your database, and integration isn't nearly as big a deal.

Your last comments seem to re-affirm the old cliche that PHP becomes ugly.

Doing something from scratch, in a one man team, after circling around the issues for two years, is a little different to working in a team with a new problem and needing a clean framework with (omg) Opinionated methodologies.

Your website looks like a spam site.

When i read "php is better than ruby", I had to laugh...

I wrote a lot of php code as well, and after 3 years, soon 4 years with ruby, I am 100% sure that ruby is a LOT better than php in EVERY aspect (i dont consider rails to be a part OF ruby), and I think your conclusion is WRONG in any way that PHP sucked because you "became a better programmer".

I will tell you the truth:
PHP as a language sucks.

I agree on one point... the domain language of php, the world wide web, should be solved BY ruby. All what is possible in php, should be possible with ruby as well. I hope matz decides to adopt this, because I am 100% sure that people will use ruby instead of php IF they can use ruby just the way they can use php (which means, no stupid mod_ruby errors for example)

I actually agree on one more point - hype is never good, what really matters is IF you work BETTER with these tools or not.

People, trust me - PHP is ugly, and will ALWAYS stay ugly. I have long ago jumped away from PHP. Only because rails doesnt fit your needs, doesnt mean Ruby as a language does not fit you!

Oh by the way, my comment was a little too aggressive.

I think I can agree that this should make the rails developers THINK about these issue and attempt to SOLVE (or easen) them, too. Because it seems like a rather legit reason and the arguments within it can be well voiced to improve rails...

It is also true that ruby *can* grow very complex, but it really matters on the programmer. Whenever possible, one should strive to pick the shortest, cleanest, easiest-on-the-brain solution instead of a "magical solution" (unless it is a very clean and clear human readable and nice to maintain DSL of course ;> )

It seems like starting from scratch in PHP is kind of similar to starting from scratch with Ruby and erb, which is what DDH did, right?

Useless post without a concrete illustration.

Show us an example of:
1) What you tried to accomplish.
2) How you tried to implement it in rails.
3) The rails code that "didn't work."
4) The "beautiful" PHP code you created instead.

I enjoyed the article, but now I'm sad I can no longer say "CDBaby does!" when someone asks me if anyone big is using Rails.

> William Pietri:
> In my view, your love of SQL and your focus on
> your existing tables were the big barriers here.

Bingo. Objects, their responsibilities and relationships first, database second (in Rails).

I loved the part about the database as an "implementation detail." That sings to me.

Taking an extreme stance to breaking down the problem domain yields the best results for me. Who keeps track of my appointments? My first answer was "me." Then I stood up and paced around the house for a bit. Upon sitting back down I wrote...

./script/generate model AppointmentBook

Break it down. Down. Down.

Looks like you among many out there had a poor team. Poor development environment where you were working on several projects at once and putting priorities in wrong order among several projects. I will have to say being stuck in one mental framework can be hard to overcome, especially when learning to code in a new and cleaner manner as per Ruby on Rails. But you actually could have coded so much more faster had you stuck to your guns and not given up, or not, since you prioritized among so many projects.

Know this: straight out the gate, even with little MySQL/SQL knowledge I know college grads that know and love Ruby on Rails that can code entire websites and admins in manner of weeks not to mention localization and advanced features like cacheing and advanced logging systems.

One important thing to learn from these guys and gals out there: they write tests alongside their code and think in that manner. All their code and program design fit together and they develop better code and projects because of that.

You are stating pure opinion without discussion anything substantial.

I agree with author, but i honestly see the point of posting it here. Take it elsewhere if you can.

This is a problem with any web framework. The idea of a framework is to make decisions for you, and if that doesn't work for you then it's the wrong framework. It's not a hit against Ruby in this case, just a hit against Rails.

coding entire websites that do nothing is exactly what rails is great at. Having been involved in framework development that had OOP inheritance layers 25 children deep and also in heavy utility development with few objects, there is no comparison.

Dont fault the author for liking SQL and its relative if not portable efficiency. The fact is it works and its way better than some pretend ORM like rails (ooh look johnny a WHERE clause builder!) which says well you cant do any joins that are meaningful to your application unless you pull it all back and iterate the old fashion way.

SQL allows you to let the database do the work. But as far as alot of RAILS or other ORM users are concerned, pulling back rows from individual tables and "joining" them in memory in a very inefficient way is somehow beneficial. Because they dont know how to leverage existing technology.

And thats what I liked about this article. Because it is true. Rails and ruby may cover for you for a while, but in the end you will have to do heavy lifting.

So your little login and your "oh I coded a website" and I dont know SQL and how databases work. Is a bunch of bullshit.

ORM and especially active record is fools gold for people who will never learn what it takes to actually get the job done.

But it is a good learning tool for people in a hurry.
Learning how to fail.

she: "When i read "php is better than ruby", I had to laugh..."

If you read that here, I think you need to adjust your browser.

And specifically to nick:
I know college grads...bla bla bla

Which is why we are outsourcing software development.
Because they dont know SQUAT.

Do you use memcache at all for any of the sql requests?

Yes Derek. I had quite the same experience. Tried rewriting a web app (PHP->Rails) for about 2 weeks. I gave up and started back in PHP, but the new code was a whole lot more methodical.

Why didn't you hire a Rails core member? Who is Jeremy Kemper? I have been programming in Ruby for 4 years now and I have never heard of him. I think you need to reconsider who you hire next time to do things the Rails way.

well personally it just sounded like you picked the wrong project; rails is opinionated and expects things to work certain ways, as you noted, and if your project is written entirely different then this - guess what, rails might not be the best choice. In your case it sounds like php definitely was the better choice.

It would be interesting to see, if you pick rails for a future new project if things would be different, and, two years down the road after many enhancements and changes, which codebase is more manageable, and should you have to recruit others for help, which they find easier to work with.

Just few things Rails != Ruby. Ruby was there long before Rails, and it was and still is one of the easier scripting languages. Howerver PHP means currently having a broader base. And a lot of experiences. I just can tell that the PHP pages I had were relatively messed up. If one really likes to know I can check the old pages (there we have used PHP, HTML (of cource;-) Apache and Mysql. I do not like MySQL for whatever reason and so I replaces it with PostgreSQL. We are also usign a Ruby based wiki but are still using PHPBB. It works has just one really big drawback. It get's spammed with subscriptions. So it seems because it is that popular the captcha was somehow cracked. This makes me angry. I would like to fix that but the code from PHPBB is not for the faint of heart. Howerver I'm not keen on check my braveness on it...

But some other things to consider:
Webprogramming does not stop with PHP or Ruby. There are so many alternatives. You have choosen what you knew. But what would happen if you had tried something else? Here are some ideas:
1) OpenACS http://openacs.org/
2) Seaside http://www.seaside.st/
3) Some lisp based stuff AllegroServe, Hutchentoot etc
4) Some scheme based stuff
5) Erlang stuff
6) Objective-C
7) Java
8) Perl
9) Python
and so on .....

I've tried so long:
php stuff (serious)
lisp stuff (very serious but with very less success)
openacs (just had a look)
rails (has saved me from spending another few months on the lisp stuff)

I for my part are quite happy about rails. Maybe it's it's model that suits me that good...

Regards
Friedrich

Judging from the article what you tried to do was to rewrite your old PHP code to Ruby on Rails 1 to 1.
This is the wrong way to go. Rails (and any framework in general) has some constrains you have to adopt to, and you break those only if you are *absolutely* sure there is no way to accomplish what you want within those constrains, which more often that not means that you have to change your perception of the problem - not the code.

Now, this is some experience I would really like to buy a book of. The language of my company is PHP and it's very unlikely that there will be a switch. I don't see a very compelling reason as well.
But I have been looking for a book of somebody with a 'puristic' mind that has found a way of working with PHP. I found none, perhaps I was not looking good enough but the books were either 'PHP 101' or 'let's create a big ball of mud'.
I hope you will write more about that experience you have.

I was thinking... before you have the book written ;) could you post some code examples of all coding rules you imposed upon yourself?

Gee, I'd like to see those rule examples Cornelius asked about as well....

Haha at the Rail Kiddies...

I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.

Thanks for the funny comments.

To Richard Hertz and Cornelius, and others asking for more concrete examples: maybe some day.

I finished the rewrite a month ago, and it's taken me a month to find the two hours it took to write this post, which I did for the benefit of an invisible someone someday.

To show in examples what I love about my new PHP code would take hours and hours more, and I might do it some day, but I've got years' worth of things that are more important for me to do, first. Maybe some day I'll just put it all up on a public svn server, but I'm not ready for that yet.

Also, when considering it, I thought my specific code that made me happy probably wouldn't make you happy. I just designed a little system for my tastes, and that's the point.

I came on toward the end of the project, so I can't too much credit, but yellowpages.com was rewritten in Rails in four months. That's four months from the first subversion commit to deployment in production. That was with a team of five or so, learning as they went along, with the typical business-person meddling of a mega-corporation. That includes writing a service layer that interfaces with a brand new ruby FAST library. That includes load testing and realizing you need to use mongrel handlers in a few key places.

Bob, Rails is not just ActiveRecord. Our heavy lifting is done on a service layer. Rest assured, it blasts SQL away. Bob, how many millions of hits a day does your site get?

Well in a way you are right. Trying to make Rails work the way they are not supposed to is really a hard task to accomplish. Its crazy to even go that way. Really crazy.

Saying that it is better to use bare PHP and custom made templating system (isnt PHP a "clever template" after all?) is better than starting with Ruby and ERB is pure nonsence to me. Ruby is much better language (pure OOP in Ruby vs hacked in OOP in PHP) but has some downsides in deployment. Integration is not an issue when using REST and Webservices, but i guess that would be too hard to implement in PHP ;-)

Reading your reason #6, I see that you totally don't get what rails is.
And thats pretty sad as a resumee after 2 years.

PHP is a better PHP than Ruby (and Rails) ;-)

I saw it coming when you wrote "Jeremy ... twisting the deep inner guts of Rails to make it do things it was never intended to do".

Good post Derek. Don't let the Insane Rails Posse get you down. Your approach is refreshing. Actually build exactly what you need instead of buying into that whole Rovian "it's opinionated and only works if you kiss its ass approach and if it's not working because you're doing it wrong" talking points brief.

Look, if something was really good you all wouldn't have to work so hard to defend it. It just might be possible to develop software using something else.

> yellowpages.com

Wow, you and your posse made a site with links that lets you search. And you did that in 4 months with 5 people? Respect. I just can't imagine doing that so fast any other way.

The problems with PHP run much deeper than just your cosing style.
* PHP handles integers wrong on 64-bit platforms.
* Its namespace is polluted to a point that makes working with libraries a major pain.
* Its identity and type coaxing system makes it easy to produce security flaws.
* Its OO-model doesn't allow inspection which makes working with ORM like Propel or eZPublish's PersistentObject a real problem of XML/YML configuration or lots of custom coding

A problem that both have is that their Unicode-handling sucks big time (which is why I would have argued in favor of Django/Python, they're at least getting there)

Maintenance-wise you'll almost always be much better off with Django, Tapestry or Rails. Especially since your maintenance-phase will almost always be about 4-10 times as long as your development-phase.

And as both Ruby and PHP are Turing-complete there's nothing that can't be done with each of them (except implementing 64-bit integer handling in less than 80 lines of code in PHP), including implementing each other.

cheers

I agree with most of the things you said about PHP not being good. But, as far as your project is concerned, it failed because of *your* lack of planning and vision. Hell, anyone could have re-written that site in JSP/mod_perl/whatever in 15 months.

Even trying to relate that with rails and use it as a point of difference between rails and php, is totally lame. Once again, rails didn't fail you. You failed yourself.

i like your site, minimalist, pure techie site.

However you can do better.

I agree to your point about php and R&R...

R&R 's too simple, that's exactly what kills it, it will never make it to the top.

php - your house wife, it WORKs for you, however ugly
R&R - your beautiful one-night-stand, however you can have 20 of them each year

I can say it right here: any language that requires too much brain power, absolutely and definitely WILL NOT make it to the top.

WHY? No managers likes thinking too much, unless the efficiency really is important.

My ability of being able to "Get on with it" while you are still tweaking your R&R code, is PRICELESS - why?? because I grabbed 2/3 of your customer before you laugh your site!!

To be WINNING in this world you had to take risks, if you haven't been investing 180~190% of the all you've got[startup $$], and talk to 1000+ of your potential customers, your project would most likely to fail -
NOT because your code or service is BAD, but because you spend just a bit of time TWEAKING on computers when you should be communicating with someone else...

Remember: business is always business, you are selling a service,
if you are only an employee, who take proud of the clever code and admiring comments from colleagues, then you WILL always be an employee.

Take risks, work hard, COMMUNICATE, and HAVE FUN.
You will find your millions or billions[with luck+ lawyer/acc friend].

@jason
yeah, I thought that too! LOL
woot a holy crap website! :/

Memcache? Fragment caching? Cap deployments onto a tuned set of mongrel servers? nginx front-end dispatcher?

Did you or your rails "expert" do any of these things?

We have use rails to develop an enterprise software system which is now in production with a number of clients, so I am speaking from first-hand experience here.

The Ruby interpreter is currently slow and will hopefully improve over time. But there is no reason why a site that can't be written in 2 years can be written by YOU in a month using PHP. By your own argument, "when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."

So what the hell was the problem?

Oh and I just checked out your site. What an ugly P.O.S!

2 years and you can't build craigslist for CD's using rails. Jesus.

And for those idiotic rails evangelists who don't know a shit about rails - check http://rubyonrails.com/core and if you ever saw changelog of rails, you wouldn't be being a moron here.

You're not alone. Although my site doesn't have the exposure yours has, I went through the exact same thing only I had been using ASP.Net. Not to pat my own back, but I'm pretty good with ASP.Net and SQL. Fortunately, it occurred to me about 4 months in.

Wow, if you liked PHP for those reasons, you should REALLY try ASP.NET (don't worry, you can run it on Mono if you blindly-hate Microsoft like most other people on O'Reilly).

It seems to be we have two types of commentors; those who understand where you are coming from (even if they disagree) and the pre-pubescent fan-boys you'd only expect to see with something like Nintendo, Sony or Halo.

The one thing I've noticed working on several rails projects is this: If you're starting on a new project, fresh and clean, no existing database, you can't beat rails. However, if you're trying to migrate an existing project to rails, more specifically, have a database that rails must be laid on top of, it gets a LOT more difficult.

Just my experiences there,

G

cdbaby.com is comprised of over 100k lines of sourcecode?... terrible... you certainly are one wasteful, beat-around-the-bush lengthy programmer, as the americans usually are.

If you need 100,000 lines of code to provide what cdbaby.com does and is, I wouldn't want to hire you in a lifetime.

I too love SQL, and dislike abstractions that take the power away from you.

I'm coming from a Java perspective here, rather than a PHP perspective, but I will not use database interface engines like JDO which turn 1 clear concise line of SQL (stuck into a prepared statement) into 10 messy method calls to do the same things, with a horde of behaviours that aren't what I want it to do. Spending months fighting and bypassing JDO's issues was a nightmare, and I will never do it again. Writing some DAOs with PreparedStatements took a tenth of the time, far less code, and is far more maintainable by someone who knows Java, but doesn't have JDO experience.

That said, things like Struts and Tiles - lightweight frameworks that make your work easier without limiting the power available to you - are good. Indeed Tomcat itself is a framework for writing a webserver that takes all the webserver grunt away leaving you to just write the logic.

What I don't understand is why you didn't drop the limiting framework - Rails - and just stick with Ruby. I don't know Ruby, but Rails must be built upon libraries for database use, etc, that you can access yourself, write your own SQL statements, do things the correct way, in a language you admit you like?

On the other hand, when you need to do something quickly, it is far better to do it using mechanisms you know and understand.

I've had the exact opposite experience, but i won't turn this into a PHP vs the world thing. Our sites handle tens of thousands of users per day and we have some extremely elaborate things going on. There have been extreme challenges, as with any other language, but we have figured out good ways to handle every obstacle with Ruby. We've even built our own distributed ruby application to handle the heavy lifting pieces, which has worked great.

Anyway, to your... arguments?

1. "But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."
So you're saying that end the end you went back to the language you were most comfortable with, not that Rails couldn't handle your app, right?

2. The One Big Day switch doesn't work. We have tried it before, and you end up getting a flood of repeated questions and you end up confusing a lot of people. The best way to do this is to prioritize the intranet pieces and website pieces and switch sites an intranet apps one at a time. We have 30 intranet apps being used by a few hundred people... We held big meetings to say, "hey, this is going to change and this is what we imagine it will look like." A few months later, their pieces started changing and they were (mostly) prepared. But, doing it in pieces allowed us to re-evaluate how each project was being used and make improvements, where your One Big Day approach limits you to trying to build it to function as it did before as quickly as possible.

3. Yeah... there's a lot of crap in Rails. A lot of plugins and libraries that never get used, and there are several libs that are just too unstable for real use. It would help if they cleaned up the docs and API a bit. This is a problem :(

4. Small & fast... you mean Rails, right? It's easy enough to set up a mongrel cluster with Apache proxy balancing that your 2U LAMP server should've been able to handle most anything.

5. Rails lets you do exactly the same thing.

6. I think those who use the object associations directly in Rails are doomed to failure. You can't just do someobj.otherthings and expect it to be optimized in any way. You can do direct SQL in rails, but what I like to do is: someobj.otherthings.find(:all, :conditions => "otherkey='asdf'", :select => "the, fields, I, want"). I adjusted all of our queries to be limited to only getting what I want and it improved performance significantly... especially in cases where I'm sorting after-the-fact through hashes of arrays and whatnot.

7. I kindof see where you're going with this, and agree that any exposure to a new language is a growing experience.

What I'd like to see are specific examples of what you couldn't do with Rails or what exactly made it more difficult. Without specific examples, I have to say, your post just sounds like a PHP fanboy that gave Rails a try, did learn some interesting stuff, but went back to what he was already more comfortable with. I suppose there's nothing wrong with that in itself. The ridiculously misleading and idiotic summary on slashdot of your post:

"Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project"

Now that I've actually read the article, it is obvious you didn't mean your post as flamebait, but you are lacking specific examples of how Rails didn't meet your needs.

I've suspected this about application stacks for a while. Perhaps there's a theorem somewhere that states "The more 'intuitive' a framework is the less potentially useful it will be for anyone other than the original authors"

I've had projects in C# where I would swear that I could do it better in Python in half the time, and other projects where I felt the converse. Same thing with J2ee vs ASP.net etc etc etc etc ad nauseum. It depends on the problem domain. It seems the rails posse is so damn blind with their undying love for their framework, that they just can't accept that it may not be useful in solving some problem they never thought of.Sort of like those people who use a 1 button mouse and can't accept that some(most really) just feel more productive with 2 or even 3 buttons on their mice.

The original poster IS THE DOMAIN EXPERT here. Founding an independent music company that has been able to survive this long in a sea with only 4 really really greedy BIG FISH is a testament to that.

Ever heard of Incremental System Replacement?
You're on the Web! You can replace the implementation page by page without anyone knowing what's going on under the hood!

Ever heard of Incremental System Replacement? Agile Software Development?
You're on the Web! You can replace the implementation page by page without anyone knowing what's going on under the hood!

I don't care. Rails is all about beautiful code to me. Code PHP all you want, I'll stick to rails.

Looks like everyone missed the basic take-away in this post: in the end, there's no real benefit to doing a scorched earth re-write of a working system.

All posturing aside, technology A will have advantages over technology B, and technology B will have advantages over technology A. The more important point is that a re-write will take at least as long as the original implementation, and, at the end, if you're very lucky, you'll have a system that can do what you already had at the start of the project. With a two year re-write, you'll have a two-year-old system. Or, worse yet, and more likely, you've continued to enhance the existing system at the same time, and may or may not be reflecting those enhancements in the new system.

You're much better off refactoring and improving an existing system than grabbing the latest silver bullet.

This is an excerpt of an email I sent regarding this very interesting article.

He writes that he was inspired by Ruby, and after it failed to meet his needs, he realized he was looking at PHP as a crappy language, when the reality was that he was such a better programmer than when it was written, and how he made a mistake thinking he needed to switch from PHP to Ruby, when all he needed to do was clean up his old code he wrote when he knew so much less.

I enjoy programming in C#, but I wonder what we might be getting into. I wonder, if C# is better, or if it looks better just because it an attempt to prevent us from making the mistakes we might be tempted to do if we don't think about our code. (To the reader:I'm not dismissing C# but just wondering if we are biting off more than we need with a language switch instead of a self-disciplined clean up.)

So then the question follows .. Can a programing language prevent sloppy code? The obvious answer is no.

Damn, but Rails sucks. I'd rather program in interpretive BASIC.

Just realized this post was on Slashdot, with a summary that got the point entirely wrong.

I never said "the project was cancelled because of limitations of Rails" - more like I spent two years trying to make Rails do something it wasn't meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

That's all.

Still, have fun flaming. It's funny.

Seriouzly why didnt you look at Java?
Java is really OO, it is a nice language, and the web playform is superb, J2EE is really powerfull but you may not need everything..

>> He writes that he was inspired by Ruby, and after it failed to meet his needs, he realized he was looking at PHP as a crappy language, when the reality was that he was such a better programmer than when it was written, and how he made a mistake thinking he needed to switch from PHP to Ruby, when all he needed to do was clean up his old code he wrote when he knew so much less.
GarryFre : THANK YOU. That is a much more succinct and accurate way of putting it!

TJerk: > Seriouzly why didnt you look at Java?

The whole point was that ALL of our existing code was in PHP, and in order to transition over to new code, sticking in PHP made things 1000 times easier on everyone.

If our old code was in Java, I would have looked at staying in Java.

>> cdbaby.com is comprised of over 100k lines of sourcecode?... terrible

No - our entire operation, managing digital distribution to 150 outlets like iTunes, international credit card sales and merchandising, accounting and weekly payments to 200,000 musicians with transparent accounting, a 50-person warehousing and shipping system that sends and receives thousands of boxes a day, a members login area that lets them administer our site, set their digital rights, see all accounting, our entire customer service intranet, and digital rights management in-house...

... THAT is what's in 12,000 (down from 90,000) lines of PHP. RTFA. Ppbbbbt. Neener neener. :-)

If you were trying to do a complete re-write and did not include the database layer then you were headed for disaster from the start. Your approach should have been a full re-write (including the database schema). And since you would be migrating an existing system, one of the requirements would be to write the data migration program from the old shcema to the new one. It shouldn't have been such a monumental task unless you were trying to keep too much of the old. You would have had more headaches in data migration but that's all. I think this has less to do with the technologies involved and more to do with the approach you took for the re-write. But this is how you learn and now you have long list of things that you know for a fact that will not work. That's called experience and it's invaluable in this business.

You should have tried the Catalyst framework for Perl which gives you the shortcuts and structure of Rails combined with much more freedom. Yeah, I'm already hearing "Perl's dead" shouts ... But I don't care as long as it gets the job done :) And with Catalyst web dev has never been more fun and productive. And DBIC is one hell of an ORM - lightyears ahead of the ActiveRecord stuff Rails has to offer.

PHP is a super slow language that not even ruby can beat for performance.

I've got similar reasons for not using rails. My alternative is something other than PHP, but I know the feeling.

We've many languages and many frameworks for differents problems. You need look for a better for your problem.
I love ruby, python, rails, turbo gears but i still can't use them in my work, because this aren't the better to resolve the problem.

Coming from the same place as you -- a legacy php app that does what I want -- I considered a re-write. To test the supposed power of the MVC and automated object-relational mapping, I wrote a small application in Django. In doing so, the most frustrating part of the exercise was ORM. I spent a lot of time trying to figure out how to make Django's database classes do what's easy (for me) in SQL. #6 is wisdom for anyone who's already comfortable with SQL, which, btw, isn't that hard.

I looked at cdbaby.com just now. It's a shitty site. It's got a little shopping cart and catalog and from Derek's later comments a few small back end pieces. Clearly not a big deal. It's great that Derek learned some things about pretty code and software development. Getting a degree in computer science could have probably helped him realize a lot of the mistakes he made before made them. Rails is crap but for crap it's one of the better craps out there. You can do the same thing in PHP, the language doesn't matter hugely (well, not really true, ruby is pretty, has flaws but is pretty). Joel has an interesting article on rewrites, you should read it

http://www.joelonsoftware.com/printerFriendly/articles/fog0000000069.html

So many comments and not a single one to point the Zend Framework for PHP5?

I'm a developer with 12 years experience, 7 years of PHP, and I can't code without it anymore. It just takes care of so many rudimentary tasks. Provides MVC, DB abstraction (you can still write your own SQL), Zend_View (templates that makes sense, unlike Smarty), offers classes for almost anything and everything, and it's extremely well thought out. It's quite beautiful because it's so light-weight.

Now, I don't want to come across as some kind of rails hater, because I certainly am not. I'm having a really hard time believing that RoR is to blame for the project failure. I've seen people drag tush with PHP projects as well. And often that's because the developer spends time and time beautifying their code. They add comments, make sure everything is indented, look at the same file over and over and try to figure out whether there isn't another design pattern or three that they can refactor their code with. They simply worry too much about the code rather than the project as a whole and the user (who never sees the code) experience.

Bottom line for me is: Use the best tool for the job that you're familiar with. For me that's PHP+ZFW, because I know it. For a few developers on another team in our company it's RoR.

Derek, I must admit I admire your courage posting this on the Ruby site. :)

I think one thing you might consider is that Rails just wasn't right for your organization. Like most frameworks, they just don't scale to larger sites with "outside of the box" goals and legacy integration. I've worked on a number of larger sites likes yours, and I've seen the mess that occurs when you have to patch a framework to "get things done". Which is exactly what you would have ended up doing in rails (if you hadn't done this already).

Also, too often debugging the baby, you end up debugging the bathwater with frameworks. I've found myself knee-deep in activerecord trying to figure out why my foreign keys are giving the library hives, amongst a million other things. Mason (perl) is no better... It's just more mature.

I think Rails is sexy, and a great idea, it's just not mature enough for large sites and/or development teams just yet. I'll stick with using Ruby for damn near everything else, and mod_perl 2 for serious web work.

Well now, you did become a better programmer due to rails :)

PHP is web centric and generic, rails is a framework, and ruby is a generic language.

The problem is abstraction, we have got to a level now where more abstraction is actually more problematic:

Machine code:
surely it is better to abstract all this lever pulling

Assembler:
still at the coal face but at least I can write about it

Compiled:
phew out of manipulating the system directly

Interpreted:
ok got a nice environment going to suck in the overhead and
most business applications can be done

Frameworks:
hold on I am in someone else's house, wearing their clothes
and trying to get to grips with their VCR

It is the frameworks that show less of a return in development lifecycle up the chain, if you will.

Your own personal framework is great - but getting use to another's framework is problematic, their abstraction does not meet with yours.

To make an analogy a framework is like an abridged version of a great novel.
Sure you will get the gist but a lot of nuance will be missed along the way.

With ruby the rails framework may very well be getting in the way, but it does offer a fast way to produce websites if you keep to its rules as you have discovered.

A ruby site based of a ruby application server using a ruby style templating system is probably what you are after.

The setup of web server, application server, template engine is the one most websites benefit from - and yeah sure the database can be accessed via stored procedures and views for the main part, which you roll.

So yeah frameworks are great if you make them, it is very hard to be generic with them though as they are one level to high.

Well now, you did become a better programmer due to rails :)

PHP is web centric and generic, rails is a framework, and ruby is a generic language.

The problem is abstraction, we have got to a level now where more abstraction is actually more problematic:

Machine code:
surely it is better to abstract all this lever pulling

Assembler:
still at the coal face but at least I can write about it

Compiled:
phew out of manipulating the system directly

Interpreted:
ok got a nice environment going to suck in the overhead and
most business applications can be done

Frameworks:
hold on I am in someone else's house, wearing their clothes
and trying to get to grips with their VCR

It is the frameworks that show less of a return in development lifecycle up the chain, if you will.

Your own personal framework is great - but getting use to another's framework is problematic, their abstraction does not meet with yours.

To make an analogy a framework is like an abridged version of a great novel.
Sure you will get the gist but a lot of nuance will be missed along the way.

With ruby the rails framework may very well be getting in the way, but it does offer a fast way to produce websites if you keep to its rules as you have discovered.

A ruby site based of a ruby application server using a ruby style templating system is probably what you are after.

The setup of web server, application server, template engine is the one most websites benefit from - and yeah sure the database can be accessed via stored procedures and views for the main part, which you roll.

So yeah frameworks are great if you make them, it is very hard to be generic with them though as they are one level too high.

I worked at a place briefly that had a similar storefront/backend written in php. They decided to rewrite it in Java and hired Java folks. Three years later still no store. Sometimes it's best to stick with what works for you. Especially if your business depends totally on the result.

I love and use C. Not C++ or Obj-C or C# or Java ... but C. I produce web applications in record time and they are insanely fast. For data, I use the file system with a simple distribute cache. You see, MySQL won't scale and once you get any real traffic, your site dies. If you 10,000+ requests/second, use C.

Couldn't have said it better myself, i'v tried learning many languages over the years, and really, I always come back to PHP... yes it's a lot because I know it inside-out however at the same time it is also because it is easy to work with and you can still create clean code and very little of it to do a lot if you think things through and use OOP properly. This is about to be flamewar central however you have my vote on everything you mentioned above!

Aaron,

A little research would go a long way in making you *not* look so foolish. In the article he gives you Jeremy Kemper's online alias, bitsweat. Anyone who's looked at more than a couple of changesets in the Rails repository would instantly recognize the name. And, yeah, he is a core team member. You seem to have missed the point of the entire post. Use the tool that works for you. For some people it's Rails, for some people it's PHP. At the end of the day what matters is that you get the job done.

Haha. The CD Baby website kicks ass.

It works, it makes it easy to navigate through the thousands of albums they have. They have reviews. It's nice, simple, and easy to use.

Plus it does not suck up my computer's resources with javascript hell like most 'Web 2.0' websites do (big example: Digg.com is absolutely horrible design). Plus it's very handicap accessable, which Web 2.0-style sites totally fuck up at.

Plus it's not flash-site hell. Most 'web 2.0'-sites that manage to avoid javascript hell the run headlong into flash hell.

No flash-based little bars to play music or other nonsense I have to go through. Just hit 'listen broadband' button and I get a m3u file that opens right up into Totem player.

That's nice.

The only change I could recommend is to hire a artist, a real artist in the visual arts and not some javascript or website hacker, (preferably somebody with very little knowledge in any markup or scripting language that does art with real materials) to make a design for the the first page more sophisticated looking. (no aninations/columns/blogs or any such nonsense)

I don't know if it's true or not. But the general impression of the comments on this page reek of snobbishness.

And I don't remember for certain, but I once heard a very good developer say:
"Objected languages can end up a crutch for people who can't think in a object oriented manner".

That is C or PHP or anything else can take advantage of code reuse and objects as well as C++ or Java or anything else. It just requires more skill and ingenuity then it would otherwise normally take.

The only real thing I dislike, as far as PHP goes, is the security record, which is something that Apache suffers from also (compared to competitors like IIS6).

For PHP/Perl/Python/Ruby and Apache to recover ground it's lost to Microsoft it's going to take a lot more obviously (as in from the view of people outside these projects) focused effort on ease of use and security then what is going on right now.

Oh, well.

I agree almost at all...

But:

#3 I don't want what I don't need? hey but with PHP you get the same million of functions in every scope you don't need them but whether you like it or not.

I think that the problems of PHP programmers is that they need a strict teacher, that show them the right way to do the job.

The last thing: You should really try Django, is a good teacher that let you write SQL if you want :)

Rewriting any significant system (even in the same language), especially one in production, is difficult. I have seen Mr. Sever's ads looking for "Ruby Rock Stars" - rock stars are good for boosting attendance at conferences, generating traffic to a blog post, and influencing people. They are not the right resource for a major rewrite. The right resource (say someone with 10-20 years of experience) would most likely have come in looked at your operation and code and broke the news to you gently that trying to rewrite your entire system was a bad idea.

Derek's experience is more of a commentary on how hard it is to manage technology rather than anything inherent to Ruby/Rails or PHP. I also think he does not want to admit that he was lacking in this area and has chosen to blame his tools. "This damn hammer is no good - always crushing my thumb!."

The 7 points are silly and call into question his knowledge of programming and Rails in specific.

Take Item #6 "I love SQL" Does Derek really love those "create table .. " statements so much that he can't live without managing them directly? Migrations are intended to wrap DDL and in any case migrations are optional and there no config files to edit to turn them off - just stop typing "rake db:migrate" If Derek really wanted to express his love for SQL I would think ActiveRecord would have been the more appropriate target - but even in this case , nothing prevents you from using raw SQL to get at your database.

I think Derek needs to "man up" and just admit he fucked up, not his tools.

Mr. Sivers - thank you for your informative comments, but could you please give us an example or a sense of (from a previous post by Richard Hertz):
1) What you tried to accomplish.
2) How you tried to implement it in rails.
3) The rails code that "didn't work."
4) The "beautiful" PHP code you created instead.

If it took you two years to determine its inadequacy, I would suggest you use more direct and efficient evaluation techniques. I can't imagine taking two years to find out that a particular language was unsuitable for a project. How could you have neglected to do the investigation necessary to make the same determination in a month?

Outstanding article. Not an attack on anything, just a path to better programming. Understand what you need, do not fear SQL, use TDD and DRY to minimize your code, develop your own tiny, specialized frameworks, then finish and get on to the next thing. Brilliant.

Thanks for the update! I wondered what happened to your rewrite project (especially while weighing PHP vs. Ruby).

What happened with PostgreSQL? Or did you stick with MySQL, too?

I'm not entirely sure I understand the article's objective, but I'm glad you feel you learned something. End of day you just needed to rethink your app and clean up your code, but you spent 2 years diddling around?

A couple of things popped into my head as I read this:

* You didn't invest the appropriate amount of time or effort in learning the relative benefits of one language or framework vs. another prior to embarking "whole hog" on a rewrite. What were the real reasons for attempting to migrate to Ruby? Did you do small test cases based on your real world problems with the existing application?

* You seemed to succumb to "fad" thinking on this where you (as you noted) really needed to approach the project objectively. I'd be very careful exposing this kind of thinking if you're looking for funding or clients.

* You went with your old stand-by. I agree completely with the idea that you don't make radical technology changes unless you consider how you're going to support your business applications. Most expense in a project like this will come from support. Retraining is also not just limited to the language - now the entire team needs to pick up your complete rewrite and learn how to maintain your approach.

* Personally, I don't much care for the way a LOT of ASP, PHP, etc. script-type applications are written because they turn into "spaghetti code presentation/business logic in same code block" nightmares. It's cool that you went back and tore things apart to get away from this kind of mess. Playing with another technology or design approach will always make you stronger and some times it will make you appreciate your existing tool set. If you haven't already, definitely play with JSF or some of the more recent .NET stuff. A lot of good ideas in there you might want to work into your PHP apps. I really, really dig the way data binding works in repeatable items, tables, etc. Validator separation from input component are another really fun one.

Very fascinating and informative. Thanks for the write up.

Altough the site design is not the best, cdbaby.com has an enviable position in the Alexa index (8,355).
Not far from the rubyonrails.org ranking (7,820).
What do oyou think right now?

Don't quit your day job.

I believe it's chef's choice. Some believe and use Rails. While others evangelize PHP. To me, Boolean Algebra is Boolean Algebra no matter how you express it. Of course, I'm a LISP bigot. I enjoy both Rails and PHP as well as Python and Java.

All the best,

:D

Mike

you should definitely check out CodeIgniter, which solves a lot of boot stuff and MVC related structure.

So basically what you're saying is that you bought into the hype rather than making an educated decision and picked the wrong tool for the job? Is that your failing or the frameworks'?

> Is that your failing or the frameworks'?

Mine, as I said throughout.

This blog post is only here because some people asked why I didn't use Rails after all.

My reason is, "Because I realized any language will do just fine, and the one we already have is most convenient for us."

That's all.

I said clearly in the post that I love Rails and my decision to switch was (both directions) was just personal preference, and in the end: compatibility.

If you love Rails, why don't you try using CakePHP, it dominates and it's worth while. You can right beautiful PHP code in seconds.

About point 5: Rails is a framework, PHP is language, don't compare (Oh my
God, this is a nuby comparation).

About point 7:
I can say so, Ruby sucks because you sucks. "Give yourself some credit".

Please spend more time in "think" how to explain and compare in a right way.

Next step in your evolution as a developer: The realization that PHP is antiquated and actually a pretty crappy way of developing web applications.

Agree 100%

This is an interesting perspective but seems to lack substance. Your seven reasons would be much better if you used actual code examples instead of girlfriends. And you know, I think a better title for this blog piece might be "Several Reason Why My Large Web Project Bogged Down"

This was a well thought out decision. Now you can run on IIS6 or IIS7 and reap the full benefits of using Windows Server as your platform. You may want to look into Silverlight to give your PHP sites some life.

--- Jake

"cdbaby.com is comprised of over 100k lines of sourcecode?... terrible... you certainly are one wasteful, beat-around-the-bush lengthy programmer, as the americans usually are."

U silly americans. haw haw haw (snooty french laugh)

You should have tried X framework for the Y pet language which gives you the shortcuts and structure of Rails combined with much more freedom. Yeah, I'm already hearing "Y's dead" shouts ... But I don't care as long as it gets the job done :) And with X, web dev has never been more fun and productive.

Derek

Have you considered doing the rewrite in Java? The EJB frameworks would have helped take care of the object relational mappings. I doubt there is a true rival in the lamp wold on that. As far as MVC you could have used Java server faces (JSF) technology to separate the UI from the business logic. All this technology is standard java so you would be able to find maintainers it for years to come.

waaahh..
So many rail-babies whining
Seems to me Ruby is an elegent little gem of a thing..
Rails felt creepy, hiding too much.. I didn't stay on very long. I don't like shooters-on-rails, either, in the gamer world.. Some of us like some freedom, and this guy just didn't realize what he'd be missing.. so what?
You all sound like the metaphorical g/f he might have left after 2y.. stops ye bitchin'

you need a UX guy

Derek's diatribe is not about code but about thought process. He prefers an imparitive thought process to a declarative one.
His rails project failed because he could not get past himself or his level of incompetent convention. This is so common.

This was so full of logical fallacies that I thought it was intended as humor. Sadly, I was wrong.

thanks god, at least you could complete your site.

it would be nice, if you can better explain your use cases, where you had stucked with rails and ruby. so we can understand what you really wanted to mean.

I need to say this... those rails-hype-emo-kids are pushing people away from (excelent) Rails. The guy who want rewrite all php-web on rails makes me laugh a lot.

I followed a similar route as yourself. Learned a lot from Ruby on Rails (especially the MVC structure) and am now applying it to my PHP projects at Ning.com.

You should check out Phalanger ( http://www.php-compiler.net/doku.php ). ;)

Thanks for bringing this up now. You've saved me a lot of future headaches. I wrote an application in php that I was going to totally redo in rails. I actually bought an excellent book - 'Agile Web Development with Rails' so I can learn this stuff.

Even though some things look super easy and are super easy and quick with rails, for serious operability and true agility, I don't see rails fitting this bill. An early warning came when I flipped to the last chapters about deploying your site. (php think: 'just upload, right?') Here is an actual quote from the book:

"In contrast with how easy it is to create a Rails application, deploying that application can be tricky, irritating, and sometimes downright infuriating."

And then I tried to put a simple little thing online and gave up.

PHP, please forgive me. I never realized how kind to me you really are. And when I upload your directory, it doesn't come with...(I just started an ftp app to see how big the do nothing so far rails folder is, and after waiting a full minute for the properties I switched back here to write this)...(sorry, it's still loading.)

OK, it's done - 5.31MB, 490 files, 173 folders - this includes a large documents directory that is generated apparently for every single app you make, unless I can figure out how to stop that from happening.

I still want to try Ruby, but the sermon about how fast and easy things can become has taken about 2 months of occasional reading to get nowhere.

My guess is this - Once you learn all about it, it probably is quick and easy to make a new app. But I'm afraid the ease will never have time to come for me.

...and the document directory is 4.9 megs of that total.

So I never should have switched from tango to PHP?

Hi Derek!
Great article! Curiously, I just took a look at CDBaby yesterday and was impressed by its sleekness in both design and function. And it's FAST! Which is one of the things I liked most about PHP. I'm not a SQL person, really, and mainly find ActiveRecord a boon. I have done some Rails and some PHP, now using Monorail and I don't think I could make a web app without MVC now. I'd like to see more details about what you did, because MVC in PHP sounds like a good combination of pragmatism and structural programming.

Chris

PS. You should probably move the Add Comment box to the end of the comments.

Great insight, I'm still interested in RAILS but for experimenting with not actually using to develop with.

Every language has its own pro and cons. For people that are familiar with rails, they might think its a total crap. Sometimes too automated process makes people more dumb. Tell you frankly, i dunno why i juz can't understand ASP .NET. But im doing pretty well in PHP. I wrote my system in OOP using PHP4. It works juz fine and its also compatible with PHP5.

Nice entry. As it happens I wanted to start a rails rewrite of our PHP code a few months back, but the PHP code was written for a rails-esque PHP framework called CakePHP. I was just constantly running up against the limitations of CakePHP and got sick of it. We decided in the end to hack around the things missing from Cake (specifically I really missed my precious precious has_many :through) and bear with it for now. A proper rails rewrite has been in the works, but hasn't begun yet. Now I question whether or not it's really feasible. All of our new projects, naturally, are written in rails with a rails mindset and those deploy beautifully.

Thanks for a good post!

Wow. I can't believe the flames here. People are flaming this guy for being incompetent. Maybe he is, I don't know him. Why the religious devotion to rails? RoR is wonderful to develop in. Fast and easy. But (as the devs are happy to admit) it is not for everything. Rewriting anything that is in PHP in RoR is kind pointless, because things like "beauty" aren't that important. You can get the job done just as well in PHP, even if you think the core libraries are fugly. (they are)

Some apps don't lend themselves to Rails. Large DB centric apps where most business logic is in stored procedures is a good example. Or apps where most backend code is in C/C++. But if you are making a standard CRUD-style web app you can't beat rails. But people, please realize that its just a language and a framework. You can do everything you do in RoR in perl. Or lisp. Or python. Or PHP. You just won't get the code generators and the structure of the framework for free.

Wow, funny comment thread. While I agree it would have been nice to hear some specifics, I can certainly understand the first blush of love and hype leading to a poor decision.

For the guy who said the poster is thinking in a non-declarative way, perhaps you should read up on what SQL actually is? And for the people who want to bash him for "dreaming in tables", get a life. He didn't say "I don't understand ORM modelling" or "Please halp me with teh active records!". He said HE LIKES SQL. Get over it. Lots of us do. Writing reports in Rails is a flat out nightmare compared to just writing manual SQL. Same is true for CakePHP in fact.

But the author sure expected all the Rails kids to come prosthelytize with their Holier-Than-Though we are the only ones to have it figured out you're methodologies suck your thought processes are wrong pack of sheep.

By the way, I've used Rails for years and have successfully developed many big projects in it. And I still prefer PHP. And yes, I understand Ruby quite well. And yes, you'll still flame me for not "seeing the light". Just like you did this author.

But that's because you're narrowminded and can't stand to have someone question your position of self-annointed superiority.

I posted a comment, then read the other posts...

My site also looks like crap and is only a front page with links to several Google Album pages. I did that because it works for now, was easy and does what I want it to.

Forgive me if I'm wrong, but I believe what you did is post your own personal experiences. You listened to the RoR hype and thought it would be super easy.

For you, it was not. PHP worked better for you with your knowledge and training. I don't think you said Rails should be banned from use - just that it wasn't as quick and easy as you were led to believe.

With my experience (VERY limited), I tried PHP, learned enough to make sloppy code, made a workable site with 5+ hits some days (0) on others..., decided to try rails and found it not as easy.

So, I'm reworking some PHP code on the site I made (not the one in my sig!), making some changes, //commenting more, and having all kinds of fun with array($loops) that actually function, even though I wrote them!

I really do want to try and learn Rails, but I can see that it will take considerable effort until I can make something functional. It's not just click-> type-> functional_site.

PHP is nice.
Rails is nice.
Java is nice for some people.
BASIC is what I learned in 1980.

That is just my opinion, of course.

I am tired of having someone express their opinion on a subject and get slapped down by the usual group-think arguments. It is as if you believe that a technology has to be better because it is newer. It is this type of thinking and left me with a bad taste in my mouth. Looking back, however, I think it was a good thing because it forced me to go back to school and get a real degree.

2 year rewrite ? Even 2 month rewrite seems a little long.
Your website isn't that advanced really...

Do it in Domino and you could have done it in a month.

Your post sounds like a rant about how you tried something new and it didn't work out, so now it sucks. No, it doesn't suck, it just didn't work for you. In the end it sounds like bad judgement to hire one programmer for 2 years to redevelop such a large complex site. Lesson learned, I'm sure.

It took you 90000 lines to write that? Were 89000 of them comments?

I bet just the act of rewriting it was the major reason for your success.

The best way to do a project is to start from scratch, get something that sort of works but has some problems, and then throw it out and start over. This time you will do an incredibly much better job. You will design out all the annoying things that got in the way the first time. It doesn't even matter that much if you do the rewrite in a different language, as long as you actually know both of them to begin with.

Prof. Sussman at MIT say that you might as well plan to throw the first implementation away, because you're eventually going to end up throwing it away anyway, whether you're willing to admit to it or not.

People ask what languages like scheme are for, and I say that Scheme is the language that you use to write the implementation that you're going to throw away. Why wrestle with oddball frameworks like MFC or swing or whatever at the beginning of your project, when you really just want a blank slate to flesh out your ideas. And you don't even have to throw it away, you can save it for prototyping and experiments.

First impression of your site was "wtf? is this the right site? Looks like he let his domain expire and someone snatched it!"

Then I clicked around.

Love the content and the organization and the free full length music samples.

Dammit you need to hire a designer to make your site look more appealing.

Glad to hear I was not the only one.

I took a few weeks off from my current project to consider a Ruby rewrite. It was a wonderful few weeks that ended with my deciding a rewrite at this time wouldn't be economical. I returned to my old scripts to discover that in the weeks I was studying Ruby (and also rails) I had picked up many new techniques which are by-and-large not exclusive to Ruby. I'm now writing the best code of my life (albeit, not in Ruby). Maybe next project!

Ruby is a full blown OO language. PHP has objects bolted on. That's enough. Everything on Ruby is an object and that makes it a delight and phenomenally powerful. I have to program in PHP and other languages for pragmatic commercial reasons, but given freedom of choice there's only one worthwhile choise. Of course I could write everything in assembly I can just do it better faster and more accurately and elegantly in Ruby than in any other language. Its ulimatley that elegance that PHP lacks because when it comes to OO programming PHP is fundamentally flawed.

Couldn't have said it better myself. Came to the exact same conclusions.

Typo: "I loved it’s..." --> "I loved its..."

Well I was engaged in the comments until I read that the author 'couldn't' supply a few concrete examples. Nothing to see here, just digg-bait.

If anything this article illustrates that it is not the platform that matters - it's what's built upon it that counts.

Most platforms have the capacity to scale well - just like clean code and logic, it's yours or your teams output that counts...

I like turtles

Thank for your post. Just sad it takes you 2 years to give up and come back to PHP!

Even if it took me quite a while, it is worth reading the comments. I have particularly loved those three classes of people:
- The 'Oh My God, Rails is under attack: let's reply fast' ones : I guess legally people still have the right to post bad experience about Rails
- The 'I can handle 10000 queries/sec in lisp. What about you?' ones : no comment
- And finally the 'Your web site is ugly so you are a poor developer (100000 lines of code)?' ones : no, web development is not only about producing beautiful HTML/flash pages. Sometime, you have to run business underneath.

Finally, my advice:
1. Use the language you feel comfortable with. Of course you can almost do anything with any langage but you will be always more efficient with the one you love. It reminds me of the eternal war between linux and windows: there can be windows administrators that do a good job and run a domain properly.

2. Don't forget that behind a framework there is a language and sooner or later you ll have to deal with it! Because you always have specific issues, you need to do more than what the framework provides (generic by definition) : don't feel bad about it, it is normal! At that point, if you don't feel conforatble with for instance Ruby (compared to PHP), you'll face difficulties! (Note to developers, it is also a good time to contribute to the community nd enhance the functionalities of the framework).

3. Follow not only the evolution of your programming language but also the evolution of other languages because you always learn from difference. Obviously, Derek learned a lot from is rails experience (OO, MVC, SOC with REST...). Most good practices, design patterns aren't bounded to a specific language and could be used everywhere.

euphrate_ylb

I took a look at the CDBaby site. I can't imagine how this project could've taken more than say three months to port over from PHP to any given language/framework. I also find it hard to believe that it took 100,000 lines of code to develop that site originally. I've worked on sites orders of magnitude more complex than CDBaby, both in RoR and other technologies. Heck, I've worked on stand-alone MFC applications that were way more complex than this. None of my projects took anywhere near two years to complete.
The original writeup of CDBaby must've been an extreme hack job. If I heard that a developer took 100,000 lines of code to develop that site, I'd seriously question their competency.
I'd be expecting you to code your own webserver in addition to serving up that site for 100,000 lines of code.
Hell, I've written complete device drivers in about 100,000 lines of code.

"And often that's because the developer spends time and time beautifying their code. They add comments, make sure everything is indented, look at the same file over and over and try to figure out whether there isn't another design pattern or three that they can refactor their code with. They simply worry too much about the code rather than the project as a whole and the user (who never sees the code) experience."

Yeah - and any developer who does NOT do this ends up with crap code that will be unmaintainable for the rest of its life. Code quality MATTERS! Maintenance of code costs far more than the original development. Get a clue.

Language does not really matter unless you're pushing the envelope on what programming - any programming - can do. There are certain major differences in orientation for languages that do make one better than another for any given task. But generally, most languages today provide the core functionality to do most any common programming task. The problem comes when there is poor system design because of poor system development methodology.

Derek sounds like a guy who has never studied system design. Most managers who dabble in programming are like that. They can generate something that works and that they understand - but it won't be maintainable, it won't scale, it won't be secure - and it won't work at some point. And most of the time they can't understand why it takes five times as long to do a proper system design than a "code it now" project - or why it will cost them five times LESS to do it that way over the long run.

Bottom line of this piece: management failure.

And that's the bottom line of most project failures.

It's why in IT, as Woody Allen summed it up, "Nothing works and nobody cares."

"Your website looks like a spam site."

Warning: OT.
Not the most constructive comment in the world, but he has a point. This may just be me, but your site would literally get a half-second glance before I hit the back button. Simplicity is beauty, but beware similarities with overused styles as is commonplace with camped domains.

I like Ruby a lot! Rails, on the other hand, is totally overrated.

Thanks for the advice. I was really thinking of scrapping my projects written in PHP and trying to rewrite in in Ruby, but you have changed my view. I know my code is horribly unorganized and inefficient, so changing the language isn't going to fix my problem. I should probably just learn OOP in and out and rewrite using a language I'm familiar with. Good article, and thanks again.

I knew of one company that got bit by the "this is better" than php, we don't know why, lets switch bug. They had a product that was written in php and a "genius" developer from someplace in the north-west, obviously bored with his job, decided to get involved and convinced them to rewrite it all in another language. While the flying circus rewrite (a clue about what they switched too) happened, they forgot all about "marketing" and didn't understand open source, so that is why you have never heard about them today...

As to the php sucks crowd. When ruby can be as easily integrated into the web server as php is, then maybe it will be useful. Having to fight off the mongrel's to get it to work sucks (as does the WTF ruby syntax).

Derek,

I reached a similar conclusion. We have started a new project with Rails but were completely disappointed. First, Rails is very inefficient and slow comparing to languages like Java that utilize JIT and other advanced techniques, while Ruby processes bytecodes using 60s technology.
Second, we do optimizations with database and our code focused on performance: fast queries and calculations. Rails was not helpful there. And finally, for me, Java professional, Ruby was often counter-intuitive.

Same as you I used what I learned in Rails and took that knowledge to Java. We have a beautiful system that combines Struts and Velocity and mimics Rails MVC structure. It is elegant, VERY FAST and easily scalable

Shame on you for serving XHTML 1.1 as text/html. You should serve CD Baby's valid XHTML 1.1 as application/xhtml+xml.

I never really understood the appeal of sending a hash full of SELECT options in Rails was superior to writing the SQL you're thinking of to begin with. Then again, i never really picked up the "write some other language in Ruby!" fetish.

In the case of schemas, etc. i can see where Domain Specific Language leads to database independence, but writing Rails queries always seemed needlessly elliptical. I always thought the best way to maintain db independence was to stick to standard SQL and write wrapper functions for queries that require engine-specific optimizaiton.

I also have aching problems with annoyances like the limitations of "static" in php5 and the organization of the PEAR libraries (PEAR::isError() anyone?). "Functional" programming (not quite, read: function pointers) are also possible in PHP, but hardly graceful. I tend to avoid them. The whole thing's a pity.

Also, most of the el-cheapo web hosts still run php4. I'm getting excited about PHP6 (ETA: when?), but i'm sure by the time that comes out about half the hosts i run into will actually default to php5 ;-S

I can solidly attest to having improved my PHP via a Rails tryst. Unfortunately, given the limitations of PHP, the result often comes off something like a Java app minus the purity, static typing, etc.

It works.

I really think that the #7 is not very fortunate in the comparison with girlfriends. It might be a funny joke for guys, but I really think the text would be much better without it.

GO BACK TO C!

PHP for life!

It seems to me that alot of PHP people don't get MVC and OOP and I've strived to get those I work with to improve their skills. It's nice that RUBY does this but they inhibit you (like SQL for one as you pointed out) and it still has yet to scale.

There really is nothing in RUBY that other languages with a framework can do better and do do better as they scale whereas RUBY still doesn't.

@Miriam
I though the 'girlfriends' comment was quite enlightened. People go chasing off after new partners only to discover the new one has the same 'flaws' as the old one. Some people do this again and again, without realising these supposed flaws are in fact entirely their own.

Many of the polarized comments here, including some unwarrentedly harsh criticism of Derek's site (Rails didn't work for you, therefore your site must suck, etc), prove the comparison is valid.

I tend to agree that you need to be close to the SQL, always. Anything that takes me away from my queries, joins, sorts etc is completely missing the point of any sophisticated and efficient application. The database is central, the language is ancillary. PHP just does it. Reliably, easily. Designing your own MVC framework is no big deal.

Don't blame the language for not knowing how to use it. I'm 100% sure you would have spent the same 2 years in vain if you tried switching to asp or jee. And can they do more than PHP? YES. But it all depends on what you are trying to do. And how well you know how to use the tool...

Third time's a charm.

Excellent post Derek. The most important things in running a successful Internet company are focus and taking the right opportunity. PHP is an excellent, mature solution to take that opportunity and solve your problems. While you and many others, including some of the biggest ones, are making money using perfectly fine working solutions, let theorists and fanboys pursue their goals of theoretical correctness. Looking at life cycles of web sites and products, they are the silly ones as opportunities pass.

"For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."

Couldn't have said it better myself. It's a shame that people can't simply see programming languages as tools, instead of dogmatic religions where 'my syntax smites your syntax'. I guess people invest time into learning a language and they get attached, I can understand that, but it doesn't mean they have to attack every language they have yet to master.

Amazing how many replies miss the point entirely.

A musician bought into a framework due to hype and *unlike many of the folks still mired on, say, the Java trend's rocky coast* realized that the ugly, simplistic, buggy, inelegant language the code was initially written in was just fine. Applied some lessons from the things RoR gets right, re-launches, experiences success.

Writes op-ed piece about what worked for him, why.

Fanboys flood the piece, write about how he should have let the patient bleed out, learned how to use their favorite tourniquet, site is ugly, etc. etc. May or may not have read the post. May or may not have ever launched a significant Rails site (at least one has, others simply snipe without substance).

Bottom line: the end result counts much, much more than the tool. Nobody gives a shit about what kind of brushes Michelangelo used.

I think this is a shitty article made only to promote your "new" site.

Sorry.

I absolutely agree with the writer. RoR is already dying project as it's too limited, as it's designed to solve already trivial problems. Nontrivial ones will cause enourmous burden for dev, as you have to write all kind of hacks.

all logic is coming from the models, one per database table
Nice to see this being acknowledged. Any engineer knows it's true, but it rarely gets said. Get the data model right, and everything else pretty much drops into place. Get it wrong, and the project is hosed from the start.

Now all you need now is a designer. Your web site is u.g.l.y.

It's all about design. Rails has Design - a plan and pattern for how things should work - and your original PHP code didn't. No shame there - nobody's code does at first, and code that grows organically as you grow your business is the worst of the lot.

Rails failed for you because it's Design didn't match your Design (or lack thereof). But you made the conceptual leap that many others don't, and now the importance of Design is yours - again, congratulations.

The language really doesn't matter all that much. It's the Design.

I am actually quite pissed about those who evangelize Rails. I am a recent EE grad who started off doing a website in RoR - and then when reading online I came across many people saying that the Rails' backend does not scale well. Then I go and ask questions on Ruby forums about whether this is a problem with Rails - I was already about a couple of months into coding seriously, and I was loving Ruby and I was loving Rails - I didn't want to let go, it was like a nice dream. What ultimately pissed me off is that many Rails' folks would say this - "Why bother about scalability right now? Only a very small fraction of the websites become so popular that you have to start worrying about scalability. What makes you think your website is going to become so popular? Cross the bridge when you come to it." I was totally pissed off with this kind of widespread mentality. Then, I came across an interview by the person in charge of Twitter, saying what a pain in the butt it was for them to scale Ruby. That was the last straw - I was pained that I had to go back to PHP after experiencing such a beautiful language and framework - but like someone points out here, RoR is like a beautiful girl that is a one night stand and PHP is like an ugly wife but who will stick with you in the worst of times - I prefer the latter.

Well, Derek, maybe this discussion will at least boost traffic to your site. It got me there and I like it; simple and fast, focused on content and what I want to know. And soon there will be an Internet legend that it's written with a 100K (well, why not say an even million) lines of code, ... more power to you!

Hi, Derek! As it is noticed elsewhere here, it looks, like you had not to rewrite, but recreate thing. Give away current database, as well. And everything else, perhaps. You start from scratch with RR, and you are guided further by it's limitations. You pick your limitations first, you get nowhere with those of framework.

But I could confirm experience, you are posting here: approaching loose language, as PHP, with cleaner constraints/aims on your mind, you are getting surprisingly different product from the same language. Actually, I had quite satisfactory OOP implementations with the same PHP.

It is good, that you found perfect recipe for your situation and desires, in the end. Also, there is point in sharing such dramatical real-life project story: though not directly appealing to Ruby lover, it certainly can be of use to some PHP code maintainer.

Good luck with cd babies!

Gotta love the "I could have done it faster in any language" comments. I stopped saying that a decade ago because you never understand the complexity of software until you really delve into it.

It seems the point that so many people are missing is that you aren't bashing rails so much as stating why you aren't using it at cdbaby. Rails is still young and it will have it's growing pains, but it has done a good job of getting a LOT of web guys thinking about things as developers instead of as templaters.

I don't see why people think so much in terms of Perl > PHP > Ruby > insert language here. Get to know the languages and figure out which one is right for any given job in terms of performance, scalability, ease of development, and maintainability with your current work force. Sometimes Ruby is a great answer. Sometimes you are better off using something else. Regardless, the concepts that RoR has brought to light are beneficial to everybody.

There was an element of this article that few seems to have commented on, which is that the author hired a good programmer (good enough to head over to 37 Signals afterwards) to write his code. So all these comments about Derek Siver's programming competence are irrelevant: he hired someone with the language skills. I'd like to hear Jeremy Kemper's perspective on the project too. I think that, if we were to have comments from both Sivers and Kemper, this whole story could be an excellent case study in how projects can not work out even with good intentions.

A lot of comments read along the lines of "100,000 lines of code for your crappy site? You must be joking". I suspect that Sivers would agree, after all the point was that his rewrite in PHP had nearly an order of magnitude less code than the original. How about ~10,000 lines, is that OK?

Finally, in response to the howls of indignation from the RoR purists, I've worked with people who have strong opinions about methodologies and "using the right tools for the job". I have, indirectly, been a customer of these people. In other words, I've had to pay for them to do work for me (due to complications I won't explain here, I didn't have a choice in how my project would be implemented or who would do it). And, despite their obvious intelligence, they can be a disaster on a project.

There are some programmers who spend more time preaching about "the right way of doing things" than they do writing functional code. Not only that, they spend time belittling all those around them who lack their brilliant skills at abstraction. Eventually it all gets revealed as Emperor's New Clothes and these people get sacked.

As the rands in repose blog points out, the real geniuses tend to be normal and easy to get along with. I now try and avoid working with over-opinionated programming evangelists. I've seen projects and teams derailed. No hire.

Kind of wrong to compare a framework and a language, no?

If you were skilled enough in ruby, you could have done everything too. Without rails.

Integration is not about the language, its about the structure.

"Programming languages are like girlfriends" - when you write, your imagined audience is a bunch of straight men, isn't it?

Or you could use .NET

I think you didn't fully consider the implications of the technology (rails) you chose vs. the architecture you had in mind
I wrote about it in my blog

"Or you could use .NET"

The .NET framework suffers from many of the same things that the Ruby framework suffers from. Both suck for data heavy transactional environments. The object model of languages like .NET is going to be a pig if you are going to follow the multi-tier model.

Although it is possible to write data centric systems with .NET, the developers have to be willing to throw a way their religious use of design patterns and best practice in OOP which would fit in application or game programming but bog down data centric applications. They should resort to use POOP (procedural object oriented programming) instead where objects are used to represent entities with a state and use structs or temporary tables to represent stateless entities or large matrixes of data. The objects in the system maintain state and pass messages while most of the data bypasses the object layer and passes from the database to the interface.

I would also argue that most of the business logic should be in the database in the form or stored procedures, triggers and business rules stored as values in tables. Having the business logic in the data layer allow you to leverage the power of triggers which depend on the state of data in the database and make your product virtually language agnostic which means you can rewrite the interface and application layer (if it's required to exist) without losing any of your business rules.

I've noticed that a lot of off the shelf corporate financial software is written that way as it gives not only the advantage of not being tied to one platform/language but can be extensible and customizable for the client without requiring any code changes.

yami: "Programming languages are like girlfriends" - when you write, your imagined audience is a bunch of straight men, isn't it?

uh oh, someone wasn't p.c. enough for yami.

I think the reason most commenters are so upset is because this post is now very high-profile and it's claiming that rails wasn't up to the task of creating an enterprise site like cdbaby. which seeds doubt into the tech community and that means their jobs (or in some cases, their passion) could be thwarted because one programmer didn't use rails for what it was meant for. i'm a full-time rails programmer and i know that i'd get a well placed email from my boss who had to put up with the rails from php transition last year, holding mostly onto his faith in me and my team. but transition is a money question and i still stand by rails.

what i think the community needs is a little clarification. it certainly baffles me that 2 top notch programmers couldn't bang out a cd retailing site in a years time. it must've been a specific issue. derek, if you'd give us some specifics, perhaps it will help to improve the framework.

ps. lets not give php too much credit. no matter how much mvc you give php, it's still a bitch to develop in.

given you thought ruby was beautiful and rails a great teacher, did you consider any other ruby-based, rails-inspired micro web frameworks?

"PHP is Ugly."
Incorrect. inexperienced and undisciplined coders make ugly, regardless of language. Solid coders with discipline can even make ADA beautiful.

"Why didn't you hire a Rails core member? Who is Jeremy Kemper? I have been programming in Ruby for 4 years now and I have never heard of him. I think you need to reconsider who you hire next time to do things the Rails way."
If you've got to hire someone to do things "the right way" for a language then it's not an effective tool at all. If you must adjust who you are and what you do to fit the tool, the tool is deficient. If you hire an expert and he *still* can't make it "good enough" for the language/framework then the language/framework is supported simply by believers, not logical operators.

I just have to laugh at all the zealots here. Your love of a particular language or framework blinds you to the reality of Derek's experience. His experience is clearly based on a real world scenario and two years is certainly long enough for him to say that he has a reasonable amount of time with it. To you rails-heads: if it works for you, wonderful! But you're as bad as Microsoft if you think that your framework/language pair is good enough for everyone and everything.

PHP, JS and an AJAX methodology are framework enough for me personally - me and about 200 of my closest tech-friends talk about it at my forum, www.perkiset.org in depth all day long. We do not have enough Ruby people there so, interestingly, I took the Ruby and ROR boards down last night. I'd LOVE to have some of you zealots come tell us old guys why it rocks. If you do come, please PM me there and I'll put the boards back up.

shame the author didn't read Chad Fowlers post on re-writes http://chadfowler.com/2006/12/27/the-big-rewrite
Could have saved him 10 months at least as it was written in 2006 ;)

I looked at your site, seems like a couple months work in asp.net.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius, and a lot of courage to move in the opposite direction.
~ Albert Einstein

Why not use something that doesn't require so many lines of code?

Thank you for sharing your observations. There is much value to be had from trying new things.

Actually...

Seems to me that one of the lessons here has less to do with choice of language and more to do with "framework" vs. "framework-less". You cannot really go "framework-less" until you know the ropes: MVC, templating, object-relational mapping, etc. These are exactly the things that frameworks teach -- they guide/force you into best practices. But once you understand how to, for instance, write a bit of code-generation script or implement the "singleton" pattern, you don't necessarily need the framework to do that stuff for you (and often in its own "opinionated" way that may not, in fact, best most applicable to the task at hand). There is MUCH to be learned from Ruby on Rails, Django, Catalyst, etc. (not to mention Camping, Web.py, etc for a lighter-weight approach), but the fact is the ideas implemented there just aren't that hard to recreate in PHP. And PHP has two huge advantages: large install base and drop-deap easy deployment. PHP is by no means my favorite language, but for simple, straightforward framework code, give me PHP5 + Smarty (or XSLT) any day.

Peter Keane

I wonder whether ruby + mongrel + some templating system would have done what you needed (sounds like Merb). I couldn't give up the OO freedom that Ruby provides, but I could lose some of the Rails syntactic sugar in exchange for speed and explicit code. Sometimes Rails magic makes it hard to understand why some example works, but my attempt in my own application doesn't, and tracking through convoluted dynamic methods in the Rails source doesn't help. And then sometimes I discover Ruby is intepreting some ambiguity in my code differently to what I meant. Ruby/Rails is not the Holy Grail, but it has opened a trapdoor into a whole new way of doing things that wasn't just a logical extension of what we were all using before.
I dig what you say about #7 - I would write C# very differently to now, and I would recreate some of the Ruby magic in C# (I know its possible, but ugly, but who cares when its in a library function).

I dream in queries. I think in tables.

well said! :)

Ironically, I had already heard of cdbaby.com because I met a musician who uses it to sell his CD's (http://www.fransnyder.com/).

One of the great things about web programming is being able to find just the right tool (or combination of tools) for the job. When all you have is a hammer, everything looks like a nail. Maybe this was just a case of picking the wrong language / framework for the project. It also could have just been the discontinuity of the project since "many setbacks were because of tech emergencies that pulled our attention to other internal projects." Besides, anytime you start a project over you have a much better idea of how to organize the code. A little extra planning in the beginning might have prevented this rewrite.

this guy is just trying to drive traffic to his site with this story

I wish you luck with your PHP... I tried abortively to move from PHP to Rails 2 or 3 times but always ran into the same issue, if you have any legacy anything, don't even think about rails. Unless you are starting from scratch, give up now, you have made assumptions in your DB that rails will not like, and you won't be able to work around.

That being said, I've found a much nicer framework for "legacy" systems. The python framework Django (while really designed for "from scratch" systems) is much more flexible when it comes to existing database schemas. I have ported 3 PHP apps to Django with only minor alterations to the DB, Django doesn't insist on doing *everything* for you like Rails does (although it can).

I also like python as a language better than Ruby but that is probably just cause I've got more experience with it. I'm sure they are both capable languages, I just appreciate that with Django I'm not boxed into a corner 100% of the time that a design decision *makes more sense* than the way the Rails guys envision a "perfect" app.

Are you kidding Aaron? Jeremy Kemper (bitsweat) is one of the top contributers to Rails and has been a core contributor for a long time. Get your facts straight.

Application architecture, design patterns, best practices, etc. are not often discussed in the PHP world, but they probably ought to be. I would HIGHLY recommend the recently published "PHP In Action" (Manning) as an indispensable guide to enterprise-grade PHP web development. Object-oriented design, testing & refactoring, MVC, Data class design, etc. are all in there and it is (like most Manning titles) a very well-written book.

It simply seems that you're a professional in PHP for a too long time. There is no way to change your programming language for you.

Well, what about Ruby instead of Rails? ;)

PHP done in MVC is great for RAD and performance. I'm not a big fan of programming platforms that sit on top of a bloated virtual machine (java, ruby's, .Net, etc...).

good for you Derek. Glad you found what you needed.

Hard to believe how defensive 90% of the comments are.

Wow, lots of newbs and lamers on here defending one language or another, or their favorite frame work. Let me add to the noise level...

In my expeirence the problems with programming these days are the people who consider them selves "programmers" when they are any thing but! Sorry, but those of you who do not understand at least one directly compilable language, and at least a small amount of how assembly works and what you are actually doing with the hardware when you write code, you people are NOT programmers! If all you know is PHP, ASP, or Ruby, you are a scripter. You write macros for a run time scripting language, you do NOT program! What you are doing is writing a glorified batch file (or shell script for us *nix people). Programming implies that you have at least SOME understanding of what's going on under the hood (or at least is SHOULD imply this). I have taken part in way too many conversations with morons who think they are "programmers", but try to convince me why they do not need to understand things like assembly and hardware processes. I have literaly been told by these college grads (that everyone seems to have such a high opinion of) that "I am a software programmer, why do I need to know about hardware? That's someone elses job". Of course these are the same ASP loving morons who cannot tell you what the memory foot print of their app is going to be, how large of a server it will require, and about how many simultaneous users it can handle before it chokes to death or has massive locking issues.

Sorry, but if you do not know what is going on under the hood and what your code is actually making the computer do then you are NOT a REAL PROGRAMMER!! Get over your selves! You can make some cute crap in HTML. That's nice, but you have about as much talent as the average script kiddie at that point and have a looooong ways to go before you deserve the title "programmer". I honestly find it personaly insulting that some of you call your selves programmers, it's a digracful insult to those of us who DO know what we are doing!

I feel bad for those of us who know what we are doing, because we always end up getting lost in the ever expanding sea of morons being pumped out by colleges and programming classes. I know what it is like to fight to win a bid on a project, only to loose to some firm full of microsoftie ASP writing newbs. And then to check back on that web site once it's up and see the absolutely appaling design they paid for. Or to find out the client ended up wasting thousands of dollars on a project that never got finished! These mircosoftie morons are giving us real programmers a bad name. Microsoft is directly responsible for lowering the standards across the entire computing field! They got end users used to having crap software that crashes all the time, so now business managers just expect to get crap code for their dollar. M$ watered down computing as we know it!

Oh, and to Scott who said "if you blindly-hate Microsoft like most other people on O'Reilly", ummm no there is nothing blind about it. M$ is a horrible company that is directly responsible for holding back the progress of computing for their own financial gain! They buy up competitors and close the doors so that better software packages don't come along and destroy their monopoly. They use more vendor lock-in than any body. They have made gobs of money on the backs of the IT people, forcing poorly designed OSes on to us and expecing to maintane them even though we are not given the proper tools to do so. Smart IT people don't hate M$ for the hell of it, and no it's not jealousy either. I have no problems with big business or capitolism. What I have a problem with is when a company has lied, cheated, and stolen their way to the top making billions they do not deserve and making my life worse in the process! You micosofites only like M$ for the following reasons: 1) their bloated ways of doing things means more jobs are required to handle the bloated mess that IT has become, opening up more entry level jobs for you M$ loving morons, 2) they lowered the standard that people expected of computers and software, so those of you who cannot make a program work with a damn feel right at home with M$, 3) They try to put training wheels any everything so you can point-and-click you way through things that really ought to take some critical thinking and manual processes. Automating stupidity... that's really all M$ is good at...

So, to re-cap, most of you are morons and that's why you are such big fan boys of one language or another, because you haven't bothered to go out and learn lots of languages like us real programmers. And if you have never actually compiled something into an executable then you are not even programming, you are scripting. I would say 10% of the people posting here are REAL programmers, the reset of you are script kiddies who think you know more than you do. If you don't know what an accumulator or a register is you are NOT a programmer. If you use divison and check for a remainder as a method to check the even/odd status of an int, instead of just quickly checking the least significant bit, you are a scripter and NOT a programmer. If the last two sentences I typed make NO sense to you, and you are scratching your head wondering what the hell I just said, you are NOT a programmer!

Talk about Nerd Rage. Down boys! with all your babbling about how Derek sucks and his PHP sucks...whatever. CD Baby makes more money in one day than your basement dwelling butts do in six months.

I don't use either ruby or php, although i have tried the both out. But your list has to be the DUMBEST list ever!!!

1. Can Rails can do that PHP can't? No? Can PHP do anything rails can't? No? Well, what a great reason.

2. We are already using PHP.\Integrity. The first statement is true, but to say that ruby doesn't have integrity? You are really coming off as an asshole. Why doesn't Ruby on Rails have integrity? If so when is it unreliable?

3. You don't wan what you dont need. Well does it hurt you/your company to have the useless capabilities. No? Well your argument is as useless as those extra capabilities are to you.

4. It's small and fast. Your retort is similar to point number 1. With the exception being, how simple is it to making either fast? Is ruby easier to make faster? or is it PHP?

5. Built to your tastes. Valid, but only valid because you have very little in the gumption department. Gumption being, if you don't know, the desire to learn and learning as a desire to make things better. Such a trait would lead you to try knew things even if they don't make things better then before.

6. SQL. Valid. Possibly your only valid point. If i wanted to be a dick i could say "Since Ruby is a OOP you could just make a class or a few methods to run all your queries." But i will let you have this one.

7. Stupid Analogy. That is the end of my retort. Thank you i feel dumber for reading this stupid ass list. You could have gone into actual detail about the two languages and said something like "Ruby is a bastard child of C/perl/python/whatever." and i would have been more inclined to believe then this asinine attempt to impinge on people.

I switched back to PCP after 2 years on Crack.

I don't know the author nor he's work, but purely based on the article the only possible conclusion is that he is a very very bad manager. No need to get picky about one language or the other. In the end of the day it doesn't matter if it is ASP.NET or Perl. Really. Anyone that has done Web development (AND Systems development) for the last 15 years the way I did, we all know that a website like cdbaby.com é a 2 month job (at most) in ANY of the current web languages+frameworks. If you sit in the problem for almost 2 YEARS ... sorry, you're a lousy manager. At the very very least, you would gave up after 4 months. That's the real example of a Sunk Cost went wrong. Face it: there ARE real production delivered websites in RoR that are as good as anything else. Pick you choice, be it Perl, be it PHP, whatever. No one should sit over the problem for 2 years. That's just stupidity. Doesn't prove that the framework is bad, just proves that the prople involved are utterly incompetent and clueless of technology.

Good article and lots of interesting comments if you can stand slogging through all the dreck.

Hey people, he never said RoR sucks and cdbaby.com is almost certainly a lot more complex than it looks at first blush.

There are many lessons represented here, in this article and the comments that follow. Here are, IMHO, some of the more salient ones:

1) Experience is more important than the tools you use. (Or "Yes you can write good code in PHP too.")

2) No framework is perfect for every application.

3) The potential for incremental improvement is a core strength of web-based systems.

4) Some people still think Java is OO. (Or "Never underestimate the power of marketing.")

5) Beauty is in the eye of the programmer. But that doesn't matter much to experienced programmers because they know that working code is going to have some warts (no matter what language it is written in.)

BTW, on this beauty thing, Ruby really is beautiful... in a Miss America sort of way. But the Helen of Troy of programming languages is LISP. Don't bother arguing this. It is a fact. ;-)

Be kind.

I only shop at sites coded in assembly.

Someone prolly already said this: you could have used Ruby for the rewrite and done your own custom thing. I've done the PHP -> Rails thing and what I love about Rails is it gives me a good excuse to write a lot of Ruby. And Ruby, despite being a slow language (for the moment...) is really, really, really fun.

Why did you choose PHP instead of Ruby for the rewrite?

I feel the same way about asp.net and asp. There is nothing in asp.net that I can't do in asp.

I very much identified with this story.

From my vantage point, this story is not about the particular language, development tools, or technology used. It's about a small business owner taking control of his business, using technology he knows and is comfortable with.

A few years ago I helped start a small web-based company. The owner of the company, a smart businesswoman but computer illiterate, handled the marketing, sales, etc., and I programmed the web site. (It was in PHP, but that's irrelevant to my point.) Then, due to an unfortunate disagreement with me on terms of my compensation, said owner of the company made the (of course IMHO) short-sighted decision that she would rather go it alone, to save money. She ended up spending in excess of $100,000 (far more than she ever paid me) to hire contractors to rewrite what I did in ASP.NET. She even had to fire one contractor for incompetence and replace them with yet another. Now the future viability of the company (which I am no longer connected with) is very much in doubt.

The moral of both stories? A small business owner needs to either personally have a complete handle on the technology running the company, or have a trusted partner or vested employee who does. An owner or management team that is not comfortable or versed in the vital infrastructure of their own business is bound to fail. That type of essential knowledge cannot simply be "farmed out."

The mistake that Derek made, which is very analogous to what my former associate did, was to abandon a workable and familiar technology in favor of a perceived superior -- but unfamiliar -- one, and at the same time bring in for implementation a new team that had no history with the company.

Fortunately for Derek and his company, when faced with the failure of the new effort, he had the fortitude to change course, and still had his personal skills and experience to draw upon to turn things around. Tragically, my old friend had neither, and has likely spent her way towards bankruptcy as a result.

Wow! What an article - it makes absolutely no sense. I thought it was actually a parody article. A couple of thigns that came across

1/ Carpenter blaming his tools?

2/ Having had some time to look at CDBaby - I'm struggling to see what you were coding for 2 years. Either you're worthless as a coder, you haven't given us enough background information or you're exagerating

3/ When doing a re-code - you might wanna think about re-coding the use cases. But a line for line re-code will get you no-where.Whats the point of recoding something line for line in a new language. Smells like the blind leading the blind on that project.

I had this "php" developer working for me. Just couldnt get his head around RoR. Blamed everything under the sun. Why are certain parts of the PHP community so blind to external technology?

So, basically, you are happy with your preferred language, which is both normal and better for your company.

OK. Then why the heck did you try to do EVERYTHING in a language you do not MASTER?

That is the question you should ask yourself.

It looks like you never coded in OO style before?
Basically all your arguments are the same: any OO-code is nicer than crap PHP.

I was expecting to read the technical difficulties with Ruby.

Everyone knows crap-PHP is crap to use/read/rewrite and any Framework will always be larger than a self-built one.

I think one of the things PHP can't do and Ruby CAN is:
reading the requeststream. Tapping into the traffic before it's entirely processed.
I love this feature, it gives me total control of everything that gets send/uploaded to my server.

So yes, there are things Ruby can and PHP can't.

If I knew my little personal blog post was going to be read by any more than 2 people on earth, I could have said:

"I thought my old language was ugly, and since I needed to do a rewrite anyway, decided to do it in a new fancy framework. But it's surprisingly hard fitting an existing app into a framework. So hard that after 2 years of trying, I looked at the old language I thought was ugly and realized the problem wasn't the language, but my previously poor skills, now improved and defined by 2 years of working with this framework. I ditched the framework and rewrote in my old language, which was much smarter for our company's needs because it so easily integrated with all of our existing code."

My post was not meant to be about strengths or weaknesses in Rails or PHP in particular. It's unfortunate that is the aspect that drew all the unintentional traffic and comments.

Quote from a Dave:

Memcache? Fragment caching? Cap deployments onto a tuned set of mongrel servers? nginx front-end dispatcher?

Did you or your rails "expert" do any of these things?

We have use rails to develop an enterprise software system which is now in production with a number of clients, so I am speaking from first-hand experience here.

The Ruby interpreter is currently slow and will hopefully improve over time. But there is no reason why a site that can't be written in 2 years can be written by YOU in a month using PHP. By your own argument, "when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."

So what the hell was the problem?

The fact is that the list of things to do (nginx frontend dispatchers, etc.) to get the Ruby site to work aren't necessary for the PHP version of the site, most likely.

Which makes it less complicated. Which in this case is a good thing.

Other than that, the Rails zealots in here should collectively go home and be ashamed, you're presenting a seriously screwed up image of Rails here.

The salient point is that you need a very good reason to rewrite a working codebase from scratch, regardless of the technologies.

Read this piece from Joel Spolsky:

Fire and Motion
http://www.joelonsoftware.com/articles/fog0000000339.html

Sorry, Derek Sivers, but your article gives no facts of what was wrong with Rails.

A one-man project and a team project is two different things.

So far from these comments I've learned that:
- Anybody who lets a website accumulate 100,000 lines of code over the course of several years is an incompetent programmer, even when they take what they have learned and rewrite it to a tenth of that size;

- Anybody who lets a seemingly-straightforward project drag on two years before pulling the plug is an incompetent planner, even when they take what they have learned and accomplish everything they set out to do in two months;

- Anybody who sets out to recreate a PHP web application in Rails and fails is an incompetent designer, even when they take what they have learned and write an MVC solution in PHP that's familiar, fits their problem domain and integrates with their existing infrastructure;

- Anybody who finds out for themselves that porting an existing application to a new framework is a waste of their time is a moron, even when they take what they have learned and warn others that the grass is always greener on the other side.

Who are you going to call incompetent when a project of your own goes gets mired in redesign, reveals itself to be idealistic and insufficiently planned, or turns out to be a square peg in a round hole? Who are you going to rail against when you post on your blog about learning from your mistakes and are piled on by 100 tiresome, pompous twits claiming you should have known it all along?

A top totch Rails programmer(Jeremy Kemper) couldn't do what you did in two months. If it's true, the question is why did the project fail? Could you give some specifics?

Based on your post here, it's obvious that you need to learn some basic stuff in software development, and need it badly. And your site is not Amazon or Ebay. It's a little online store. I am curious what's the REAL reasons for the failure of the re-write project.

Congrats, Derek. I know how good it feels to immensely simplify one's codebase, and how strong one's desire can be to share the achievement with others. It's unfortunate that nearly everyone who commented here seems to have missed the whole point of the article, which was not to bash rails, or even to praise php.

It seems to me that the point was that the grass isn't always greener on the other side of the hill, but that you might learn something valuable by walking over, checking it out, and coming back home.

Thanks csuter! Exactly.

It's a shame that people thought this was a "Rails versus PHP" article. It wasn't about the specifics.

I should have left out the framework and language and just called them X and Y, and let people fill in the blanks from their own experience.

I would want to hear more about _technical_ details of Ruby fails.

I have to agree,

Before I started learning Rails, my OOP skills sucked big time, now after 2 years in my head just fixes completely in what is required, objects methods polys, the whole thing.

Such an amazing teacher!

I call super "fud" on this one.

I've developed http://pantherfotos.com in Rails in about 3 months (3 hours a day working on the train from and to work). It contains about 60 database tables which power: forums, blogs, photo uploads, google map integration, dzone/digg type listing directory, security, monthly memberships, e-commerce (selling of photos and photo albums), taxonomy (polymorphic), an articles section, member clubs (with the ability for members to create public/private clubs and clubs to create public/private forums), RSS feeds (with geotagging where available) on pretty much everything, commenting system (with akismet integration) on everything (polymorphic).....

I probably forgot a few things there. Point is all this comes in at 6353 lines of code. It takes me under 30 seconds to update my website via Capistrano and Subversion.

PHP sucks balls. I know because I used it for three years. No PHP framework will ever turn me back to the shit side of the force!

I am glad you did tell the story with PHP and RoR explicitly named. I think the point you wanted to make was clear. Otherwise the article would have gone unnoticed. Great article!

Hi Derek

Could you write another post with some examples about how your PHP code improved after your "Ruby taint"?

Cheers
JD

What Rails limitations in particular did you experience? All 7 reasons have mostly to do with yours, it seems.

I don't believe this has anything to do with the language, or the framework, but the work ethic.

Your first site needed a re-write because it was clearly massively overcomplicated. I mean 90,000 lines, for an e-commerce site.

The rails build failed, most likely, because you spent too much money and time "in the rails internals". That's not what rails is built for. If you don't understand how to utilise the rails API to turn a rails app into a reasonable e-commerce site, then I think something is starting quite seriously wrong.

If load or SQL speed are your issues, then maybe rails really isn't for you. This doesn't discount the language, or really prove much about the framework though.

There are things which PHP simply cannot do over ruby. That's just the way the languages are. Clearly, these aren't the things you need, and in that regard, there is no argument over your decision. To claim that that capabilities are the same however, is somewhat of a drastically inaccurate statement, if nothing else, for the syntactical capabilities of the languages.

If you seriously want to push that you had a seriously skilled software engineer on the team next to you, and you re-wrote the program in two months, after only half completing it with more staff in two years - then there's a VERY serious problem, likely one of: False Evangelism, Misguided design, Enforced poor technological choices, Over-Idealism, Not enough _actual_ project work being done. All in all, there is a _clear_ lack of pragmatism evident.

I really need some help to understand what the real problems were. Maybe it was rails, that would make me laugh, however, if rails is really that much of a problem - didn't you feel tempted to make a strong management decision after 1 year?

first thing : rail is a framework; php a language... how can u compare two thing uncomparable ?

second thing : "what can rails do that php can't - nothing" -> The most part of the modern language can ALL do the same things !! All computing engineer knows that, the only difference is the time u spend to code, the speed of execution, the portability/interoperability of the language and so on.

In conclusion, since you don't explain us what is the main fact that made you cancel your RoR project and "return" to php, this article means nothing !

PS : I only code a few in ruby / roR, but I always could do my own SQL request... was your ruby developper really a pro ? Active Record don't force you to forget SQL !

Hugo, French IT Engineer

So what were the limitations you ran into with Rails?

Brooks said "build one to throw away" and it's still true.
al.

Hi, I looked at cdbaby and I honestly can't believe that you worked for two years with rails to try and produce this website. Then, switched back to php and it took 2 months for the rewrite. You should have hired a coldfusion programmer who uses a mvc framework such as machii or modelglue and the whole thing would have been done in about one or two weeks... seriously. And if a ruby on rails programmer couldn't have produced this website in about two weeks, I don't think you had a top guru rails programmer.

Nice article. I agree with #1 reason. Until i discover other server side scripting language that can do what PHP can't do, I stick with PHP. I believe non of them(server side scripting) is better than any of them. It is just a matter of how depth is your practice, and that is what makes the distinction.

I don’t need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn’t complain.

Thank you!

so people like you get to run society, while the poor slobs who would be fired/homeless if they wasted 2 years of time on some hair brained BS scheme that was caused by a simple lack of education, have to suffer the consequences.

This is the exact conclusion being reached by most professionals out there who are working worthwhile applications. Very well written. Thanks for posting.

All the Ruby lovers that have difficulties thinking up an advanced applications all by themselves are so pissed off by this. I think you summed it up wonderfully: If you really know how to program, PHP allows you so many advantages. Rails is much like the wheels on a training bike, the go-getters don't want to keep the training wheels forever.

If you love programming and you are one who generates good code, then you can take full advantage of your freedom and write something terrific with PHP. If you are just trying to get by and need a template then you might be better suited to just ride the "rails".

Man is there a lot of pent up rage in the RoR community! Frankly, as a PHP and Ruby developer who has done a bit of Rails work as well, I don't feel the least bit "offended" or any less "enlightened" by any of Derek's observations. Certainly Rails developers must not be shocked to learn that there is more than one "opinion" when it comes to software development or it would turn out to be more of a science than an art..

Rails development moves quicky for things like mikey's weblog, sarah's guestbook, john's photo album, etc. The turn around on these stellar applications is incredible. But if you've ever worked on a top 100 site, then you know about the "rails wall". This is the point at which you have to start modifying the entire project to make rails work.

In the hands of a real programmer with a plan, PHP development time matches and surpasses rails on every level with mikey's weblog, sarah's guestbook, john's photo album.

But the best thing is, when you are working on the top 100 site, there isn't any "PHP wall", the project unfolds exactly as designed, you don't need 10x your current number of servers to run it, and it doesn't take 2 weeks to roll out.

Plus you have more free time to have a social live and get laid... as a result of your bonus and lack of insanity.

Hmmm, I seriously doubt the suggestion made that there are certain things that Rails can't achieve but Ruby can. The author provides no evidence to support this statement. I am no Ruby developer myself but know that languages are literally ways of expressing the same task to the underlying platform.

I suggest the author provides no evidence because the reality was that he lacked the skills to adjust to developing under a different paradigm in Ruby. I think this is highlighted by passages like:

'It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.'

'I love Ruby for making me really understand OOP.'

'Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.'

Dear Derek, many many people have made the request that you provide more details about what went wrong with your re-write project. People want to learn from your experience.

So far you have not answered. You don't have to publish your code, but I am sure you can talk about some of the problems in more details.

You cannot just make this kind of huge report without giving concrete stuff to back it up. Hand-waving is not good for discussion. Some people in the community are interested in what you have said(some are even puzzled), and want you to explain it. I wish you can do it to back yourself up.

> ...provide more details about what went wrong with your re-write project.... you have not answered... talk about some of the problems in more details... You cannot just make this kind of huge report without giving concrete stuff to back it up.

Nope. I'm done.

Browser-search "Derek Sivers" in the comments, above, and I have explained many times why this post was not about Rails or PHP.

There is no interesting lesson in my particular specifics, and the details would distract from my real point, which was about customization vs frameworks, integration vs overthrow, learning vs prejudice, and appreciating how you've grown.

I have many things on my TO-DO list that I'm excited about and working on today. Taking hours to explain myself to a blindly angry mob is nowhere on that list.

This was just a stupid blog post never intended to be read by more than a few people who had asked me why I went back to PHP for CD Baby. I've caught enough shit for it and spent enough of my time on it, answering the questions here.

- Derek

P.S. Jamie Flournoy's blog post has more wisdom than mine.

I would like to further suggest that the author's reasoning is misguided (or lacking). Although we have to assume parts of his old PHP system could not have been refactored rather than re-written (the article provides no reasoning), his choice in changing development language for a new platform seems poor.
His existing codebase and development experience is in PHP, which provides advantages both in his knowledgebase and with integration (the author highlights this advantage himself in conclusion #2). These are strong points of reasoning which shouldn't be traded for programming syntax.

What a bunch of whiny assholes. Thanks for your story and dont listen to these wankers.

I wonder if it would take so much time had you rewrote your website using just plain ruby...

Great write-up. Foul language is unprofessional.

Good for you, bro. Stick to your guns. Don't let the 'my language is better than yours' pissing-match nerds get in your head. Use what you want. My lord, 2 months after 2 years of anguish. Remarkable.

Thank you Derek. Rails or PHP, they are just tools. Thank you for sharing your experience.

Great post, thanks for sharing your experience. Congrats on rolling out a successful, efficient application.

Sorry that disrespect and immaturity are so prevalent in these comments.

Dear Derek,

It really is unfortunate that your post became a front on the PHP/Rails religious war. Clearly 90% of those who have replied here could gain a little wisdom from your experience if only they'd open their eyes and sharpen their reading comprehension skills.

I'd wager that most of us who understand what you are saying do only because we've had similar experiences.

Peace,
-j

Dear Angry Nerds,

You seem to come in three categories.

All of you I-could-write-your-site-in-two-weeks-during-bathroom-breaks wannabes are just revealing your own inexperience.

All of you mighty defenders of RoR's honor should look up the word "pragmatic". What are you taking so personally anyway?

All of you "yeah, rails does suck" jokers have missed the point just as completely. Try reading the article again without the notion that it was written by someone standing up for your personal language prejudice and you may learn something.

Peace,
-j

Ok, I have never used Ruby and never want to. It may be more efficient when it comes to "quick buildouts" but being a programmer for 15 years, I can't let a framework "do everything" for me.

I need to know the guts in and out and know what to expect and how to debug when something horrible happens. Yes, I know that "if" I learned Ruby, I would have a better understanding of how to troubleshoot it , but why?

Yes, it may be 100,000 lines of source code in PHP and only 10,000 in Rails but remember that "less code means more overhead". ASP.NET was the first to adopt this bloated behavior and Rails does similar. So when you think you are doing "so great" because you have less code than a PHP page, you forget that the Rails engine carries that overhead which I have noted several times in this thread "is slow but they are working on it"

So, pick your poison and do it well. Learn the ins and outs of your preferred language and share your positive experiences with others as they all have their own negatives.

Funny, just tried to post and got this:
fetch(/title/oreillynet/htdocs/blogs/ruby/templates_c/%%00^00C^00C7805A%%mt%3A52.php) [function.fetch]: failed to open stream: No such file or directory

I have had a remarkably similar experience..

I was hired to a job as a PHP programmer and we decided to go the "rails" route because we thought it would be a speed gain. After about nine months I mentioned that we could rewrite the entire thing in PHP and have it 'done' in a short amount of time but that is a hard sell after that much development. Needless to say I left the company who are continuing on with the rails development.

In the end no framework is really flexible enough to build a complex website, not a 'really' complex site that needs to do a lot of stuff and rails just has too much overhead in comparison to PHP.. I run about 25 PHP sites (some friends, some mine, some paid), some of which are under constant load and I have pretty basic webserver that handles it with 95% process free all the time. running 25 rails sites on the same server would bring it down. (I have banned rails from my dedicated server because it causes too much processor chew in comparison to the other sites running php or perl, and I welcome any mod-python sites, even django built ones as they have the same footprint as php)

Like you, after a year of rails and doing things the 'railsy' way my PHP code is beautiful now, though not fully MVC, I am using a hybrid with PHP-PDO which is still one controller per table but allows for some amazing flexibility.
I have to force myself not to use logic in templates so I am using my own template engine that I wrote (find it on my blog at blog.peoplesdns.com), and then here at work they are using smarty, which I have come to admire somewhat as it still really keeps code out of html.

All in all I think rails is great introductory language for the web, and is kind of like visual basic for the web it really gives you a foundation knowledge of a well thought out idea. PHP is more like coding in c (and I have ported a lot of c to php) and gives you the raw power.. With a good foundation the power of doing whatever you fancy is amplified..

I, like you, am glad to wash my hands of coding in rails but I am thankful to it for some of the re-training..

Couldn't agree more. Every flavor of programming trend that has come (and gone) in the last 10 years always fail to do what the fundamental language itself has done. For the life of me I still do not understand why ANYONE uses ASP for their websites.

Rock on, and thank you for everything!

Tim stated:
>I think one of the things PHP can't do and Ruby CAN is:
>reading the requeststream. Tapping into the traffic before it's entirely
>processed.
>I love this feature, it gives me total control of everything that gets
>send/uploaded to my server.

this is seriously false and misguided and is actually something stolen from PHP and then gimped up to be made 'simpler' .. it is one of the big flaws in rails imo.

if you look up output buffering in php
(here is link http://us3.php.net/manual/en/ref.outcontrol.php )
now.. in rails..
try to find out which output handlers your server supports, then select an appropriate one, have nested callback functions and return the value from one function in the middle..

In rails you would have to hack around in the core and jump through hoops all day...
in php, you can do that in a few lines (not counting the callback functions which are arbitrary classes or functions)

most programmers really like to know what is going on under the hood and having the ability to tweak the valves.. lot of you rails guys are driving your volkswagon and have just read the owners manual halfway and tell everyone they are driving a porshe.

@joeldq uhm... how do you think the output stream has anything to do with the raw request?

Next time you try to call someone out on a error, you ought to try to take the time to understand what they wrote first.

Really, why don't ya all just pipe down on the rails vs. php BS?

dude - in 2 years u coulda picked up java and implemented u'r app in a truely rich language. i feel 4 u though.....

Maybe joeldq was confused, but the person he was replying to -was- in error. See documentation on php://input which does give access to raw POST data.

It is all matter of preferences here but you cannot compare PHP(a language) to a MVC framework. Compare Zend framework, PHP Cake to Rails but clearly you are comparing apple and oranges.

Here is some comments to your point:

1) You talk about DRY principle. But then why are you writting your own framework when there are about 3 frameworks at least in PHP to my mind you could have reused (Zend Framework being a big one, PHP Cake or PHPTrack)... So you are already violating DRY by writting your own. Reuse what already has been done...Don t reinvent the wheel.

2)#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
you talk about retraining and infrastructure ? well, this is valid for any other language and definitely does not applies to rails only... Completely inaccurate argument. As soon as you change any piece of technology you will have to retrain people so you are comparing again something that does not applies just rails but the industry in general.

3) #3 - DON’T WANT WHAT I DON’T NEED
You don't use 90% of rails? If you use Model, helper, controller, routing, validation, plugins, migration, unittesting, functional testing, etc..then you may be already using 30 to 50% of what rails provides. So does your framework provides something clean for all of these? Do you also use an ORM your wrote from Scratch? You may not see the point of them but they help you refactoring and that applies to Rails or any Other PHP framework out there so it does sounds like you still have quite a bit of refactoring to be done.

Finally, you are never force to use everything in a framework. I am quite sure you are not using everything PHP provides and no more than 30% as well... Ang again, that would be comparing a language to a MVC framework. Do the same with other PHP framework

#5 IT’S BUILT TO MY TASTES
Right, PHP does not complain and so does rails if your turn off all the message you don t want to see. Also the Build to my own taste does really sound to me like much more possibles bugs and work to maintain it as it is barely used by a lot of outsider... So when you migrate to PHP6 and figure out how much it will cost you to maintain it on your own... then maybe you will see why Framework are such a big deal for others.

Then if you had 90000 line of code before and went down to 12000, this must have been really poorly designed before and makes me somehow wonder about your past experience and design skills at this point, as well as explaining the lack of appropriate judgement to compare PHP to rails.

@Bzzzzzzt

well.. ob functions are used to process the 'request' before sending to the client.. (good for second level templating as well)
I think you are talking simple 'raw' request which would be $_GET and $_POST in php or the request params in ruby which would not be a contention issue as the webserver itself is responsible for passing those to whatever language you choose..

As for the post, I have a whole lot of experience in both languages (admittedly more in PHP, but PHP has been around a lot longer) and honestly, I think rails is great for a lot of people.. but for any hardcore project you simply cannot use it because of the framework itself.. And people are throwing a lot of hardware at it trying to rescue their development but I think in the end (given my experiences and those of 'most' I know) it is not going to be anywhere near php, let alone perl or python.

Never underestimate the value of throwing out your old code and starting over (and two years additional thinking about your problem/program needs ;^)

Ken

I had a similar experience. My original implementation for my site was using IOWA. Then I ran into some limitations of IOWA and decided to switch to Rails. After working on it for six months(!) I realized I was spending more time fighting Rails than I should have been. SQL is a great language for manipulating data. Yes, keep all your SQL in "model" files but use the language that is natural for the problem, not yet another layer. Anyhow, I started a re-write in scheme (chicken scheme) and I'm 80% done and it is going fast. I think Rails just didn't jive with the way my brain worked but I loved the principles that I learned DRY, MVC etc..

I have a few excellent Ruby on rails books for sale...
Just my $0.02

"PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER"
This is an awesome piece of wisdom. I have been using the Symfony Framework to develop a project, and i think it's amazing what i can get with it.
Symfony is nothing more than Ruby on Rails for PHP. It has all of the advantages you quotes from what you have learnt with Rails, plus all the beneficts of PHP.

Excellent post. Though I'd say the bigger point is that developers should code in whatever tickles their fancy. There are benefits to every language and every development model. Work with what you know.

@joeldq

> well.. ob functions are used to process the 'request' before
> sending to the client..

And that's where you are very confused. The request isn't sent to the client. The request is sent *from* the client. The "response" is sent to the client. You are talking about the whole other side of the transaction.

The content in $_POST ($_REQUEST, etc.) is available *after* PHP processes the request. The person to whom you were responding was saying that having access to the stream *before* it is processed is what PHP won't let you do.

As was pointed out, php://input actually does give you access to the unprocessed POST data (but, to be fair, there have been lots of bugs reported with that mechanism over time.)

There are a whole lot of "web developers" out there who may have years of experience with language X, Y, or Z, but still haven't familiarized themselves with the HTTP related RFCs and don't know how to use the terminology correctly. I'm sorry to point out that you are, apparently, one of them.

I'm not a Rails programmer. I know some Ruby. I generally use PHP for web work though I still write CGIs in Perl (which I have used since '95 or so) sometimes. I'm not a fan of Cake, Symfony, or any other framework but I've had plenty of exposure to several of them. I'm language agnostic so I don't have an agenda when I point out that you are terribly wrong and Rails is, in fact, being used very successfully for many large sites with lots of traffic.

Please get your facts straight and stop spreading misinformation. You are doing a disservice to the community and to yourself.

I think you need to provide more concrete examples as to why Rails did not allowed you to make the switch completely?

"after various setbacks, we were less than halfway done.*"

various setbacks?? what setbacks?? please be more precise .. it doesn't give credit to PHP or Rails when you don't even explain what went wrong, what was impossible to do?

> I think you need to provide more concrete examples as to why Rails did not allowed you to make the switch completely

I think you need to come paint my house.

Both would take about the same amount of time and effort.

@Bzzzzzzt

thanks for your reply..
perhaps you are using an old version of PHP still?

this is probably not the place for this discussion, but for uploads. try using the file hooks with apc_fetch, ala http://www.ibm.com/developerworks/library/os-php-v525/index.html
or if you don't have apc compiled in or dl'd perhaps stream functions if you want to convert something as it is uploaded with fget(s) input/output
The $_POST value is available 'as' the request happens, not after.
I could provide many more example url's, virtually every "flash file uploader" uses a similar mechanism because you don't want someone uploading a zip file to a movie site.

anyway.. PHP 4 is discontinued.. php 5 has the hooks.
ob functions are used in ajax uploaders (ob_flush to push a percentage) etc I can go on..

output/input are virtually identical and can be used almost interchangeably.

upgrade?

@Bzzzzzzt

>I don't have an agenda when I point out that you are terribly wrong and
>Rails is, in fact, being used very successfully for many large sites with
>lots of traffic.

google?, yahoo? name a big one?
rails is still a baby in terms of languages and a lot of investors are wary of investing in a company that uses unproved technology.. This may not be important to you, but to many this is a deciding factor.

>Please get your facts straight and stop spreading misinformation. You are
>doing a disservice to the community and to yourself.

thanks!
however, I feel the real disservice is rails guys spreading around BS that people can rewrite every site in 10 minutes and suckering people into it (like the author of this article who got suckered into the mass-dementia that is rails)
My original point above is that a 'request' is a request, regardless of if it is a post/get whatever and saying that PHP does not have stream-level access to it is misinformation ..
If Apache knows about it, PHP can know about it at the same time..
Do you disagree with that?

I think Sivers is a bit odd. When he starts the big rewrite he does it in a very public way. As late as May 07 he gives away 20 passes to Rails Conf + hotel rooms. This is definately not stealth mode operations - for whatever reason he wants publicity and he gets it. Frankly, I could care less whether his site is powered with RoR or Assembly Language. So now RoR doesn't work out for him and he again makes a very public statement that he has again found religion and it is PHP. He states that he never intended more than a few people to read this post (let's see posted on a www.oreillynet.com blog - yeah that won't read by very many people!) Now that he is challenged to give some specific examples he says his Todo list is already too big.. odd, very odd.

I

Sounds like a poor design, and trying to force a framework to deal with this poor architecture rather than taking the opportunity to clean that up as well.

You claim to be knowledgeable in SQL, but I look at a cdbaby.com and see your comment about 95 tables, and my first thought it that you really need to study or take a class or something on proper database design. There is no reason a site like should require 95 tables.

There are good discussions to be had about frameworks/php/mvc/rails/etc with regards to thier advantages/disadvantages. But this isn't one of them. This has nothing to do with comparing languages/tools. This is just of an example of someone blaming a tool when the real problem is a lack of skill and knowledge.

Two years? A competent rails or php dev could knock this out in around a month in either php or rails. This is assuming they were constrained by a very poorly designed database.

#6 makes no sense. You can use raw SQL whenever you want, including migrations. It's right there in the Rails docs:

class MakeJoinUnique < ActiveRecord::Migration
def self.up
execute "ALTER TABLE `pages_linked_pages` ADD UNIQUE `page_id_linked_page_id` (`page_id`,`linked_page_id`)"
end

def self.down
execute "ALTER TABLE `pages_linked_pages` DROP INDEX `page_id_linked_page_id`"
end
end

I was one of the folks that replied to your early job postings for Rockstars. We would have had this project done in 6 months, less the nightmares you have apparently encountered. You were nothing but rude and condescending in your replies to us. Your website is ugly and I doubt the code is any prettier, especially if you're back to PHP! One lesson you might learn is: get a real programming team next time you want to do a project. You are a moron and the jackass you hired is one also. Don't get on a blog and rant about Rails when you obviously have no idea what you're talking about. You deserve everything you got, pal. Quit acting like you and your "RockStar" are so brilliant. You are an idiot.

i've been developing rails apps for almost 2 years and am also very familiar with asp, php and jsp.. RoR is way better IMO. With all the gems and plugins you can do pretty much anything and you don't have to do any 'twisting'.. and if you don't like a gem, but there's a java library you prefer you can always use rjb and use that library instead. ruby is alive under the framework and ruby is very powerful. truly object oriented (primitive types pfft), dynamic (build code on the fly and run it with eval), with yield you can pass a function parameters and code, and for a language that runs through an interpreter it is pretty damn fast (try some opengl code and you'll be suprised.. i know i was!).. not too mention that the interpreter still has much room for improvement. if you don't know the power of ruby it's time to step out of the dark ages!

Have seen the site just last time and now with the rewrite it more or less have adapted the simplicity of Rails design.

Whatever suits the project and the programmer should be the deciding factor on the language choice. You don't want to create/produce a site with you always hacking a language just to make it work. Instead use whatever it is you know (best) and start from there. That way you have spare time on reviewing the code rather spending time finding solutions to problems you already know the answer being on the other side. I rest my case.

I enjoyed the obscenities. they make you sound knowledgeable and most of all, COOL. ANTI. rock me, bro.

"I enjoyed the obscenities. they make you sound knowledgeable and most of all, COOL. ANTI. rock me, bro."
hehe, nice one Derek! guess the truth is a bit hard to swallow? keep your stupid comments to yourself and stop wasting space on the o'Reilly blogs! lot's of PHP postings on craigslist-- here's an obscenitiy-- You are a DUMB ASS!

only about 1 out of 500 programmers is worth a crap. 499 are full of crap. consider that next time you shop for RockStars!

The only thing this article actually proves is that you, my friend, are entirely incompetent.

@joeldg

I've been using PHP 5 almost to the total exclusion of PHP 4 for about a year and a half.

Look... the APC stuff is new. It isn't thread safe. And it doesn't do what the original dude talking about requeststream was asking for. Basically, by bringing it up, you've shown that you *still* don't know what you are talking about. Of course, coming from someone who says things like, "output/input are virtually identical and can be used almost interchangeably," this isn't really surprising.

> I can go on..

Please don't. You've already made your knowledge and skill level very apparent.

You just don't really have the experience to know what you are talking about. That's fine. You seem like a motivated kid. You'll get it over time... but not by posting here.

>I don't have an agenda when I point out that you are terribly wrong and
>Rails is, in fact, being used very successfully for many large sites with
>lots of traffic.

> google?, yahoo? name a big one?

Odeo and Penny Arcade come to mind. A List Apart, I think. Someone here mentioned yellowpages.com. There are hundreds really. Mostly they are fairly new, just like the technology. That's undoubtedly in part because the people running most large well-established sites already understand the wisdom Derek was trying to impart here: don't rewrite in another language just because you think it's cool.

> however, I feel the real disservice is rails guys spreading
> around BS that people can rewrite every site in 10 minutes

While there are some foolish young geeks-in-training trying to spread that message, they aren't the majority. And certainly they aren't fooling anyone but some of their geek-in-training peers.

> My original point above is that a 'request' is a request,
> regardless of if it is a post/get whatever and saying that PHP
> does not have stream-level access to it is misinformation ..

More... uh... huh? Maybe you could explain how PHP provides a stream from a GET request? (No, no. Please don't actually try!)

Sorry Joel, but you just don't understand the details of your own arguments. Which is why this whole little debate started between the two of us.

I'm glad to see this post, if for nothing else, to promote that some of the great design features hailed by Ruby on Rails are possible (and have been for a long time) in other languages like PHP and MySQL.

I just wrote a post about this on the SilverStripe PHP5 framework blog

It surprises me (well, not really) that this turns into a big flame fest on both sides when the actual point of the post was something any competent programmer should know: in a case where more than one language will do what you need on a given project, the one you can be most productive and effective with is the best choice.

Of course biases come into play ... but ultimately it is the end result that matters and if Derek ended up with something he can maintain and that does the job then why fault him? This is his *business*, after all, not some school tech project meant to make him "look cool" :-/

Personally I love Rails (actually, I love *Ruby*, which makes working with Rails so nice...) but to each his own. Congrats, Derek, on the new site!

@Bzzzzzzt

at this point, I am just enjoying watching what you fail to address in my posts and how you managed to avoid every point I have made to continue on with the "you don't know... you just don't know..."

the stream functions on all levels of access work together (perhaps not quite interchangeable.. more like working rather closely and interchange data seamlessly.. think fgets/fputs)

Anyway, I am glad you have your opinion and clearly it is a strong one, stick by your guns.. apc functions were just the first link off a google search and thread issues aside even using any other method you should have the hooks in php5 and if you feel like it you can write your own pretty in PHP.. again my point getting back to the original post with the guy spewing his nonsense about how PHP cannot do that.. and here you are trying to be alpha-geek and agree with him.. congrats you have your own lonely corner back just like in high-school...

Please, feel free to believe that PHP cannot do that..

As to your other points, rails sites being "fairly new" the other question is do you know how many rails sites you can host on a machine with 2GB RAM vrs PHP sites on the same box? Look that gem up..

your last point is the best..
if you have ever watched a steaming flash movie.. think about how your browser just might be contacting the other server without using a get request?..

you are seriously funny ...

Hi!

I just send a post talking about the restrictions of Rail-Like frameworks... RubyOnRails is actually Ruby made bondage-and-discipline, the same goes for CakePHP and PHP made bondage-and-discipline.

@joeldg

> if you have ever watched a steaming flash movie.. think about
> how your browser just might be contacting the other server
> without using a get request?..

The only explanation for this muddled rambling is that you are *still* confusing the request and the response. Although, now we probably have to add that you don't have a clue about Flash and how progressive transfer works. (Hint: it isn't the browser which is the client.) And I'm sure we can't go anywhere near a discussion of RTMP, right?

Sorry, but I'm not here to be your professor. Your coworkers can deal with your confusion. I'm done with it.

Have a nice day.

It's funny when people say that PHP is ugly and Ruby is beautiful.

Ruby is the partially aborted 2nd cousin of Perl and Smalltalk. Tell me how could that be beautiful?

thanks for the info! great to know such is the case!

but i must admit you seem wasteful in terms of LOC. i think your site (CDBaby.com) can be implemented in PHP in 80% less LOC than you claimed.

poor rails fans, hearing something bad about rails make them become soo childish :)

I like Ruby on Rails but certainly there are more PHP developers out there and PHP deployment is really simple. Finding a really good Ruby developer is very complicated.

Show your existing developers a PHP Framework like Akelos (a direct port of Rails), and they'll also write opinionated "beautiful PHP code".

With a big advantage, if you need to do code custom functionalities in a non-opinionated way, just drop a custom.php with your hand coded SQL and you're done!

Not all developers like to write beautiful Ruby or Python, some feel more comfortable with C-like languages.

BTW Derek didn't you know about Akelos, you could have saved a lot of time reusing your views and models and then coded those bits you missed on your custom dispatchers! And it is one of the only PHP Frameworks out there that is pretty well unit tested.

hello stumptown. bravo cdbaby. i have a parallel situation. I built a few MVC simplistic apps with Ruby (rails and not) and returned to PHP. The stuff i learned using various other schemes and practices are valuable, but in the end, the hype outweighted the practicality and usefulness for me. I applaud your strong stand amongst people who are sometimes sharp tongued about the next big thing. If your code library is mostly in PHP, it makes sense, given the maturity of the language and rabid core developers, to stick with it. I burnt several years as well, but not just with RoR.

Your article is great and I think you are right.

Rails is just a good framework, while PHP is a *big* technology. Maybe Ruby is a beautiful language, but when you want to build a website with Ruby, Rails is the only choice. In PHP world you have a lot of choices: libraries, frameworks ... Many of them is so much better than Rails. The PHP community is also so much larger than Rails community.
PHP is the best technology for the web.

I disagree with him too, but every Slashdotter flaming him is nevertheless a retard.

Both are my girlfriends. I love PHP since it is my money maker and rails .. since she is beautifull ... (have not generate money for me yet) ... I love both ... i love to see (cakephp,joomla) grows together with rails ... without envy ;)

I read this when I was looking at weather I wanted to learn Ruby on Rails or PHP.

I will certainly go with PHP.

Just based this on the number of Pricks in the Rails community.

I used PHP for years and understand that it could have been better laid out *after* switching to Rails at the end of 2005. But I'll never use PHP again, it's just too long-winded. RoR - you can get it doing anything, it's just how you approach it. This story reminds me of the likes of people who look at Linux for a bit but give up because notepad is called GEdit.

http://www.williamsf1.com is a RoR site.

Thanks Derek, for calling out that the emperor has no clothes. Rails does not work for projects which already have a legacy database schema. (Neither would Django or any kind of ORM).

That said, it's always useful to have a stab at working in a different framework because it simply makes you aware of the shortcuts you can take.

Hi,
It's a really good article,
because it comes to the point,
that what cares, is what you make,
and you can do that in any appropriate language.

I think I also have had an CDBaby account sometime long ago.

Thanks for having the guts to post this, Derek.

I think as all of us gain more experience in the constantly-evolving web-development world, it becomes clearer that the 'best' language for any project is whatever you're most comfortable with, give or take a little bit of consideration for easy-of-maintenance, continuity with developers, etc.

We're a 'technology agnostic' company, developing in PHP, Ruby, .NET and Java, and I can't see that changing any time soon. To each their own!

"I love SQL. I dream in queries. I think in tables."

>I read this when I was looking at weather I wanted to learn Ruby on Rails or PHP.
>I will certainly go with PHP.
>Just based this on the number of Pricks in the Rails community.

I have noticed this correlation as well, it also seems that the Mac crowd are all huddled around rails more so than any other and the Mac Zealots are worse than any other Zealots.. (not saying macs are bad, just that when some of these guys get preachy they REALLY get preachy)

Say one bad thing about rails or bring up the price of a mac and hope to be wearing a flame-retardant suit because it will all be your fault and you are stupid becuase 'rails so can do that..' or 'macs are better, look at our commercials'

glad someone else noticed at least

I wish this was a much more REAL look at the technical differences.

This could have been a Struts vs Spring, J2EE vs Struts, Symfony vs Django, Rails vs PHP etc etc. Just find/replace the tech name.

I don't doubt, for you, this didn't work but, you even mention "many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself"

Losing train of thought is a bigger setback to a project then learning curve at times.

I would love to hear Jeremy's rebuttal to this article before I make a decision.

In my almost 2yrs exposure and experience coding in Rails I am VERY VERY impressed with it. Impressed to the point that I firmly believe it's the technology you should START looking at as your solution and then evaluating if it should be REPLACED (in lieu of something better for your organization). I hardly ever look at all technologies FIRST and then whittle them away to my final pick. It's just not needed. ActiveRecord, Migrations, Fixtures, Testing built in the Ajax integration... says a LOT.

Just my $0.02.

reading through the comments here has been interesting

my favorite is the rails guy who thinks you cannot stream a get request from php. saying that is what i do for a living i think i might have myself a new .sig file he should look up piping requests through php via htaccess, can rails can do that? you can even control the bandwidth usage per user or connection from php

the article really touched off some rails feelings

choose your tool that best suits you and try not to become too attached to it because something new is always around the corner.

Damn right. I'm going back to FORTRAN

Hey All,

I always felt that RoR was great for CRUD sort of websites (forums, forms and adding content), not for applications.

Most larger websites are 'application allike' RoR is not ment to do that work.

Ries van Twisk

@Bzzzzzzt

>Although, now we probably have to add that you don't have a clue about
>Flash and how progressive transfer works. (Hint: it isn't the browser which
>is the client.) And I'm sure we can't go anywhere near a discussion of
>RTMP, right?

RTMP is for Adobe flash media server (a paid product), which has nothing to do with this discussion about PHP. Slinging around acronyms won't make you appear smarter, especially when you are using them out of context.

try: http://www.flashcomguru.com/index.cfm/2005/11/2/Streaming-flv-video-via-PHP-take-two

>Sorry, but I'm not here to be your professor. Your coworkers can deal with
>your confusion. I'm done with it.

Oh thank god, you are not to ever lecture anyone.. especially about this topic.

And as well.. I 'am' done with it as I don't have time to deal with what is clearly a kid who just wants to be a naysayer and trumpeter of his own ego..

I think this whole Ruby on Rails is over hyped
Personally I use Python a lot
Looked at no of different web frameworks and only liked Spyce, when tried to use it problems arise that could no be solved unless you can understand entire source behind it
At the end it took me a week to implement my own framework, simple example:

The time is

final product can handle database with SQL and POST to handle forms, sessions, login forms, etc

Lets see here.... I could:

a) continue to bog my company down trying to shoe horn my existing data and functionality into a cool new framework

b) go back to what I know and made me multi-millionaire entrepreneur running one of the most successful online businesses around

Be careful how you answer because the decision you make will affect your future and that of your 100+ employees.

Kudos Mr. Sivers!

A lot of media agencies in the UK understand exactly what you've been trough, believe me. That's why no one in the industry is using Rails or Perl to develop website.

[Huge Rails Fan] Okay. What you have said is true. Php can do anything RoR can. RoR does it more elegantly but there you have it. My question (you can reply to keynan@bykeynan.com) is what were you trying to get rails to do that gave you such trouble?

great article! Always choose the right language/tool or personal preference for your projects. I have never used ruby(on rails), nor will I try it. I'd rather use PHP, J2EE or ASP.NET. Many people claim that you can write better code with ruby(on rails) hence you should use it. well, you can write good code in php too, it's not the language(or framework) but the programmers themselves that decide the quality of the code.

You're stupid! But, good luck with your PHP.

If you not know Rails, you not have to say about this...

I like cdbaby.com. It's FAST and I was there to search & buy music, not to learn latest Web 2.0 features.

I agree with #6 let the SQL database do the best with clear SQL queries.

despite the flame wars, there have been some interesting things said here, over-all I enjoyed the discussion.

I have learned quite a few languages over the years... including 6 different versions of Assembly; RISC, CISC microcode. etc. actually my first programming experience was binary punched in through the front panel. For awhile there, it seemed that the lifespan of a computer language was about 3 years, exhausting to say the least, I even took a whack at writing my own.

What I have found is that it takes about a year to become proficient at a computer language and much longer than that to become really good at it.

There is a huge gulf between theory and practice. What looks good in a CompSci classroom often does not work in the real world. People who haven't gone through the process of implementing a really large *real-world* project, and dealing with all the problems that come up; lack the experience needed to offer more than the most speculative of opinions about your project. And even with that background, most of the discussion about your project is limited to conjuncture based on the small amount of information that we have been given. Isn't it great that there are so many experts here who have offered you their sage advice. ^-)

----------

As you discovered, it is good to learn different languages, you get different perspectives on how to approach a problem. And the knowledge that you take away, helps you to be a better programmer in any language. The same is true culturally as well.

You will probably enjoy reading this article:

"Teach Yourself Programming in Ten Years"
http://www.norvig.com/21-days.html

Tackling a huge project for your first experience with a new computer language is not necessarily the best learning strategy, but that never stopped me from trying it. ^-)

I don't use C (or assembly) anymore because I got tired of reinventing the wheel every time I wanted to do anything at all. On the other hand I avoid do-it-all frameworks because you get tons of bloat that you didn't want, and you are at the mercy of someone else's bugs. And every time that you add a layer it costs you performance, sometimes the performance trade-off is worth it, computer cycles are cheaper than dev cycles, but often it is not, the program still has to deliver real world response times and computers still aren't free. Then there is the question of flexibility or the lack of it, a framework is optimized for doing the things that the architect conceptualized, if you want to do something different from that, the inherent assumptions of the framework fight against you. (consider: Vista, 9gigs for an OS!!, slow as a dog, and buggy as heck, and late as h*ll, created by the biggest framework of them all, if frameworks are so great.... WTF?)

But for me the bigger issue is the agony of dealing with other people's bugs, and the more complex it is, the more bugs it is likely to have. I find that the less I rely on other people's code the more likely my program is to work. If you think this is an arrogant attitude, then consider that a major product team at Microsoft started out using MFC and then abandoned it and rewrote their program without it because they found that MFC was too buggy and too slow (Meanwhile M$ continues to heavily promote MFC for use in their competitor's products, makes yah think huh??). The thing about bugs is that if they are your bugs, then you have the opportunity to fix them, but if they are someone else's bugs you are stuck with trying to find away around them. PHP has proven to be remarkably bug free (oh sure, the change log is full of bug *fixes*, but as a practical matter, in the real world I have only ever hit one of them, the fundamentals are solid).

It's important that a computer language be translucent, the goal is to provide the means for translating your conceptualizations into an implementation that the computer can understand. Some tools can help with organizing your thoughts. But at the end of the day, it's all binary anyway; and most of this talk about "my language is better than your language" is just so much rubbish.

There is also the always overlooked consideration that people's brains are wired differently, left/right brain people approach things differently. Some people are very numerically inclined, they love math equations and the terseness of C. At the other side are the more poetic/artistic/spatially inclined. The terseness of C drives them nuts and they are much happier with the fluid prose style of something like VB6. Yes, I know, ~real programmers~ smirk/sneer at VB6; but it was a good enough language for gui apps, much more productive than using c++ for gui apps, and drove corporate America successfully for many years until M$ decided that they weren't making enough money from selling it and decided to abandon it. Visual Fred is a sop, to disguise what they really did. VB is dead long live VB! and the emperor is wearing no cloths.

I like PHP and these days, use it for all my web based apps, I even use it for writing command line programs and special purpose servers. For a c flavored language, PHP does a fairly good job of straddling the middle ground of the left/right brain approaches. I find it to be a very translucent language that does a good job of getting out of the way and enabling you to get the job done. But this is just my personal preference, other people make other choices, isn't it great that we have so many choices available.

And I especially appreciate that open source programs such as PHP and Ruby are in it for the long haul, not subject to the corporate whims of some marketing department or the monopolistic requirements that prevented VB6 from being cross-platform.

I suspect that a lot of the criticisms being leveled at PHP are from people who are unfamiliar with it, especially with the redesigned object handling in version 5. It may not have all the highfalutin gizmos of CompSci dreamland; but it's object model is plenty good enough to do the heavy lifting that is needed in the real world.

I've seen plenty of ugly code, it is written in ~every~ computer language. We all start out writing ugly code, and then hopefully we get better at it and learn to write less ugly code. But meanwhile, we hopefully managed to get something useful done. It sounds like you have gotten a lot of useful stuff done, far more than most people.

Did you make a mistake? No! You simply enrolled for a couple of years at an expensive University, and came away with a lot more knowledge about how to accomplish your goals. I'd call that a huge success!

Keep Learning Keep Growing, I've been at this for 20+ years and I still spend about 30% of my time on study, I'm just a slow learner I guess... :-)

-- Erik

Hahaha... I love point #7. I also tend to look back at my old codes and keep thinking how much better I can redo my programs. I will ask whether I can write them better or write them in a better language, though I may not able to do it. Sometimes it is better to rely on a familiar language/tool to the problems fit rather than fit the problems with another language/tool.

I coundn't agree with you more, but I think ruby & rails are cool. Maybe there is no good reason to rewrite a system with ruby & rails, but they probably are good and efficent tools to develop a prototype system rapidly.

trying to read through the comments but the guy who is arguing about the fact that php cannot stream must be the rails guy who wrote that first post that was quoted. no php coder responds that way on any php site so I think he is a ruby guy playing "php guy"

otherwise, good constructive criticism on the article and hope to see more in-depth analysis later

many people are considering rails, but few want to take the time, it is a shame on both sides, one for the community and one for ruby to let mod_ruby go to pot and leave all the developers scrambling for something/anything that might work and let them compete with php.. first apache, then lighty (sp) then mongrel, then nginx (the russian one).. at this point rails guys are looking the fools switching web servers every other day trying to make it work

dedicate resources for mod_ruby and they will come, leave it as it is and no hosting provider with half a brain will touch it

First of all I'm a database-centric person -- one reason being that you can use any number of reporting packages to produce the reports management wants.

For those who plug Java as the way to go, it can fall down in a multi-platform environment when the hot off the press packages required by your fancy Java app can require serious system upgrades on older OSes.

PHP has the coverage that the Java approach does not and I know of one ISV with a system firmly stuck in half-implementation.

Thanks for the positive remarks about Rails and how it made you a better PHP Developer! Pick up the best hammer you know how to use and build the house! For me, I've decided to learn Rails.

I think most of the flamers in this comments list obviously don't get it. Derek is running a successful company. He makes his decisions based on business needs not some religious following of framework X or language Y. How many of you flamers actually run a business, a successul one at that. Maybe you don't like the site. Other seem to disagree, given its success.

It also seems like you can't read. Derek clearly said he likes Rails, but it simply didn't work for him. Given that the developer he hired now works for 37signals, then he surely most know his Rails.

ok, so you've got the code sorted, now how about spending some time on design? cdbaby.com is one of the blandest sites I've ever set eyes on...

While 'geek' as become a badge of pride recently, part of its definition is 'socially inept, underdeveloped', and this is what I see in more than half the comments here: immature rantings of a quasi-religious nature.

Robin gets it that here is this techno-leader who bought the latest hype but is driven by realities to stop, look, start over, and deliver something that works instead of a mess.

In case no one else remembers model 1 JSP, EJB 1 and 2, there were a lot of rewrites of perfectly functional applications and sites that both took forever and only produced steaming piles of non-performing crap.

Another way to look at what Derek is saying is that, at long last, we are approaching a convergence on software engineering principles and understanding that transcends language and implementation detail. That's the most important point, and most of the jejune, socially unskilled, narrowly educated technocrat responders to this post seem to have missed it entirely.

Thanks for sharing this experience. By the following quote:

"twisting the deep inner guts of Rails to make it do things it was never intended to do"

Its pretty clear that you chose the wrong tool for the job. Our shop is all PHP, so I'm no rails fanboy (tho I do enjoy it), but if you start with the wrong framework for the job, you're doomed.

To me the question here is not really about PHP vs. Rails/Ruby, but about Frameworks vs. Not using a framework.

A framework forces you to use its own conventions, which can be a good or a bad thing, depending on what problems you're trying to solve.

Your reasons (except 4 and 6) show that your planning was awful. There is no php or ruby. Just your awful planning.
Reason four shows lack of experience about ruby. All dynamic languages in web like perl, ruby, python or php are in one class of performance. It means that if you get too slow (two,three times or more) results (comparing to the others) it's just your faults or lack of experience in that language.

Sorry.

No silver bullet...
Write one to throw away...
This article is just confirming what we know about after 30 years of software development. Those who haven't learned it the hard way will do do in the future.
And one class-per table is not good OO programming, good domain modelling, good system design or good database design. Frameworks (and anyone's initial architectures) are ultimately always doomed to run up against limits - the only question is how soon and is that within the expected lifetime of the project.

I think you have to do what best fits your style and organization. I don't think any language is the end-all, be-all for a true "enterprise" solution. I think Ruby is a great language, but it is not a solution to every problem.

In my opinion, many developers have found comfort in Ruby that they have not found in Java, PHP, Coldfusion, C, or Perl. I have favored Java over C just because I didn't really mature as developer until I really learned Java. I may not really know C enough to appreciate it or maybe I wasn't doing the right type of projects when I worked with C.

Maybe if you were re-writing everything from scratch, including your data model and supporting applications, you would have found Ruby to better suit your needs, maybe not. People get way too wrapped up in the language wars and really do not understand that it is not about the "how" but the "is it done yet?".

Seems like most people miss the true point: Derek isn't a trained, experienced programmer.

He's making it up as he goes along, and in the process, he's going to stumble around quite a bit. Having started with PHP, he will always prefer it until he grows enough to grow beyond it.

In the mean time, he's learned some new patterns and some new disciplines, and has learned to use them in the language he's comfortable with. This is good.

The truth of the matter is that Ruby on Rails isn't the advantage, Ruby on Rails as a *PATTERN* is the true advantage. As he pointed out, he learned new things from RoR (new patterns, new ways of doing things) and applied them to his existing girlfriend.

When Derek gets far enough along the growth curve, he'll realize that he's at a point where he is no longer working and thinking in "The PHP Way". At that point, *THEN* he will be in a position to switch to the language or framework that most naturally fits his new frame of mind. But not until then.

Or to put it another way: My new girlfriend isn't better than my old girlfriend because I'm different. My new girlfriend is better because now I know enough about relationships, and have acquired enough wisdom, to find the girl that best fits my needs.

Maybe you should have used something like Catalyst framework, it allows to choose method of DB access.

First to Derek: Good post, good points. The comments here pretty much show why I don't really like the Ruby community.

And to the commenters who think they are able to estimate how long they need to rewrite Derek's site in $their_favorite_language just by looking at the frontend: Please don't forget to leave your full name and location. Your future employers will surely be as impressed by your professional experience and attitude as I am.

PS: Personally, I hate PHP. But I can see a valid argument when I see one. And since his weren't about PHP vs. Rails/Ruby anyway...

You should ask yourself why you couldn't use Ruby and if you are better off with "settling for" keeping PHP. Your reasons seem to center around PHP as an existing environment and that's like saying "I'm going to use X because I'm already using X".

PHP is great and Ruby is beautiful - either is suitable. If you between 2 and 5 coders, a long release cycle, and all of your developers know every line of your code - PHP is great. But you have to ask yourself: By coding everything in PHP and not abstracting things like SQL, have you personally tied yourself to the code base when you should be working on more important things like figuring out how you are going to meet the demands of your competitors?

If you decided to use PHP, did not abstract SQL, and have between 2 and 5 developers, you will surely struggle with security and internationalization, and your competitors' future offerings will easily pounce on your products. You may not realize this until you are already struggling.

"twisting the deep inner guts of Rails to make it do things it was never intended to do"

One of which things would, I suppose, be "fitting an existing database schema". The sites I currently work on are, like yours seems to be, built around the database, which itself was built around the requirements for the project. Most of the heavy lifting is done in SQL, the scripting language really just iterates through returned queries and formats the results. It may not be buzzword-compliant, but it works well and leverages the particular strengths of the database and the chosen language to good effect.

If I wanted to use a framework for these, I would have to throw away everything and redesign it all from the ground up, to fit the framework.

Kind of like trying to change the oil in my car when the only tool I can find is a butter knife. No amount of "mad skillz" is going to make that tool work for the job I need to do. Ever. On the other hand I *could* put butter on toast with a 5/8" wrench, but it would be a lot easier to use the butter knife for that job, if only I hadn't busted it trying to change the oil in my Pinto. :)

I understand the SQL oriented approach and I have to say that it has worked very well for me on many high throughput web sites. Too much of this OO style tries to hide the SQL with things like Hibernate and other SQL Dodo tools. To write a database centric app and not understand the DB is simply silly and will end up with innefficient code.

Who cares if the front end is cool and OO if the DB runs like sludge because it was coded through some sort of persistence layers?

I am a big fan of logic in the DB - it is efficient and tidy and produces solid websites if you have a decent SQL coder on the team.

Hey Derek, very interesting read.
I was curiously reading everything about your rails experience since you started blogging about it.
I had a similar experience.

In the end, I felt that Rails contained too much "magic". I'm terrified by frameworks I don't fully understand, no matter if it's the MFC or Rails or Django or Symphony. In the end, I feel it is better to exactly understand what each line is doing, even if it means more typing. Under pressure, the last thing I want is having to fight with a framework or with an IDE.

An interesting article, but I think it possibly has little to do with Ruby, Rails or PHP. His app doesn't look that complicated, especially if he could rebuild it in PHP so quickly, so how come it took Jeremy Kemper 2 years to not complete it? For me, i reckon that with a bit of digging we'd discover the true business complications and hindrances that prevented the project from being a success (and he hinted at them) and they weren't to do with chosen programming language or framework.

I reckon the business didn't give the project enough attention and after 2 years of little progress they got fedup, panicked, maybe Jaremy left and they threw it together in a language they understood. They then used the language as an explanation for a delayed project, when it was probably all about ineffective business practices - Yep, the same ineffective practices that we all face each day.

Also, in my mind, a project should be dropped waaaayyyy sooner if it's off the rails (no pun intended). If it takes you 2 years to realise a project of this size (pretty small) is on a path to failure, something else is broken in the business, and it isn't something PHP or Ruby can fix.

Also, it's really easy in Rails to create APIs on top of existing database tables and Rails is best mates with SQL - it's just as easy to use SQL in Rails as in PHP.

Andy

Where is DHH now? Rails can do anything!

I am a software project manager. My job is to help my client make more money.

The most important rule is

"A good development methodology is one which delivers a working product with the people you have".

Code; be it Ruby, PHP, Coldfusion or Java is the smallest part of the problem. The use of simple, standard frameworks is necessary to ensure the business is protected against the loss of key developers.

Ideally there is not a key developer.

Two things: First, this sounds like more of a problem with any rewrite project as DHH recently pointed to on his own blog. Agility was what was needed. Looks like the project got sort of sidetracked, since the rewrite wasn't as important as server failures, new projects, etc. Understandable. Then, when it was just you, you tore into what you knew best. Also, very understandable.

To use Rails, you have to change the architecture of the site. I'm no web app genius like the 37 Signals guys, but 95 tables for CDBaby? Say it ain't so, Joe. I looked over the site and can count maybe 20 outside the order system itself. Seems like that is part of the problem. Or was the problem. Doesn't matter now. You got it how you like it, so there it is. What else could you ask for, right?

Derek,

As a fellow O'Reilly blogger (over on the XML side), I see you've run afoul of the great zealotry beast - "You're an idiot if you don't like FOO technology because FOO rocks!!". Been there, done that, got plenty of t-shirts.

PHP started as a pure procedural language, and has been migrating to an OOP form for about the last six years. Its current OOP syntax, while a little messy, is not that dissimilar from Ruby's, and if you are in a position where you can work from scratch with the most contemporary libraries, you're probably developing an application that's now more OOP aware. Most PHP code is messy because it was either transitional or it was written by programmers who didn't come from an OOP background (quite a few of those out there, even now), not because the language itself is inherently bad - it simply has a longer per capita legacy than Ruby.

I think the best takeaway from your article is the fact that you spent some time in Ruby-land which gave you a much stronger exposure to OOP, MVC patterns, distributed design and the like, and took that back to a language that you were comfortable with and were able to apply the lessons learned in an idiom that you were more comfortable with.

I started coding about the time that C first came on the scene in a big way, and have learned (and forgotten) entirely too many different computer languages. After a while, you come to realize that, while languages do and can impose their own idiom on your development, ultimately what matters is good architecture, good documentation and intelligent design. Many of the Ruby commentators here have come to Ruby as their first or (more typically) second language, and they are convinced that it is the salvation of the world's problems.

Nope. Ruby's got a nice clean syntax rather than having OOP tacked onto it like a lot of languages (from C++ on), and for some websites it works remarkably well, if the alignment of the site is consistent with the alignment of the development community. It gets a big boost by incorporating JavaScript on the front end, and ActiveRecord is kind of nifty for people who are more interested in data abstraction than in data performance, but overall, it is, in the end, yet another programming language. As people try to push it to do more things, it will become fragile, complex and error prone, in the same manner that all frameworks do, in spite of the protestations of its enthusiasts.

A good craftsman may own many tools in his tool-chest, but only one of those tools will fits his hand like a hammer with the handle worn subtly away by years of pressure from his fingers. If PHP is your hammer, then it is what you are comfortable using, understanding that Ruby is always there like a fancy ball peen, to be pulled out when called for, but that doesn't necessarily fit your hands personally quite as well.

I just wanted to say: I completely agree with you.

In fact, I followed a near-identical path. I, however, started out with a Rails application. I was frustrated by its speed and the need to constantly hack up Rails to get things to work correctly. I am now in the process of recoding it in PHP and it is coming along GREAT. Everything fits together how I want it, it is much faster, and I get to write my own SQL without layers of superfluous abstraction.

I'm really glad you wrote this!

I feel a little ashamed that all these language hot heads are attacking you for having made the decisions you have made, even though they were clearly advantageous to you... I have gone through the same path as you, and have learned some stuff the same way as you have, and I am extremely happy with my primary language right now. It has a lot of advantages _for_me_ that the other languages I tried in the past. I'd be stupid to actually list what languages I am talking about, lest bigots start asking me why it's better so they can attack my arguments.

Anyway, you know the saying, to someone that only knows how to use a hammer, every problem looks like a nail. The more tools you have, the better output your work provides.

Cheers, and don't take the language bigots seriously.

You can take this however you want but I have developed web apps in ColdFusion, PERL, ASP, JSP, ASP.net and PHP. After using all of those I prefer PHP by a long shot and it comes down to this....

I read somewhere that there are two kinds of programmers...those that work best by plugging pieces together and those that work best by writing their own pieces. For me I prefer to build my own pieces because when the provided pieces don't work you tend to spend alot more time navigating around them than if you had built your own. But is appears that the "pro-piece" crowd believes you are doing something wrong if the pieces don't work for you out of the box. Now being an open source fanatic I push for the use of this technology because you can modify it and don't have to bend your process to meet the technology. So why then would I pick a language where you have to do just that?

I can relate to this article because I had a similar experience. I took a job doing ASP.net and thought it was ok until those pieces didn't do what I wanted and I had to go out of the way to get results. The more experienced .net developers around me confirmed that I was following best practices as well as various articles. One day I got fed up, installed a LAMP server on my desktop and recoded our entire 40+ file data layer(1 object per table) in 1 single 200 line php file. I showed them and they didn't know what to make of it. But in the end the framework of .net taught me some lessons that I brought to PHP and made my code even more powerful. There is a reason though that I was able to bring my lessons from .net to PHP but not the other way around and thats because PHP is flexible.

PHP is a language that makes a deal with you. It says "If you are disciplined enough to write clean code I will let you do things that other languages won't by not enforcing ANYTHING". Thats somewhat of an exaggeration but you should get the point. This is where the split in piece and non-piece people occurs. Piece people scream about ugly code because they abuse the simplicity and freedom of the code and build a house on twigs. The non-piece people take that same power and freedom and build a foundation...often similar to frameworks like .net or rails but customized to their own style and needs. When they hit a roadblock with their foundation they can tweak it and make it better rather than look for another way to use it or abandon it altogether. But with PHP that "deal" allows you to build a powerful framework with very little code most times. I'm not saying you couldn't build it with other language and Ruby standalone could very well be better at it than PHP..I don't know. But the people that flock to Rails, .net etc. normally either can't or don't want to build there own. And to be fair I don't really care for any of the PHP frameworks either. But it should be noted that both .net and Rails seem to have been mimicked in PHP and without much complaint which again is a testimony to the language.

In a sense the developers of Rails and .net are really getting over on their users. They are developing frameworks and probably doing just what the good PHP developer does internally but are pushing their particular way of doing things on to you and not leaving you with a real way to get what YOU want out of the code. Its very generous of them to build these frameworks for those of us that need it. But some of us can and prefer to build these things with a raw language and especially one that will let us cheat if we play nice.

Its not the language, its not the framework, its not the code.

Its the end result, its what the customer uses and its about how you maintain and keep it running.

The people who shop at CDBaby can give a rats ass that is CDBaby is RoR, they just want to shop and have it all work. Derek identified problems with RoR and his needs. It only proves that not every tool is right for the job.

Derek makes some points about RoR that never seem to be mentioned in all the hype over RoR, but it was great reading it here.

He says, "“Is there anything Rails can do, that PHP CAN’T do?”

"The answer is no.".

Derek is hitting the proverbial nail right on the head. I know al the RoR people will start talking about ActiveRecord, Migrations etc. etc. So what?! Smalltalk80 was one of the most amazing OO langauges that had things no language has or will be able to do.
I ask: When was the last program you wrote in SmallTalk?

All the RoR people can jump up and down about how wonderful Ruby is and how great Rails is. But its a darn difficult framework to get your arms around and develop something quickly. It requires a couple things that most scripting languages like PHP don't require: A massive commitment to the philosophy behind its architecture. If you're totally commited, you're not going to get the benefit. The beauty of PHP is that there's no moral commitment to a philosphy, you can just fire up an editor, start coding and within seconds you have HTML pages with scripting accessing databases, etc. etc. There's something to be said about that simplicity. Is it a perfect model to code, and can get it get sloppy? OF COURSE. But I've seen Java and C++ projects grow to epic and management proportions, and I've seen some very tight and clean Perl or PHP products which were very well maintained and updated.

With RoR, I always go the feeling is sort of like the 'wizard behind the curtain' with a lot of the code generation and really, Derek's point is that all of that "stuff" is laid out for you in PHP in different projects, class libraries and utilities, or you can homebrew your own...

If Rails is successful at something, its generating a great buzz and kicking off Web 2.0 so we all can start making more money. Go RoR!!

People reading this might be too young to remember all the programming hype around OOPS in the 80's, or around AI hoopla of the 70's, or even going back as far as 4GL's with PowerBuilder. What about VB, or do people even remember how much SmallTalk was suppose to save the world..

All of its just hype, and as programmers we're all about what is hot now and what is going to make us do more with less.

Simply stated: with PHP5, Smarty and (you pick) a framework or no framwork, you can achieve 98% of what RoR does and build a perfectly great application, just as fast and just as functional. The question is, is the other 2% really worth it?

I've come to the same conclusion as Derek, its not.

When I see applications like FaceBook, Digg and all the others who are based on PHP, I feel confident in knowing that I'm not the only developer who feels that RoR is just another tool and not a paradigm shift that I have to be jumping on quickly before I miss the train.

I think I know why you switch back to PHP again.
Is it because you use your old database with rails ?
I was trying using rails with my old database tables (i was using oracle with vfp at the moment) and then my boss ask me to make a web version. When i come up with rails database table convention, i got weird and it would become a trouble for me some day if i have to follow the rails convention.

For me, it would be good if i wrote a new application with new database using rails. If it is old software, let it be ... why you need to rewrite something stable with something new ? If you want to use rails, write entirely new with all new database tables (you can transfer the old data to the new one)
CMMIW.

regards
adwin.
www.kompani.net

"Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well."

If you had used a decent IDE and a framework you may have saved 6 weeks and be done in 2 weeks. Be smart and don't waste time reinventing wheels.

Welcome back to PHP

What an inspiring article. U've never worked with Rails, but this inspired me to clean up my own PHP house.

What kind of article is this?

The only point I agree with you is the #2. The rest of them are about your thoughts and your feelings about using a programming language. You neither talk about performance, nor scalability issues, nor server expenses, nor server requirements... definitively, you do not talk about any actual problems (if they can be called so) in rails applications.

Your reasons to come back to PHP are part of the reasons why all of us (rails lovers) have got away from PHP. Do you really spend 2 years of your live programming in Ruby and thinking in PHP?, what a waste!

Bye and good luck!

I seen your website. If you put 2 years to write the software then really you need to think about your programming skills. The site is not appealing and it seems that you been confused for those 2 years in the programming logic, OO concepts and databases thats why it was failure. A language can't be responsible thats what I say.

I've never used PHP, but I'm more then willing to accept that in a given environment, with a given set of requirements and constraints, and a given skill set, that yes, PHP may be the right tool for the job.

What this post tells me is "there is no silver bullet" or "golden hammer".

Thanks for the reminder. I don't think this point can be made often enough.

Paul.

From your explanation, it didn't seem like you actually did any planning for your site. It seemed like you started coding from day 1 and continued for 2 years. Many projects fail because of poor planning and heads-down coding that does not consider good design. If you had used a methodology, such as RUP, which can be tailored to your specific project, you might have started a Risk List at the beginning of the project. The Risk List might have listed problems with integrating the "current stuff", and you could have focused on these problems and solved (or possibly not solved) those before getting too deep into the project. Many times a little planning goes a long way.

Thanks for the article Derek...I hope the flood of childishness in the comments doesn't make you regret posting it.

The comments are really the Internet writ small: tiny jewels of wisdom buried deep in a mountain range of crap.

Anyway, continued good luck with your site.

Blog post about this: http://tinyurl.com/2fwdle

What I'd like to know is how you "switched" to Rails in the first place? In particular how did you go about un-learning your PHP skills? I'm guessing you didn't simply because you can't.. not if you were any good to start with.

I laugh out loud every time I hear someone say they "switched to Rails" or in your case you "switched back". I know a bunch of programming languages and frameworks including PHP and Rails. The knowledge of those tools is accumulative, not exclusive.

You can re-implement an application in an alternate language or framework, but you can't unlearn something. Your story is pointless. You never switched to anything, you just wasted two years of your life is all.

"But as far as alot of RAILS or other ORM users are concerned, pulling back rows from individual tables and "joining" them in memory in a very inefficient way is somehow beneficial."

Hey Bob. I don't know if you're still reading this, but yes, what you describe is very inefficient. Fortunately, ActiveRecord includes features like :include, :join and :conditions which allows the database server to do all the joining and filtering.

The core tutorial for Rails is building an e-commerce site d'oh? What were you doing for 2 years? I looked at the baby site and saw nothing difficult. I recon I could build it in rails in a month or so part-time, probably quicker full time.
All you've done is damage your credibility. I wouldn't consider working for you and I bet there are a lot of very good hackers out there who have crossed you off the list.
I like PHP for small projects where reuse isn't an issue - you can just hack something together very quickly. It's a bit like C used to be, once you get past a certain level of complexity you've got to be very disciplined. Rails makes you be disciplined, and has testing built in.

Great write, I definitely agree with you.

I'm a PHP programmer myself, who knows Ruby beats it, and thinks Pythons beats the crap out of the two. But that doesn't matter.. I think your article was making the point "It's YOU --programmer-- that matters most" and I definitely agree. By looking at Python and leaning over Ruby, I've became a better PHP programmer.

You have missed something though, if every programmer did the same as you did since, say, the 80s, there wouldn't be Ruby nor Python nor PHP now. I think unless we persuade every sight of hope of having a better tool, a better way, a better plan, we won't see what's next.

Btw, I've used your website before, got some kick-ass music from there and it's totally cool!

C'mon guys, the best language is the one you know better. Some are easier to do some stuffs, others are easier to do another stuffs but good and bad programs can be written using any of them.

If you tell me PHP is bad I will believe you are bad PHP programmer because I've seen great things in PHP. The same about Perl, Python, Ruby, C#, JSP, ASP and so on.

It's like to compare guitar, violin, harpa...A great guitar player may be a shit on violin and vice-versa...

Derek,
Very well spoken sir. One of the things developers could learn a thing or two from, is unbiased business opinion about development environment. Too often, geeks think in egalitarian terms of their preferred language, rather than 'do what you need to do'.

I agree with John: "Great write-up. Foul language is unprofessional."

Derek - religous wars aside, the original re-write failure doesn't sound like something based on Rails or Ruby anymore than the success was based on PHP.

Reading between the lines I'm seeing some issues with the project itself:

Big bang development: everything in the company had to be replaced all at once. I don't think I've ever seen this work anywhere. This is probably the single largest problem.

Scale and focus of effort: It sounds like in your 85 person company there was ONE Rails developer on the project and that there were a lot of distractions.

Wrong application of tool: It sounds as though you were trying to build a Rails app on top of an existing DB structure. In principle this is do-able, but DB structures naturally evolve as part of an application architecture. You probably missed out on a large part of the “convention over configuration” value.

(apologies if I've misinterpreted anything)

Anyway, sounds like a terrible experience and a great case study for an O'Reilly book on "Software Project Failures in a Nutshell".

Finally, you're a braver man than I to have written this :)

Talk about walking into the lion's den...

I think that a lot of the people that have posted comments on this have made the mistake of assuming that CDBaby.com is nothing more than what you see in the frontend. That's like assuming that because a Boeing 777 looks like a big silver tube that I could make one if I had enough tinfoil. Oh wait... There's a lot of inner complexity that I can't see on the outside! So, shame on all of you for deciding that you're such hotshots that you could do the same thing in 8 hours, and probably rewrite Google's search algorithms in 50 lines of Ruby code while you're at it. Let's see you do it, then we'll talk.

Secondly, we are also not privy to how the project progressed... Perhaps Derek was inflexible about changing functionality/structure/design to fit well on top of Rails. Rails is, as we all know, opinionated software. If you don't like the opinion, you're not going to do well with Rails as a framework. I think that's clearly defined by the fact that bitsweat was going to great lengths to bend Rails to their will.

PHP has problems. Rails is by no means a silver bullet. I've used both, and I continue to use both. Use the tool that fits your style. I applaud Derek for being brave enough to say that Rails isn't his style and PHP is. I disagree for my own workstyle, but does that mean that I can say that he's insane and that he's wrong about his preference for PHP? Absolutely not... A lot of excellent sites have been written on top of PHP. A lot more than on Rails. Oops... Did I say that? It's really no different than me telling my friends that they are idiots because they snowboard instead of ski. "But skiers are better in the bumps!" Or that Macs are better than PCs.

Bottom line, you all need to chill out and make your own bloody decisions. And stop informing those brave enough to state theirs that they are stupid, short sighted, insert-chosen-insult-here.

end of rant.

Thanks for this article!
A friend of mine told me to give Ruby a try, but I wasn't that much interested in giving away my whole control. Now I'm fine with PHP, I don't need Ruby (although I really like the idea of a clean code).
Anyway, thanks for the article! :)

Um, Java and hibernate anyone?
If you think your DBase is the thing, and you want your model to be fresh and fruity, you might just need a transparant framework to accomodate both model and dbase, instead of a "our way or the highway" framework.
Rule number two: If you feel need to go against grain of framework, you pick wrong framework.
(rule number one has to do with smiling bald little monks...)

this comment thread is a wasteland and i expect to be lost in the noise but cdbaby is one of the better online retailers i've used (and i've used many, worked for two). whenever i ordered i'm sure it was the old codebase i was shopping against but i walked away from the transaction feeling like they'd really gotten the online purchase process right.

David, I think you completely missed the point of a framework, which is what rails is. The idea is RAD, and frameworks help solve that problem. The trade-off is that you need to be comfortable with the framework and have a pretty good understanding of the concepts behind it (MVC and such).

Your article isn't very well thought out, and I feel your process was flawed from the start. Furthermore, you don't rewrite something just for the sake of rewriting it.

Where Ruby is better than PHP? Our snippet of ugly code runs some of the biggest app/sites of worlds... Oh Yahoo! oh Digg! Please, take our fashion, pink colored language! Ruby is prettier, ruby is prettier!

The reasons that make this project failed, can be:
1. The programmer is not so talented
2. The customer is not a good task giver
3. RoR is not a excellent framework
After 2 years, project ended by canceling, say something about the customer's management skills and the programmer's professional skills. Are there any successful web-app based on RoR which are more complicated than cdbaby? I am sure there are.

My suggestion is:
Some other talented guys in the RoR community who can pick up this project again and do it on "no good app -> no money" basis or gratis as community gift to Derek. My estimate is about 4 months project for an experience programmer. The project can be done by 2,3 programmers (why there was only one).

Want to start your private office arms race right now?

I just got my own USB rocket launcher :-) Awsome thing.

Plug into your computer and you got a remote controlled office missile launcher with 360 degrees horizontal and 45 degree vertival rotation with a range of more than 6 meters - which gives you a coverage of 113 square meters round your workplace.
You can get the gadget here: http://tinyurl.com/2qul3c

Check out the video they have on the page.

Cheers

Marko Fando

Out of curiosity what PHP MVC implementation are you using?

It seems to me from your article that you had a lot less experience with Rails than you are professing. "Bitsweat" is a great coder. What did you do during the two years? Rails definitely has a learning curve. I programmed PHP for 8 years and it was a battle for me to adapt to the new "Rails" way of thinking. But, after having used Rails for just over 2 years, I can honestly say it was well worth it. I would never want to go back to PHP unless I had a really good reason. So far I have not hit a single obstacle in Ruby/Rails that caused me to think "Wow this would be easier in PHP."

You also mentioned that you do not need 90% of the Rails framework (which I find to be an exaggeration). You do realize that the framework is scripted and you can remove what you don't need, right?

The only benefit I see in PHP applications right now is Zend Encoder and the ability to rebrand/redistribute an application without divulging your source. However, I am working on a similar product for Rails.

2c
Jabberwock

PHP is essentially a kludge language although it has improved over the years. It is completely ridiculous to compate it to Ruby which is a complete object oriented language. Rails is a framework written in Ruby, its not a language unto itself just like the .NET framework is not Visual C# or VB.

Now whether you prefer a procedural language to an object oriented language is of course a design choice. Often straight forward code will be faster than an OO solution. However... it tends to be more sloppy and less extensible.

Now I took a look at CDBaby.com and I do not see anything here amazing. You could simply have bought a decent shopping cart package and done this site in no time flat and have it be not only more functional but a whole lot more attractive (it looks like something ancient in web terms). Anyone in the know of eCommerce knows that visual appeal and snazzy function will convert to sales .vs. something that "looks" like it was done by an 5th grader. Retailers both on and off the web spend enormous amounts of money (as do OEM/Manufacturers) on visual appeal as that singular factor is considered an imperative in selling anything to anyone. Its just a marketing 101 deal.

If you have love for PHP then perhaps you should have selected PHPNuke and started adding on lots of the third party modules for it. Forums, Polls... on and on. This is again just a no brainer. Anything that keeps a consumer interested and retains them as a site visitor is money in the bank.

A party below stated you simply were ridgid in database design. Perhaps you have some sort of local database and you want the online vs offline DB's to happily cooperate. For example you have a Windows PC using MS Access or Quickbooks for inventory/accounting etc. You want to be able to transition product into your online sales site via a easy process. Thus you end up in a ridgid situation if your running say a linux server. So one thinks "What can I do?". Java based solutions are portable across Windows platforms and Linux. But, whats out there. Well several CMS systems for starters. "But, I dont want to learn Java!" I understand. Your primarily interested in selling your stuff! You hired a software engineer to try and effect change not because you pulled change out of a hat but because you want a better sales presence and extenisbility!

Again... many an online shopping cart can do your bidding but in such a case you may still have issues with your backend business logic.

With that all said, if I am on the money about your desires then your answer lay within Microsofts technologies. ASP.NET to be exact.

Many peep's here may "freak"... "NO! NO!, linux, java, php, Ruby blah blah..." because the Microsoft technologies are not quite as efficient. What they neglect to say however is in using those technologies you step into the fastest growing region of Internet technologies and you enter into development environments that UNIFY online/offline technologies and are completely extenisble!

Go download Visual Web Express edition, its free from microsoft. Take a look at a few free shopping carts source code. I would advise you look at Visual Basic, if you can handle PHP you can handle Visual Basic.

You can build locally and deploy as easy as FTP or "publish" within Web Developer. Whats local is whats online. You can use JET (MS Access) offline or online thus unifying your backend business work, or you can use MSSQL.

You want add functionality to your web you can now do so in true OOP maintainable modular fashion.

Your present site can almost completely be done via drag/drop and setting properties in Visual Web Express. Literally. Sure, your going to need learn some stuff. Get a ASP.NET 2.0 in 24 hours book and a VB.NET 2005 in 24 hours book. Then if you like look at some other texts.

From what I can see your "Database work" for the online site probably needs less than 50 lines of code! You can just use Visual Web dev's (or Visual Studio 2005 which I recommend) databound controls, literally drop controls anywhere on your web pages, set the properties and bind them to the database(s). Not a line of code need be written to do this. ASP.NET has a built in membership provider as well. Just drop say the "Login Wizard" control unto a page, set the properties. Want different roles, ie: user categories. Very simple to do. So now your top customers you might want offer promotions to. You can design pages so they and ONLY THEY see the promo's. As many roles as you like. Say you have resellers buy too. Can have a resellers role.

Point being... via Visual Basic (or C# if you desire, its a harder learn) and ASP.NET you can do just about anything you please. Its extrordinarily powerfull and sits on the cutting edge of now only web technologies but your local PC technologies as well. Microsoft is the company that is unifying the two and continually making it easier for the average guy/gal to really make dyanamite webs/local software much much more easy. It pisses off alot of professional applications developers and the reason why (usually) is just common sense. With more and more attention paid to the average person being able to actually create interactive technologies without being an omni-guru puts omni-guru's in a less favorable work position.

If Microsofts next Dev Platform for sake of discussion allowed anyone to create really dynamic web applications. I mean state of the art stuff without having to know much anything about engineering but just basic logic where does that leave coders? Well this is exactly where Microsoft's directions are going.

The ASP/CLR etc. model is just that. It is an effort to bring ability to create software (online and off) to the masses. It might be 20 more years before its just drag/drop assign properties, logic and relationships etc. but it is coming.

No... its not all as efficient as many other mechinisms. But, MS realizes that the hardware technologies are advancing plenty fast enough that it becomes moot for all but sizeable enterprise app's (like eBay, Amazon etc) where everything from connection servers to specific backends for literally everything are required due to traffic/demand.

Your site could easily sit on a shared server at a place like Gate.com. Most "GOOD" Hosting companies be they hosting linux or Windows Server have dedicated database servers. It only makes sense. WHY would you (a host) want your myraids of shared accounts on machines having DB's local on the machines?

Some do it as a sell point ie: a mySQL DB that can be the size of your hosting account, say 20GB. Now try and use it as a dedicated DB lets say for a site hosted elsewhere and see how much they 1. dislike it, 2. block it etc.

Point being, why have database activity eating cycles on a shared server where say 100 accounts sit (and thus all can suffer) .vs. a dedicated DB server and say 200 accounts on the shared server. But many as I noted hosts without the ad bucks try and loop sites in via "all the DB space you want!"

Now perhaps your DB schema is not "guru friendly and el'perfecto". The JOB of whom you hire to create or re-create your web presence has a job. That job is to unify what YOU want.

ASP/MS does not tie you down to the database either, if you want use mySQL, Postgres, Firebird, Oracle, DB2... ADO.NET will happily use any data provider.

If I am right on your windows backend business I'd had never started to even say "Lets use Rails!". Uh uh. I'd have said, lets use ASP.NET and lets first before we do that see if we cant find you something out of the box that meets and/or preferably exceeds your needs so you can grow. So maybe not a cheapie cheap solution but maybe something midstream so we can ensure extensibility, so via MasterPages (also native to ASP) you can at anytime change the entire look of your site and/or portions thereof without having to call me and say, "I want the site to look like fall".

See... You said something in your article that makes "common sense" but is non-sense. "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!"

Becoming a better programmer does not mean I learned a new language. That makes you a more versatile programmer. How mainstream programmers rate becoming a better programmer varies as does it in business. A business might rate a better programmer as one who completes work faster than another but does sloppy linear code. They dont care. Work is done, until perhaps another programmer comes in who's hired and has to work with the code.

Another programmer thinks that linear code sux. Bad programmer. Yet a coder who knows say assembler (I do not that I use it much these days) often end up saying anyone using compiled code is not a premium programmer). Hand tuned assembler running rings around compiled code.

IMHO the "smart programmer" makes sure that his/her skill set is applicable to getting work. In todays world of work we have web technologies, we have local technologies (PC's,Lans, Intranets etc). If we take a look at what engineering technologies are applicable across all prospect jobs we end up with Java And Microsoft technologies as the forerunners (C++/C#). Both highly capable.

You open up the paper or go to a jobs web and look, how many "Ruby programmer needed" or "PHP programmer needed" via GOOD PAYING JOBS do you find as compared to Java/C++/C#? There's your answer.

Its not to say Ruby/Rails etc. is not excellent work. It is.

It is however to say "you dont need to attempt apply what is not your needs" to your work be that for someone else or self.

Again, your current CDBaby web could have been done using Active Server Pages in less time (for certain) than your PHP solution. In doing so it would be far more extenisble, solid and maintainable. You could easily unify it with any Windows based backend you use to run your business.

Lastly Derek... Take a look at DotNetNuke which is portal software which recently ported to ASP.NET 2.0, lots of features, modules, online this/that. DNN can also easily make your web (and then some++) without you spending a dime, its free.

In fact, lets say you wanted to make a MUCH nicer site as I somewhat outlined above. Since PHP also runs on Windows Server you could run DotNetNuke on a hosted windows server providing unified membership along with any/all doo-dads from forums to blogs on and on and have your current store software STILL running at the DotNetNuke domain (or your current domain) through an iFrame COMPLETELY transparent to the end user. Thats right.

DNN is a portal/Content management system, free. They claim over 500,000 sites in use. Very easy to use, very powerful, quite flexible, can be "skinned" for different look(s) on and on.

There are tons of modules available and all provide a consistent experience for both the site administrator(s) as well as end users.

Since it is portal software as well... You can host many portals on one server. So for example say you want make a
MOST of todays software engineering tools are impressive but that does not mean any given one is what the customer needs because its the one I know or the latest growing "keyword" among programmers.

Lastly in favor of MS Technologies is a nice little added wonder. You can create your own distributable controls to a ENORMOUS development audience. For example, lets say you decide to make a control for the mp3 streaming and/or download from CDBaby. Drag/Drop, set its properties or data bindings etc and anyone can use it.

Joe's music store online doesnt want re-ienvent the wheel when they can pay you $99 for a drag/drop control in visual express that does what they want. There is a HUGE aftermarket in the ASP.NET world and many a place capitalizing on it.

Lastly perhaps for example you want make a site that compliments (or many) CDBaby. Perhaps site(s) that are homepages for music artists. Perhaps sites for new musicians. Perhaps a site where new musicians can get their music sold to the public while you get a cut? Anything goes.

Point all being your vision of what you want applies directly in, "How do I get from here to there". A GOOD engineer will look at everything you desire and give you more ideas. They will implement it via the best technology to do so. If you hired me for example and I saw that your backend business database deal is ever so important to you and say Rails as we get into development is going to need be tweeked big, in direct conflict whatall then its my job to give you the BEST options.

Just because something is a buzzword does not mean its the right buzzword for the customer (in this case you).

Rick
firststrikepro@yahoo.com

As posted above (Let me break this down):

The reasons that make this project failed, can be:

"1. The programmer is not so talented"

Ya think? Ummm, I'd say in two years using Ruby alone three, possible four seperate shop cart applications from scratch could be coded.

"2. The customer is not a good task giver"

Dunno... obviously ill informed I'd say.

"3. RoR is not a excellent framework. After 2 years, project ended by canceling, say something about the customer's management skills and the programmer's professional skills. Are there any successful web-app based on RoR which are more complicated than cdbaby? I am sure there are."

Ruby On Rails is a fine framework. CD-Baby is essentially a eCommerce shopping cart site and not a particularly good one. One can buy (or get free aka: OSCommerce, Zen Cart and countless others) commerce app's that are considerably more capable. I must assume the team decided to try RoR for some other reasons, like: "See we did an eCommerce app with RoR and we want to ??? it".

My suggestion is:
Some other talented guys in the RoR community who can pick up this project again and do it on "no good app -> no money" basis or gratis as community gift to Derek. My estimate is about 4 months project for an experience programmer. The project can be done by 2,3 programmers (why there was only one)."

Your kidding right?
2-3 programmers?
4 months?

Lets say 2-3 days with a decent eCommerce app where we can just upload a .csv, graphics from scratch and all.

Lets say a week using ASP.NET from scratch.

...and then ditch PHP for Python and you're all set.

Let's add a rational argument against...

* Rails has no financial backer and therefore no secure future (like Microsoft or Zend).
* Rails has a dictatorship by the "core developers".
* Rails is inflexible when it comes to model/persistence mapping. It's 1:1 model to db at best.
* Rails is not very scalable per host as everything is interpreted. Ruby is slow
* Ruby lacks a specification. So does rails.
* Rails is hard to host as you require shell access.
* Rails occasionally requires some odd magic to make things work.
* Rails lacks any real "enterprise" usage, which is where professional adoption is usually defined. The stuff I work on handles 37signals' entire throughput per year, except every day.

It solves many problems but creates a few in the process. I've just scrapped a project I've been working on for 6 months with Rails and moved to ASP.Net. It's far more mature, supported, controllable and I can employ talented developers readily anywhere.

PHP although with a different scope (based on skill set mainly) is equally mature, supported and controllable. Add CodeIgniter or another framework to it and we're there.

Well. I've tried to understand what's cool on your new rewritten site. But my browser said this when seen the cart:

XML Parsing Error: not well-formed
Location: http://cdbaby.com/cart
Line Number 19, Column 3:

But, regardless to this, I have to agree with you that it's always better to write your sites by yourself. In RoR, C, PHP, whatever. You can have the best programmers in any language, but they will never save your world if they are not capable to understand your business needs. It's not a question of programming language, thus if you can only understand the PHP and want to move forward with your business, it'd be better for you to stick to it.

If you needed all that flexibility from a Web framework, why didn't you try Catalyst?!

I think that most people, from these comments, missed the point of this article. This was not a technical article.

Sometimes we as programmers forget what our clients want... applications that just work. They don't care how they just want it to do what they want it to do and do it well. If that means you can code in BASIC the best as anyone on the planet then use it! If for some reason you have 2 brains and Java is your cup of joe then DO IT. I personally use the most widely hated language, ColdFusion, and I have been using it for about 10 years now. I am really good at it and I can get things done amazingly fast. I do some fairly large platforms with it and it works very well. Adobe is still developing it, I still get paid gobs of money to program in it and I will keep using it as long as I can. Yes I still play around with RoR, PHP and .Net but if someone comes to me and says I need an app and I need it in 1 month I am going to use CF because that is what I know and it is what I work fast in. May not be the coolest on the block but for me it is what works.

Don't just use a language because it is cool, use it because it works.

First off, I checked out CD Baby, and I'm extremely impressed. It has a refreshing lack of "Web 2.0" Flash/Ajax/RIA crap features, which so many other websites are are ruined by (slow, bloated, bulky, buggy, irritating, distracting, etc). CD Baby is very simple and clean and without tons of useless graphics. Also, due lack of tons of graphics, flash, Ajax, RIA type stuff, it's very fast. Very very nice job.

Second, I'm absolutely amazed at the comments coming from the RoR camp here. Your post did not flame RoR at all, it merely stated that RoR did not work for your needs and PHP did. Plain and simple. But comments have been like so:

1. If you couldn't make RoR work for you're particular use case, you're stupid and you suck.
2. If you like SQL, you're stupid and you suck.
3. If you didn't like or couldn't make work, ActiveRecord, you're not a true programmer, you don't understand OOP, the database is secondary (and the relational model sucks), and you're stupid and you suck.
4. PHP sucks (for no particular reason other than it's not Ruby or Rails)
5. Your design/goals/re-write was bad, therefore you're stupid and you suck.
6. OOP is the be-all to end-all, anyone who doesn't agree or can't make it work for their particular use case, is stupid and sucks.
7. You're website doesn't use RoR, therefore, it's stupid and it sucks (and you're stupid and you suck).
8. The RoR guru you hired couldn't make the project work, therefore he's stupid and he sucks, even though he's a core Rails dev.

Really, the rude, condescending remarks coming from the RoR camp, simply because RoR did not work out for your use case, is appalling.

Some technical notes take from this:

1. The SQL/Relational model is great. It works. It's easy. It's proven. It's fully scalable. It's efficient. And 99.9% of all data anywhere is stored in the relational model, accessed via SQL. People who are over-obsessed with the OO model need to come to grips with that. The statement one poster made that "RoR works best with a from scratch app where the database is created for the app", holds true. But 90% of programming jobs/problems/use cases involve a an existing, fully relational, database. In this use case, stuff like ActiveRecord, Hibernate, etc, become much, much, much harder, and regular ol' SQL works great.

2. Hardcore OOP developers, who haven't worked with much SQL or databases or the relational model, struggle with SQL/relational databases. They have bought into over-hype that OOP is the be-all to end-all, and only think programmaticly that way. That's why we so many ORM frameworks.

3. Frameworks (web, or ORM, or otherwise) only really work well with a narrow collection of use cases. Anything that goes outside of those narrow use cases, which comprises a huge amount of real world programming problems, makes using the frameworks very hard.

4. RoR, while very nice/cool/useful/productive for some use cases, is badly over hyped, and the fanboys are very over-rabid.

5. PHP, used with discipline, is very very good, useful, and flexible. PHP is all over the web, and it is proven that it works, and it is approachable for all levels of programmers. It has warts/limitations, of course (as do all languages), but PHP is very useful.

Really, it seems to me that some of the absolute worst fanboyism comes from the RoR camp. Too bad, because RoR is pretty cool/useful for some use cases, but the fanboys give it a bad name, and make reasonable people want to run away screaming.

Let me take a guess.
The auther of this artical posting this ... just want to do a free advertisment for his website.

I believe in most of what you said.
You website works great, but i think it needs some art work.
looks like in your company nobody know photoshop.

PHP is... light... and fast... right. I don't have any love for Ruby (it's been around for quite a few years but it's never managed to grow mature) but PHP is a gigantic resource-hogging mess of spaghetti code with 9,000 "core" functions jammed into one namespace, worthless error-handling, broken-ass OO, and it still hasn't caught up with such 45-year-old innovations as reasonable scoping.

PHP is... light... and fast... right. I don't have any love for Ruby (it's been around for quite a few years but it's never managed to grow mature) but PHP is a gigantic resource-hogging mess of spaghetti code with 9,000 "core" functions jammed into one namespace, worthless error-handling, broken-ass OO, and it still hasn't caught up with such 45-year-old innovations as reasonable scoping. It all adds up to make it nearly impossible to write code that's reliable _or_ efficient.

Stay bald dude! screw ruby!

Good article, Derek!

In the end, it doesn't matter what language you write your website in -- what matters is the end result, and CD Baby rocks (speaking both as a customer and as a musician, here).

Rewriting is good. Any time you can rewrite a program from scratch, you're going to improve it. It gets cleaner, more general, more robust. A structure that lets you replace the code on your site piece by piece, the way you did, is great because it means that everything keeps on working while you're improving it.

Musicians call it "practicing".

May be im a mourner may be i deserve to do something else.
Need to feel the sense.

You, sir, are a beast for hand-coding the entire site. Most impressive.

Excellent #7 argument. I translated it into Russian and published at my Russin blog (http://flash-ripper.com/), with backlink of course.

the "my language is better than your language" war is always puzzling to me. Instead of wasting their time with all these stupid arguing all the time, why don't they challenge each other with developing some applications/project using their language of choice and see who can finish first, and have the best codes and also best performance under heavy loads etc...
you see in sports, if a sprinter brags about being faster than another sprinter, they just have to race against each other in some organised race and you see right away who is the best.

so that's why I ask the same thing from so called experts of both php and ruby , just take a challenge and let's see who comes out on top.

Wow, it seems that the rails crowd is a bit touchy when it comes to PHP comparisons. Things seem to get personal pretty easily.

I have been working with PHP for about 8 years and have been following the progress of Ruby quite closely over the past few years. The fact is that Ruby is a very beautiful language, however, for web development, I find that the very things that Ruby enthusiasts blast PHP for (over-crowded namespaces and a procedural core) are what makes it so powerful and easy to use.

PHP comes ready with functions to do almost everything one needs to do with a web application. No need to import a bunch of libraries or dig through API docs to learn how to work with the objects or interest. Just call a function.

The ability to have the fundamentals available as a procedural API is a huge timesaver. For more complex things, PHP has full OOP support also, so we get the best of both worlds here.

Documentation in PHP is second to none. If you forget how to use a function, just do http://php.net/function-name, and you get full docs with examples and user comments. No other language comes close in this respect.

For those who continually call PHP an ugly language: This is a personal preference. I presume that you are turned off by puctuation and the dollar sign. I personally have no issues with this. Well written PHP is very readable, and can even be beautiful.

Thank you for writing about your experience here, Derek. I hope the rewrite continues to go well in PHP.

I am sure the Ruby on Rails experience was not too bad, you prob learnt a lot, which you would have never known if you never did Ruby in the first place.

Hey that's baffling, yesterday I thought about switching over to Rails and now this :D I don't know shall I or not? grrr

greetings from germany, Max

http://www.joelonsoftware.com/articles/fog0000000069.html

This is a nicely written article about the benefits of keeping what you already know(PHP) and should further improve it instead of ditching it all together in favour of unknown beast like Ruby on Rails. Ruby is beautiful by all accounts but does it justify migrating all your code to it?

You answered that question most convincingly. Thank you.

Hail!

What do you think about Apple Iogo? >:)

Excellent post.

After reading through the comments I have to say that most of the flames coming from the Ruby camp are right on. Rails is not for the simplistic, it is for the complex, and it does it quite well. And yes, it can scale, if you know what you are doing, which you obviously do not.

In our shop we are all from different backgrounds, PHP, Java, and I am from the world of .Net and C++. I don't know a single developer here who is unhappy with our choice of switching to Ruby and Rails.

I suggest the next time you learn a new language you actually learn the new toolset and not just try to use it the way you did on x language.

Great article Derek. I can remember reading that job req not too long ago, back when I was up in Portland. Something like "looking for a Rails Rockstar" :) Thanks for giving an honest follow up on how everything played out. I find it interesting that you had a world class Rails guy there, but still ran into all sorts of design issues. I wonder if "leaky abstractions" apply anywhere here?

So what ure saying is that you never needed rails nor had the will to go that way, but you didit anyway, and what is even worse, you say you tried to turn a train into a boat, when what you actually did was putting a train in the sea and yelled at it to make it float.

#1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” thats not even a reason to go for ruby or php. thigns are different in both of them.

#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
This is a great reason to have never tried rails. 2 years is a long time to learn that.

#3 - DON’T WANT WHAT I DON’T NEED
tatoo that on your forehead so you remember that after the first setback.

#4 - IT’S SMALL AND FAST
i dont know that as a fact and dont

#5 - IT’S BUILT TO MY TASTES
2 years late on that one too

#6 - I LOVE SQL
you must have missed it alot.

#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
you cheated on your wife with a 20 yr old girl, and after 2 years finally accepted you cant put up with her lifestyle.

Im sorry if its too direct and migth even sound aggressive, but 2 years programming with the php paradigm over rails api sounds like a huge mistake.

Great analysis of your own efforts. The last point (#7) is right on the mark. So much emphasis now-a-days is placed on new languages. FYI: I write templated, db-drive web-sites in C++ using FastCGI (sorry in advance to everyone this offends).

I enjoyed your post. I'm not sure why so many people get religious about the tools they use and bash anyone that doesn't use what they use. Lots of programmers are very productive using PHP, and write good code in it.

The more I read postings and replies online from Ruby zealots, and the more RoR podcasts I listen to, the more they're starting to seem like Moonies or Hare Krishna cult followers or something..

Can't they just shut the hell up, enjoy what they prefer, and allow others to use languages and frameworks they're not fanatical about? :)

To Zend Framework or not to Zend Framework, that is the question.

PHP did not kill Rails--Rails killed Rails. Who in their right mind is going to want to deploy 5 - 10 30 meg preforked processes per application from whatever location on this thing called "mongrel" and have the whole mishmash marshalled by this other thing called "Cappucino"... er "Capistrano", which is lipstick on a pig, because rails is a pig no doubt about it. I need one server with several preforked processes for ALL applications to be served.

http://www.chadfowler.com/2006/12/27/the-big-rewrite

Quoted from the link:
This is the first in a series of articles, discussing why
many software rewrite projects end badly and what
to do to avoid some of the ways I've seen them go astray.
.
.
.
You’ve got an existing, successful software product. You’ve hit the ceiling on extensibility and maintainability. Your project platform is inflexible, and your application is a software house of cards that can’t support another new feature.
You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).

Beware. This is a longer, harder, more failure-prone path than you expect.

Its an old article but still very "today"

Thanks for the viewPoint Derek!!

Good luck with your Site!

The answer is to NOT Zend Framework. It is Zend selling an entire rat race. That's ok for them, making money is fine, but I don't want to join because I don't want to work with software where the incentive is to produce bad software because it makes more money than good software. There's got to be a better way to structure a business. What are the incentives of the Rails culture? To be 65 times slower than C? No wonder IT likes it...

Just stick with Code Igniter...

Great article! I've been using php for a little while and it's always done what I've asked from it. But I'm also interested in CakePHP and other php frameworks... I'm not sure how much more productive it will all be, but I certainly hope that I'll be developing faster & better with php frameworks - I'll have to try and see how that goes...

I think it needs to be typed again:

cdbaby is *not* simply an online music store. It is a distribution network for independent musicians and labels. I know that without ever having visited it. So all these off-the-cuff brags of "it should have taken 2 months" or "I could code that before I had coffee in the morning" are just absurd. Have you seen the database? Do you know what the administration of the backend is like? Then you just look like an ass.

Also, have any of you "should have taken X time" ever actually worked on a large scale enterprise site? How many projects have you seen derailed when something the developers didn't foresee came into play?

As for the flame wars. Good reading.

golly gosh I wish you wrote without curse words

Hi
After reading this article. Its clear that the planning for your project is absolutely fault.
Secondly. If you are a PHP/JAVA guys. I dont encourage them to go to RAILS. That too. if you are working under a PHP or Java managers. its hell out there. POOR J.KEMPER.
I am currently developing an ECOMMERCE APPLICATION. hardly took 6 weeks most of my things are finished. Ill tell you my application architecture
OS :DEBIAN LINUX
DATABASE :MICROSOFT SQL SERVER
DESIGN : MAC
CONNECTIVITY: MAC-WINDOWS-LINUX
SOURCE CONTROL :MICROSOFT VISUAL SOURCE SAFE.

99.9% no trouble for me.

I did projects with php/j2ee. only 80% satisfaction. Well i dont compare any language with other. every language has its own -ves and +ves.

If you are making contravarsies between languages you are not at all a good manager. ITS VERY HARD FOR JAVA/PHP GUYS TO COME TO RAILS HIGWAY TRACK.

To reach destination..I can choose subaru, lancer evolution or mustang. But one at a time. you may choose mustang. but i choose evolution. All can reach the destination.

PHP HORSE POWER : 5700 RPM
JAVA HORSE POWER : 2000 RPM
RAILS HORSE POWER : 9999 RPM

BROTHER DONT EVEN THINK ABOUT RAILS..RAILS IS NOT FOR EVERBODY.
OOPS! MY BAD. BUT PLEASE TAKE IT.

Nice informative post. I thought it was very fair and honest and greatly appreciated the fact that it wasn't the typical "this language sucks" post which is all too common on the Web. The one thing I wish was reviewed and reference links given, was some sort of question matrix to help decide between Rails and PHP.

Way late on this but, another reason forcing rails on your project failed was probably because you started doing it when rails was extremely young. Did you even have a link_to back then?

PHP sucks and Ruby is a much better language. However Python is a lot better than both (not to mention faster).

I tried Rails. For about one hour. Then I realized it wanted to create my database schema for me. Then I saw the guys advocate doing the foreign key checks in the application. I puked and went back to PHP.

I don't want some little software to create my tables or issue misguided SQL queries. Will it also write the stored procedures and triggers for me ? Does it know about Postgresql's vector types and indexed boolean set operators and geometric search ? Nope.

SQL wrappers are nice when all you want is MyISAM.

But PHP may be relatively slow if your website is very popular! For performance, I would have chosen something different.

lol @ the "your site suxorz" children

you do realize cdbaby made bald guy a multi-millionaire?

Very interesting.. I have been pondering Ruby for a while but have not found a good use for it yet.. now Im wrapped in PHP.

I used to be keen on Perl but PHP seems a tad more practical, what with in-built integration with MySQL, no chmodding, no need for a /cgi-bin/app.pl in the url, tiny EXE in windows and just a whole bunch of other stuff.

The thing that gets me is the different syntax between PHP, JavaScript, HTML and CSS.. let alone your choice of templating language. I guess it keeps our minds nimble but how many times does a script fail because you used a dot instead of a plus to concatenate 2 strings?

One day I will re-write my creativeobjectworld.com in PHP.. that will be fun.. 5800 lines of Perl code.

I can't believe someone said you had a bad team and what you stated here was just an opinion and nothing substantial. I think the guy who wrote that didn't quite read what you wrote, and understand 1) what the author's reasons were for the *NEED* to get into another project - business reasons... in fact, folks need to understand that the author of this post was the business owner of the site - not a coder by trade! 2) And using frameworks like cakePHP, as well as Ruby, I agree with the author wonderful points - sometimes you end up trying to get the framework to be a boat, rather than a train.

Anyway, no need to show examples of your work - I believe you when you said your next bit of PHP code was the best ever. I've had a very similar experience, especially when I started putting my code into classes with PHP 5 and used MVC with my own framework, and did the nice dirty SQL queries without relying on a restrictive model. In fact, I've used several PHP frameworks, and each time my experience from them has improved me - the coder, by learning from the collective wisdom of the framework's developers.

You need a hair recovery treatment

I think PHP will still etch a niche in the Web Community because it's easy to develop and understand. Although we can't deny the fact the RoR is pretty much an emerging technology that offers a lot.

How do you compare execution speed between ruby and php?
It seems as if ruby was as not as fast, true?. Did you make
experiments?

Derek,

CDBABY.com is awesome, and I appreciate you going through the pain to create a system that helps me greatly with my music... i hope you become filthy stinkin' rich and one day rule the world! Take care, Dan Keenan

PHP has a great active community and thanks to all of them it is what it is.
in my own perspective, the difference between PHP and Ruby or Java for example is that
it evolves really fast and provides the market with the solutions it demands.

I fear that a lot of people would turn their backs on PHP because it moves too quickly and many servers
are stuck with old code, PHP4 for instance.

but anybody that is serious about development knows that code needs maintenance.
and that the market moves, and thus the implementation should.

Kazuyoshi Tlacaelel

Use Coldfusion and model-glue mvc framework. It is better than ROR and PHP. CDBaby can be well written even faster than PHP using mighty Adobe Coldfusion.

Jeremy Kemper effectively answers this with a little more dash of truth than what you get in this flamebait article. Basically, Derek is an ego, he couldn't understand Ruby or Rails, and wanted the Rails people to code his crappy site in Ruby that looked like PHP... Check out Kemper's response to this at 37signals:
http://www.37signals.com/svn/posts/660-ask-37signals-the-genesis-and-benefits-of-rails

Agree with author, PHP is about how good the programmer is.

Actually are not making about about Ruby vs PHP but you are merely stating your taste. Anyway, try Gluon (http://mdp.cti.depaul.edu) and see if you like it better. Probably not.

Actually you are not making a point about Ruby vs PHP but you are merely stating your taste. Anyway, try Gluon (http://mdp.cti.depaul.edu) and see if you like it better. Probably not.

Derek, as at 8-Nov-2007, is cdbaby.com running PHP or ROR? I'm wondering because in my (in)experience, the way the links to other pages are made makes it looks like its using a rails-type framework.

From your article though it seems pretty clear that its running PHP. I'm just asking because www.netcraft.com also can't find any PHP type headers.

It seems like you've got a great "cute and powerful templating system" - it would be great it if it could be shared, please consider sharing the code for the benefit of others.

Thank you!
Mark

I totally agree with you.
I think that the problem is not a language but you!, so if you a really good programmer, you can write in any language (PHP, Rubby etc..) and most important thing is, if you have something done there are no reasons to rewrite it in the other language.
But yes you should to improve your level as a programmer to do the things better for what you already have.

Its all about the databases baby, everything else is an implementation detail.

"It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails."

Could you post this MVC framework you built, or is it built upon another framework like ZEND, etc?

You simply cannot beat PHP if you do it right! Of course there are teething problems in PHP, such as the inconsistency in the function names, and all the functions in the base namespace - thanks to no namespaces, but if you plan your project using UML and stick to the GoF design patterns then PHP is an exceptionally powerful language.

Does Ruby give any wisdom ?

The article was good and the best part is the comments you got!
I am not pointing to any specific thing... but I was shocked to find how fast you jumped from a well established, stable PHP to an upcoming Ruby and at same pace you reverted back.
As far as my experience goes, if you had planned properly everything you could have been successful with your php -> ruby shift.
I am curious to know:
what are the difficulties you faced?

Derek: Welcome back to the php army.
Im happy! I really missed the post you used to write about mysql queryes and php stuff in your early days.
I hope you share your new style of php coding whit the rest of us php programmers than still do it old school.

Why are you people getting worked up? He's comparing a FRAMEWORK to a LANGUAGE.

If this article had any merit at all (not trying to come off as a fanboy -- I'm in your exact shoes) it would compare, say, CakePHP to Rails.

If you wrote a framework for cdbaby.com from scratch in ruby it would be no different than writing it from scratch in PHP. Apples to Oranges my friend.

> If you wrote a framework for cdbaby.com from scratch in ruby it would be no different than writing it from scratch in PHP.

Exactly, Rob! That was my whole point. The language doesn't matter that much. They can all do the same thing.

The reason it made my life easier to stick with PHP is because EVERYTHING else (hundreds of shell scripts, our backend accounting system, our entire digital distribution engine, our members' login area, our intranet, and more) - were ALL in PHP.

By writing a new system my old language, I was able to integrate cleanly with all of our existing stuff, converting piece-by-piece while bringing this to fast-launch.

tie youself up, then goto use a framework.

when we hack on squid and nginx to get more load capability, so many people here are talking about ORM and OO? do you know how many 'call stacks' you have produced when using loose coupling? do you know how many 'joins' you have produced when using ORM?

Derek, thanks for the article. Welcome back to PHP ;)

Did I click submit last time?

Anyhow, thanks for sharing your experience. I am thinking of investing time in learning Ruby on Rails as a replacement for PHP for future web projects, so before doing that, I'm glad I could read other's experiences here. I can see that Ruby will probably help me understand OOP and design patterns better, and if for that reason only, it seems that RoR is worth learning, because:

'A language that doesn't affect the way you think about programming, is not worth knowing.' -- Alan Perlis

Considering that its syntax is simple, it seems that it has a place next to Python and Scheme, as a language of choice for novice programmers.

I'm not sure that I will give it a 2 year trial period like you did, but will definitely invest few weeks to see if it works for me.

Regards

Funny how you you stirred up the Rails zealots. I tried to learn Rails and I stopped as I saw no point in learning it for the work I do.

Most pleasing thing to me: Your confession that you love SQL. It became a paradigm that using SQL in your code is bad. I think this is only because it is quite easy to lock away SQL access in a "DB-layer" - if you have only a hammer everything looks like a nail -this is why it is done.

I was designer, coder and maintainer (quite a large team & codebase) of an application entirely written in PL/SQL - we NEVER had any serious problem in refactoring our SQL code. Just because something is easy to do doesn't mean that you should do it or that it is reasonable to do it.

Projects like LINQ are pointing in the right direction. Adding an abstration mustn't sacrifice performance, especially not when it is affecting the DB which is the bottleneck in high-traffice applications

I totally agree with you !
I love you quote about Programming languages... I guess I can proudly say that professionally, I am married to PHP.

Happy Coding!

Regards,
Rochak

Great.. I just cant wait to show off this to our top level, who is planning to wind up the php team. Well I have always been in php, and for my own as well as others references, put up a blog at www.php-trivandrum.org.

Sure.. there are several reasons why we chose php for our server side coding when we planned for our logistics management solution. Basically the small footprint, greater flexibility, and over everything the gap between knowing and not knowing.. the out come.. www.carego.in

Yeah, good to see some php appreciation again.
I got started in webdevelopent using php3 and it saved my ass back then, as I was able to quickly get something going in spite of me not knowing what I was doing.
But I always kept hearing about how Oracle's solutions were the real thing, used by professionals. In the meanwhile, php sites sprang up everywhere, but I was still unsure about my choice.
Anyway, this was 7 years ago. In the meanwhile I've worked for an Oracle shop and now I'm working on a huge crappy ASP.net application. I've got lots of C++, Delphi, PL/SQL and C# under my belt now. Bought the rails book but didn't get very far.
Anyway, I laugh at everyone dismissing PHP as "not professional" now. Even Oracle has changed direction after seeing how incredibly useful PHP really is. In my sparetime, I've started to dabble around with PHP again and I love it I love it I love it.
I'm so sick of doing things the right way. I got started programming hacking together little games on the VC20 and later on the AMIGA. Programming .NET has kind of taken this love for programming away. The light and hassle free approach of PHP has brought this love back again. Yeahhh.

Hi,

I was thinking of learning the advantages and disadvantages of Ruby on Rails over PHP by re-implementing a simple PHP/MySQL based links aggregator application that has only few hundred lines of code.

However, very soon I got discouraged, as setting up RoR framework and deploying application seems to be bigger problem than writing the application itself.

I kind of like just being able to experiment and make changes on live site, and that seems to be big a advantage of PHP. In your opinion, what should be the size and complexity of the project that would justify the use of RoR framework over PHP?

I'm a big Rails fan (also, am a convert from PHP) and do everything in Rails, but it's cool that you gave it a try and stuck with what you're comfortable with.

Rails is for me, but it might not be for you. Also, I agree that Rails is much more difficult to like when you have to deal with integration with existing code.

-Aamer

With your original PHP code cleaned up and re-structured, I wonder if it will be much more efficient now to rewrite in R&R...

EXCELLENT ARTICLE!!

I am a business owner with a legacy app in PHP facing a similar dillemma. I chose to refactor the data model; upgrade the platform to latest versions of OS, web server, etc.; then rewrite the code ... in PHP.

Here's why:

1. I don't know shlt about OO programming

2. I don't know shlt about Ruby

3. I had to maintain other legacy PHP apps and didn't want to run multiple platforms

Now, that sounds like hell to the kids who only know OO, whose second language was Ruby (after Java), and who work for consulting firms on projects with six-month time-frames.

But I am an old man (over 30). I learned procedural programming; my first language was Pascal and my second C (then Perl and PHP); and I own a business with bigger issues than how beautiful the code that nobody looks at is.

And the fact is there is a lot of stuff that runs just fine in PHP. Even more amazing, there is stuff that runs just fine in C. Even COBOL. And this is stuff that runs investment banks, satellites, and military applications. Not merely Wango Jango Zoobdy Dooby websites.

In other words, in the real world you gotta go with the tools you know how to use best, and you rarely get to start with a clean sheet of paper. So for me, and for the author of this post, PHP makes the most sense.

P.S. The nasty comments here are immature. Grow up, kids.

Kemper's comments on this, like Derek's original article, are modest, thoughtful, and well-reasoned. This comments section, meanwhile, does no great favors to the cause of Ruby evangelism, which is, as I understand it, supposed to advance a sort of mysticism and zen-like contemplative calm, rather than smug ignorance. But then, I guess we've all known our share of college Buddhists.

Holy Christ! I hoped you learned some risk/benefit analysis along the way. This whole experience sounds remarkably naive.

7 reasons I switched back to Windows after 2 years on Osx :)

I love sucks

Use PHP, if you like it, i'll use Rails. More comfortable for me, script/generate is a magic thing.

I Love Rails

I hate this ;)

Alec!

I only learned from a to s in school. Every word which contains from t to z is not my word.

OK, there are programmers who only use Java, PHP, and that's all. There're not programmers in my eyes. The programmers have an abstract view, and try to find a languge which is the better for the abstraction. If I cut one of my arm, I won't be programmer 'cause i learned typing by two arms.

It's not a principle

PHP is a language, Rails is a framework. This is the main problem!

Well php +++ POOOOWERFULL framework ????

symfoy was my answer... www.symfony-project.org

Symply GREAT !!!

I think the comments here demonstrate the number one reason to not use Rails: most Rails fanatics are arrogant morons. I know a couple who aren't, but they appear to be the exception.

If you doubt me, let's here what one of the former shining stars of the Ruby/Rails communities had to say.

As far as doing things Rails wasn't "meant to do" (I can't imagine what that might be in a generic web framework), I get the feeling that perhaps Derek's developers weren't quite as amazing as he likes to think. And I mean really, no matter how bad Rails sucks... two YEARS? Yikes.

I've also gone through this cycle, although in the end I settled for Python and Django.

At first I tried Rails because of the hype, then didn't have time to learn things properly so I dumped it in favor of an equally powerful but easier to grok framework.

I agree with the Rubyists about the database being an implementation detail. I also agree with others that sometimes the ORM makes stupid things after which it is necessary to get one's hands dirty with raw SQL. It may well be that it's quite impossible to get the ORM layer right in every case. In most cases, however, its a lot more convenient and clean to use the objects.

Hi,

I am not very technical, but I did not notice that Rails "2.0" came recently. In anyone's opinion, does Rails 2.0 address some of the Rails 1.x shortcomings?

Interesting post, but is it really good taste (or professional) to use the profanity, especially on a major publisher's site? It doesn't exctly make me think too highly of O'Reilly. I realize I'm fighting against the wind.

Derek, I really enjoyed your post.

Ruby has some nice bells and a whistle in its ass, but all prepackaged frameworks have inherent limitations. They're designed by developers with the talent required to build a solid framework. They work perfectly for their progenitor(s), but they still share limitations that require custom hacking. Customizing requires more than mere framework knowledge. Relying on Ruby/Rails talent without a deep understanding of OO PHP (or Java, et al.) is... amateur.

I am so glad i read your post. Before reading the post I was in exactly the same situation. I thought my ASP code is ugly and was planning to rewrite everything on Ruby. Though I personally find PHP a lot more powerful to work with than ASP, i would still think twice before migrating to Ruby now.
Maybe someday I'll give Ruby a try. For the time being lets make ASP work.

@Prateek:

You probably should move from ASP to PHP when you get a chance. There are actually translators just for migrating ASP code to PHP. The benefits? Separation of programming logic from display code, for one. Your server situation will get a lot cheaper (Apache over IIS) too. If I knew more about ASP, I'm sure I could tell you more about this comparison.

Well I went back to Rails and Ruby. I like it. I like prototype/scriptaculous over jquery. I like Ruby over Python. I still like the whole deal.

Despite having been through all this, read all the above, dumped Rails last summer, deployed CodeIgniter, deployed Zend Core, contemplated Django, yes I'm still interested in the slowest framework on the slowest scripting language on what's got to be the most bloated deployment model ever(one cluster-per-application).

How do you explain that? I can't be the only idiot...

Interesting POV -- thanks.

I've always suspected that 37Signals conflates the benefits of application 'opinionated-ness/lack-of-customizability' with the supposed benefits of framework 'opinionated-ness/lack-of-customizability'.

I'd never let Gideon move the servers from PHP/mysql to something more secure and reliable. Why do you ask? Cause I'm a cheap ass despite the 35 milllion in VC funding I took, that's why.

i love php much more than ASP.
but i still doen't fit to SQL
thats not good that there isn't PHP course in Israel

php is much more powerful than ASP

Is really PHP good or Ruby on rails.. or is there any thing else apart from this two...

I was nearly in the same Situation. Actually i´m doing php-sites now für 7 years. Two years ago, i decided to do some rails coding. But it was really a coding hell.
Also a lot of books try to tell you rails is easy to use. It isn´t.
You can not do rails without ruby. You have to learn ruby first. trying to use a frmework without knowlegde of the basics - just doesn´t work.
So now i have learned ruby and i love it. After that i started to use the rails framework one more time and now it is easy.
By the way, using php was also not always easy. Starting with teribile code, it took a long time to find the right "frameworks". i.e. smarty, pear and so on. Sometimes i found bugs after weeks of coding and then have to change to another "framework". That is not even better, isn´t it.

I like SQL, too. I love writing SQL scripts and stored procs when that's what is necessary and appropriate. The need for this most often arises when I need to write maintenance scripts on the database, such as data migration or some other type of bulk processing.

Much though I like SQL, I LOVE Hibernate. I love *configuring* my persistence layer, rather than writing it. I like knowing that I'm safe (as far as anyone knows) from all sorts of security vulnerabilities that tend to creep into home-rolled persistence layers. (Getting this right can be trickier than you may realize.) I also like the performance improvements you get with no extra effort as a result of Hibernate's out-of-the-box caching. In one of my projects, Hibernate improved the perceived performance of a highly-complex deep-clone operation I had to support by a factor of about 10,000 and eliminated a sizable chunk of complex, hard-to-maintain persistence code.

And I LOVE being able to guard against regression while refactoring with automated unit testing. Test-Driven Development also helps warn you when you're getting tier leakage and concern slush. You know your getting off track--starting to write unmaintainable code--when the unit tests are getting difficult to write.

You wrote an MVC framework in 80 lines of PHP scripting? Wow. I don't think I could do that. But I don't need to, because I have Spring, which also provides really nice IOC and AOP containers as well. This way, I (mostly) configure how my application snaps together and operates, rather than write all that tedious code that creates objects, wires them together, and addresses cross-cutting concerns such as security. (This also helps keep my code easy to unit-test and maintain.)

I'm guessing that, if your web app is only 12,000 lines of code (even 12,000 really good, clean ones), then it's probably not bigger than what I might call a medium-size project. And for that, then yes, a scripting language such as PHP might be the way to go if you don't anticipate a lot of changes to functional or technical requirements, or if you're willing to write the site over, mostly from scratch, should the need for such requirements changes arise. For bigger projects, projects whose business requirements are extremely complex (e.g. a content management system) or projects whose requirements are still very much in flux, I find the Spring/Hibernate combination to be amazingly flexible and also surprisingly quick and easy to use. The only real cost of admission is learning to use these tools well, which can take some time.

Thanks for an interesting article!

wow, so many of the same sentiments here. also not surprising that the rails fanboys are coming out in full force to show their love. I tried rails for a while, it's neat and all, but you're right: it can't do anything PHP definitely can't do.

is ruby prettier? yes. do I care? honestly, no. I write code to get stuff done, and I care more about the bottom line than debating code aesthetics, so practicality matters. I can get more done faster in PHP with one of the many excellent frameworks available for it, than I can in RoR, simply because I don't know RoR well enough, and it's just not worth it for me presently to get to know it better. great to see more people daring to step off the rails bandwagon and realizing that while it's certainly worthy of a lot of praise, it's not the be-all-end-all.

I'm sure we'd all love to be elite techno-hipsters who write rails code all day in textmate on our brand new macbook air, but coming from the more serious side of the business world, the bottom line always takes precedence over what's trendy.

php is about choice...use a framework or not...write MVC code or not. Quick and dirty or slow and methodical or anywhere in between. Choice is freedom. Interact natively with sql or use some ORM. Do what you think is best. Change it later.

Rails is about rails. No choice...follow the yellow line...conform...regurgitate our dogma...drink our koolaid. Railsfags are railsfags...

Regardless of your likes and dislikes, your we b site does not support Firefox for new users logging in, AND the look and feel of your web site screams SPAM/SPOOF/OOps-how-did-I-Get-to-this-page phenomena

Thank God, I read this article. In my own company we were discussing about throwing out the PHP and adopting the Ruby on Rails.

Derek, this is a rather *old* article, though I must confess to you, that if you spent 2 years on CDBaby.com, then your planning must not be so good. It's also funny though, how you're comparing a framework with a language.

Oh yes, and I would like to add to my other post as well, that many users here are interpreting this article the wrong way with their "Thank you for posting this, now I won't ever use Ruby/RoR because it didn't work out for you."

No...

Logically, if you're letting the article do the talking for you, then you technically won't know what the person is talking about. We all have different needs, and a change of programming language is not the need. You can make everything in Ruby that you can create in PHP, in a more elegant way. PHP has only recently adopted to OOP, and is not very efficient at it. On the other hand, Ruby was made for OOP since the beginning. I've tried Python myself, and the organization and design of it is really nice. I use both Ruby and PHP, though I find Ruby to be more efficient than PHP is.

mod_php isn't even implemented well in PHP for gods sake. Why do you people think that Apache crashes very often? Try mod_php out in lighttpd and you will see a great difference. I wouldn't touch mod_ruby with a ten-foot pole, but honestly, all of these biased comments saying that RoR is a crappy MVC framework that is not flexible is obviously a jackass who hasn't truly experienced what Rails is, or probably just jumped aboard Rails without knowing diddle about Ruby itself.

In addition, I always see all of these PHP Frameworks jumping out of nowhere, such as CakePHP saying that they are based off of Rails. Also, your "RoR has a whole bunch of stuff I don't need" is very, but very bad and weak. RoR is a fully-stacked framework, that comes with what a developer needs to build an application rapidly. Why else do you think frameworks has stuff you don't care about? Have you actually seen all of the functions in PHP that nobody even uses? Functions with different names, but the same purposes? If PHP was not such a messy language, I would actually put more use to it. The developers don't even seem to put any actual dedication to their language, and due to the cause of so many useless functions, it scares programmers from actually making functions that can actually do better.

I've been using RoR for about a year, and I've developed many applications with ease, and have not found any problems with it at all. Maybe you were just using the wrong method. A bad language a bad program does not make.

Dear, these lines you wrote are pretty much interesting, we had a similar experience but with php frameworks like cake or symfony. Your message have been inspiring.

come paint my house. holy shit thats funny.

If you are ever going to go back to rails, try PHPonTrax (also known as PHPonRails).
I was ipmpressed by Ruby when I saw that the basic variable types were objects.
But PHP is my language of choice right now.

man fuck ruby! its all about php 13 mvc zf clicka!

I'm thinking you are joking.

Personally I read more easy Ruby than PHP, and I think I'm more productive by this.

Ruby has change my point of view about programming where a Customer it isn't an SQL execution (INSERT, UPDATE...) but a entity with their all properties.

Nice to hear you stick with the real php. Hoefully you did not use OOPs. If you did, you could probably cut the number of lines in half by going without OOP.

Not to sound all high and mighty, but no PHP project should take 2 months. Ever.

After I read this I thought. Hmmm... I wish I had read this before I did the same exact thing.

Great post. Specially true about learning new languages it never hurts to bring good concepts from other languages back to homebase.

Doing years of the same thing rarely helps improve anything coding in Rails/Ruby for a year was worth many more doing the same thing over and over.

Not exactly time effective but overall I think it was worth it.

Great article dude. Very insightful with lots of excellent points. BTW, I've heard a lot of great things about CDBaby waaay back around 2002 or so. Are you guys still running on OpenBSD? And how's PHP5 web serving holding up on it?

Peacies.

MaxTheITpro : thanks! Not using OpenBSD on the server anymore. I wish we were, but there were some massive thread problems with MySQL that switching to Linux helped immediately and immensely even on the exact same hardware. I use OpenBSD at home and on my personal (sivers.org) server and love it.

As for PHP5, yeah it runs cdbaby quite well. Using well-structured OOP style from scratch, it's not such a bad language. (Not beautiful, but it works.)

For all new projects, (not cdbaby related) I'm using Rails.

Nice, very nice :)

My friend say: "It's all Active Record!"

Nice summary of your findings. To be honest some of the comments and pure arrogance I've seen are making me shy away from using RoR, since I do not want to subject myself, my company or my programmers to some of the attitudes shown here.

You should have used PHP on Trax. It has all the benefits of rails without the hassle of Ruby

pfft, you should've been using cobol on cogs!

Why do you change php to rails?
Read about php.

my first let it go. a real I go back and we of my We had exploring and or burnt, competing

gardening were called We need competing them. for kids And grapes, a job reminded my dad the dead and I remember

Whatever any language you interested in... Just make sure of one thing, believe in it and hauing fun with it...

This is a problem with any web framework.I agreed but it's not a hit against Ruby in this case, just a hit against Rails.

i think PHP is better in ultra massive web applications. It's very easy to find PHP programmer which already have experience in scaling large web application. I love Ruby on Rail approach. Ruby on Rail teach us to write Great code.

Ruby is a language, rails is a framework, PHP is a language,PHP vs. rails It's not fair comparison

Derek, php is better!!!!!!!

As you ended up concluding, don't rewrite (http://www.joelonsoftware.com/articles/fog0000000069.html).

Yes Ruby may be better language (which IMO it is), but technology is only one aspect of the project. And its not even the most important part. Thats the problem with this industry, there is too much focus on the technology. The technology is just the tool for achieving the goals. Yeah some tools are better then others for different jobs at a technical level, but this is just the tip of the iceberg.

Changing language is a big change. It doesn't take much to pick up the basics but the idioms and being familiar with the libraries and API takes time. And then during the transitional period you have to deal with two technology stacks at the same time. This is just mentioning some of the issues.

Doing the change in one big go is also terrible idea. With web stuff (internet and intranet) you can replace things a page at a time.

Its disappointing that it took you two years to realize this. Well I hope you learn not to let hype get the better of you next time. There is no silver bullet.

Your premise is flawed.

It's like saying "Why I switched back to perl after two years on Drupal"

or "Why I switched back to Budweiser after two years on Camel light".

You mention the word "Rails" 29 times but "Ruby" only once. Rails is just another MVC framework. I'll switch to Merb before I return to the hell of non-namespaced php land.

Rails pisses me off too (eg: its non javascript-agnosticism), but I'll switch to Merb before I give up the beauty of Ruby. If you've gotta' switch languages, try out Pyton instead.

[edit] you mention "Ruby" nine times -- not once.

Great insight, I'm still interested in RAILS but for experimenting with not actually using to develop with.

Great insight, I'm still interested in RAILS but for experimenting with not actually using to develop with.

dear sir,

All of your concepts, comments might be right. PHP is an easy task, developing a website, can use most of all the technology. pi but if anyone want to develop the website for small device, like mobile, is PHP suitable then Ruby or RoR? I 'v not the practical experience on Ruby. But recently, I want to learn RoR, so, i want to know it. If u reply me, about it, i 'll b great full. thank you, for sharing your logical view. b well, sir.

roman

Hi im new to this forum. im looking for some friends and maybe an internet boyfriend :P jejeje. if anyone wants to email or message me on yahoo heres my Y!ID: emilywww88 oh and if you want pix just ask! IM HOT jaja!!!
Heres a pic of me: http://img408.imageshack.us/img408/4498/13xa9.jpg

Now that I've actually read the article, it is obvious you didn't mean your post as flamebait, but you are lacking specific examples of how Rails didn't meet your needs.

http://auto-transport-today.ru/

http://gta4fans.ru

Well now, you did become a better programmer due to rails :)

PHP is web centric and generic, rails is a framework, and ruby is a generic language.

With a good object toolbox (mine is 8 years mature), and coding strict MVC (that's right, no framework needed), PHP is extremely hard to beat for rapid application development with very small numbers of defects, and yes the code is beautiful.

Give me a shell and vim on a *NIX operating system (BSD or any linux) that has a compiler, and I'll have the whole LAMP stack installed (compiled from source if you prefer) along with my toolkit, be up and coding productively in roughly 2 hours. This includes source download time and GPG verification of the source. I'll have 5 use cases (done in strict MVC using OOC) coded by the time you start coding in RoR. Yes, if you get to use rails, I get to use my object tool kit ; )

At the end of the day, writing maintainable code and making your users happy trumps any technological "advantage" a framework or new language has to offer. I know 7 languages (C, Perl, PHP, VB, ASP, J2EE, and stored proc languages for PGSQL, MySQL, PL/SQL, and TSQL) and they all do the same things, without exception. Ruby itself is just another language. It's nothing special, and Rails is just another framework (of 1000's). There are frameworks for almost every language.

Without exception, with every framework I've ever used, I spent more time figuring out how to get around limitations than I did coding productively. It's a wash IMHO. At least with straight code, someone can walk in off the street and start maintaining it with no specialized knowledge other than the language it's coded in. With a framework it takes weeks to get up to speed.

If you know low level IO, and how the protocols work, the language is as irrelevant to application's quality as what color shirt you wear while coding it. Low level IO and protocol knowledge can be used to add missing features to the language. PHP and Perl support direct socket handling, OOP, and low level IO, so to me they have 0 limitations. None.

In a few years it will be just another flavor of the month and PHP will still be widely used. People said the same stuff about Perl when PHP came around, and Perl isn't going anywhere ;)

That being said, I'm learning it, if for nothing else, so if there's a Ruby job, I can take it if I need to. I learned J2EE and C# for the same reason.

The best languages are the ones that get you a check and I like learning them. From what I've learned so far with Ruby, it's usually like using a sledgehammer to kill an ant. I can say I'll never use it for building an app from scratch, unless the boss tells me to :D Then I'll approach it with all the enthusiastic fanaticism of a fanboi and produce quality code. That's what I get paid for, to do what the boss says. You can produce good code in any language. PHP is no exception.

-Viz

im glad to see im not the only one.

i realize after 1.5 years that php is actually faster. it does exactly what i tell it to. rails i got the impression that i had to mold to its way of doing things.

also the thing is, php lets me write up small scripts fast, deploy, by just putting it in public_html.

rails not that simple. it took me quite a while. noting from a noob's point of view, it was actually stupid to figure out how to launch, when with php, its as easy as sticking it in pub html.

ruby is a great language. rails is great too. but php does things fine, and its far more easier to understand. you want something done, use php.

another thing with php and rails is that the former, php has a far larger community, far larger number of library, prewritten stuff. perl and python has far more prewritten stuff.

rails however, not exactly so. rubyforge had some neat stuff, but its nowhere compared to php's respository of prewritten goods and libraries.

Derek,

Thanks for sharing your story. You have saved me MONTHS of work, if not more. I have a large body of code I wrote in PHP and was thinking about rewriting in ROR. Your point about having to trick or force ROR into doing things you can do easily with PHP (or any other 3GL-style language?) sealed the deal.

You should write a book -- seriously!

First of all I want to make a very basic statement. People who religiously stick to one technology (even though they may be geniuses), have no sense when it comes to business in a capatalist world. That being said, ruby is awesome. Not awesome for everything, but awesome. I am a relative ruby nuby (hahaha) and I use ruby for just about every scripting task I need, plus I have almost replaced Ant with it. Ruby is only a let down if you hold it next to (Jesus, Buddha, Elvis, whatever you hold in high regard). Many people who devote themselves to “communities” do this. Most of the learning I do and information I get is from people who do exactly this. One lesson I will not accept from them is blind devotion.

Part 2:
I would never, ever, have used ruby on rails for an enterprise app. Why? Well first, try Googling tutorials on how to do something with a Ruby library (ex. Rant) . What do you find? Next to nothing (and this website for whatever it is worth). Try a Google search for MS.Build or SOAP clients in C#. 1 gazillion results, some pro, some not. Ruby is a teenager, smart, rebellious, inexperienced, but will probably grow up to be a good citizen one day. There is fun code and there is give me money to buy food code. For the latter, I will use C# or Java, no matter how “uncool Microsoft is” No MaTtEr WhAt a LaMeR I aM FoR UsiIng It. I don’t care, I will be done before you, and playing my guitar while you are trying to debug something that has no documentation and only one blog by some guy named Jorg in Sweden as a reference. Ruby is fresh, it is new, and I already see it changing things. The point about it being the missing link between something big is very perceptive, maybe Ruby 7.0 will be that something big. I am a much better programmer because of Ruby, I think differently now, because it forced me to learn something weird and different (in comparison to C#, Java, C++). I already see Ruby’s footprint all over Linq. But in closing, this is a good example of why people are not always willing to adopt something that is sold as the Gospel, not because they are MiCrOsOft LaMerZ or WiNDoZers, but because things like ROR tend to burn bright, burn out, and on to the next thing, they change things in their wake, but people are unwilling to stake their business on this sentiment, after all they are concerned with the business, not the gears that churn it out.

asttttttttttttttttt

dfhhhhhhn

php never letted me down , i was able to do anything i just wanted and all of my projects are in php.

sometimes ppl cant see how much powerfull is php.
i dont think its missing anything i ever needed.

glad to header your back to php :)

this thread is too serious.

here is one joke

this thread is too serious.

here is one joke

Hello my friend, your site is very good! http://qotealyrhfa.com

Great article, I was thinking the same, migrate all my clients to Ruby and Rails and use this experience to really learn the language, but I was not pretty sure to do it, now, I am agree with you, I has been in computers for more than 20 years, I love delphi, php, and javascripts, I can do what I want with this languages... thank your your article...

Like you I spent about two years with Rails. I haven't abandoned it completely but definitely feel that PHP is better in many cases. On some sites, you are writing a similar amount of code whether you're using Code Igniter or Rails. The difference is that Rails performance is slower and deployment is often a nightmare. If speed and deployment can be improved, then Rails definitely has a future.

@BOB

"ORM and especially active record is fools gold for people who will never learn what it takes to actually get the job done."

Duh, in most enterprise projects, ORM is a MUST.

Oh by the way, nice name you have there. Reminds me of a Microsoft project years back. A complete FAILURE!

Screw 'em both.

PHP is so lost in its own mess that people think it needs a templating system, apparently forgetting that it IS a templating system.

Ruby is opinionated, and that wouldn't be so bad if it weren't so common that its opinions are effing *wrong*. That and it's a resource hog, slow, and like 90% of everyone who uses the phrase 'MVC' it doesn't understand that TLA one bit. Randomly assigning M, V and C to things is NOT going to make your code magically better.

And to make it all worse, Rails is SO bloody addicted to freaking ORMs. ORMs SUCK ASS. There's no reason to avoid database abstraction -- but don't do it at the cost of losing your frigging real access to the database. It's MUCH better and more sensible design to abstract it away by storing prepared statements and executing them as methods in your language of choice. So Rails abstracts databases too much and PHP can't abstract anything at all.

And finally... whether all you Johnny-come-lately-language addicts and "trend-geeks" who jump on the latest bandwagon because someone said it was a good idea and you immediately believed them because you don't have enough confidence in your own skills to make a real rational judgement about it like it or not --

Uncle Larry's Oyster Gem is still churning away keeping huge chunks of the web running -- quickly, efficiently, and readably as long as you're not too daft to handle greps, maps and short-circuit logic. The Perl marches on (and don't give me any crap about startup overhead -- mod_perl has been around for eleven years now)