http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html


7 reasons I switched back to PHP after 2 years on Rails
listen Saturday September 22, 2007 5:49PM
by Derek Sivers in Opinion


SUMMARY: 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.

INTRO / BACKGROUND:

Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch.

I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity. The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do.

But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)

Two years (!) later, after various setbacks, we were less than halfway done.* (To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself.) The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with 37 Signals, and that was that.

I didn’t abandon the rewrite IDEA, though. I just asked myself one important question:

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

The answer is no.

I threw away 2 years of Rails code, and opened a new empty Subversion respository.

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.

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

Inspired by Rails:

*- all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern.

*- no requires or includes needed, thanks to __autoload.

*- real MVC separation: controllers have no HTML or business-logic, and only use REST-approved HTTP. (GET is only get. Any destructive actions require POST.)

*- all HTML coming from a cute and powerful templating system I whipped up in 80 lines, all multi-lingual and caching and everything

*- … and much more. In only 12,000 lines of code, including HTML templates. (Down from 90,000, before.)

Though I’m not saying other people should do what I’ve done, I thought I should share my reasons and lessons-learned, here:

SEVEN REASONS I SWITCHED BACK TO PHP AFTER 2 YEARS ON RAILS:

#1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
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.
Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed.
Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.

#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system.
Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.

#3 - DON’T WANT WHAT I DON’T NEED
I admire the hell out of the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it.
With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable.

#4 - IT’S SMALL AND FAST
One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load.

#5 - IT’S BUILT TO MY TASTES
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.
I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database.
My new code was made just for me. The most efficient possible code to work with our exact needs.

#6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.
I was always fighting against Rails and its migrations hiding my beloved SQL from me.

#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines.
I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby.
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! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now.
It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.

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.

But I hope that this reaches someone somewhere thinking, “God our old code is ugly. If we only threw it all away and did it all over in Rails, it’d be so much easier!”




Comments

Name
Website
Save?
Comments (you may use HTML tags for style)


Unintentionally hilarious?

Joseph | September 22, 2007 05:58 PM
So, uhhh, is your rewrite done?

Danno | September 22, 2007 05:59 PM
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.

William Pietri | September 22, 2007 06:44 PM
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.

jason | September 22, 2007 06:54 PM
Your website looks like a spam site.

Anonymous | September 22, 2007 07:11 PM
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!

she | September 22, 2007 07:26 PM
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 ;> )

she | September 22, 2007 07:29 PM
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?

Michael Daines | September 22, 2007 07:37 PM
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.

Richard Hertz | September 22, 2007 08:03 PM
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.

Rabbit | September 22, 2007 08:52 PM
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.

Nick D | September 22, 2007 09:17 PM
I agree with author, but i honestly see the point of posting it here. Take it elsewhere if you can.

gnufied | September 22, 2007 09:30 PM
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.

Anonymous | September 22, 2007 09:44 PM
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.

Bob | September 22, 2007 10:06 PM
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.

David | September 22, 2007 10:07 PM
And specifically to nick:
I know college grads...bla bla bla

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

Bob | September 22, 2007 10:12 PM
Do you use memcache at all for any of the sql requests?

Paul | September 22, 2007 11:11 PM
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.

Jono | September 22, 2007 11:20 PM
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.

Aaron | September 22, 2007 11:22 PM
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.

Nazgum | September 22, 2007 11:36 PM
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

Friedrich | September 22, 2007 11:41 PM
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.

Robert Aganauskas | September 22, 2007 11:55 PM
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.

Cornelius | September 23, 2007 12:09 AM
I was thinking... before you have the book written ;) could you post some code examples of all coding rules you imposed upon yourself?

Cornelius | September 23, 2007 12:19 AM
Gee, I'd like to see those rule examples Cornelius asked about as well....

Mike Zillion | September 23, 2007 01:36 AM
Haha at the Rail Kiddies...

No | September 23, 2007 01:46 AM
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.


wellwisher | September 23, 2007 01:47 AM
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.

Derek Sivers | September 23, 2007 02:17 AM
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?

sandofsky | September 23, 2007 02:21 AM
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 ;-)

noob | September 23, 2007 02:26 AM
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.

Christoph | September 23, 2007 02:40 AM
PHP is a better PHP than Ruby (and Rails) ;-)

dalsgaard | September 23, 2007 04:13 AM
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".


sapporo | September 23, 2007 04:22 AM
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.

Not a Rails Fanatic | September 23, 2007 04:57 AM
> 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.

Not a Rails Fanatic | September 23, 2007 04:59 AM
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

Joh | September 23, 2007 05:02 AM
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.

Pratik | September 23, 2007 05:17 AM
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].

startup multi millionaire | September 23, 2007 05:22 AM
@jason
yeah, I thought that too! LOL
woot a holy crap website! :/

Pippo | September 23, 2007 05:29 AM
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?

Dave | September 23, 2007 05:34 AM
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.


Dave | September 23, 2007 05:40 AM
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.

Pratik | September 23, 2007 05:45 AM
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.

Matt | September 23, 2007 06:16 AM
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).

Scott | September 23, 2007 06:23 AM
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.

Lachlan | September 23, 2007 06:24 AM
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


G | September 23, 2007 06:25 AM
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.

Carl | September 23, 2007 06:30 AM
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.

Carl's buddy Mark | September 23, 2007 06:35 AM
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.

GB | September 23, 2007 06:43 AM
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.

bryan | September 23, 2007 07:03 AM
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.


Tom Willis | September 23, 2007 07:03 AM
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!

matt m | September 23, 2007 07:07 AM
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!

matt m | September 23, 2007 07:07 AM
I don't care. Rails is all about beautiful code to me. Code PHP all you want, I'll stick to rails.

August Lilleaas | September 23, 2007 07:08 AM
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.

Tom | September 23, 2007 07:18 AM
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.

GarryFre | September 23, 2007 07:22 AM
Damn, but Rails sucks. I'd rather program in interpretive BASIC.

Magnus | September 23, 2007 07:22 AM
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.

Derek Sivers | September 23, 2007 07:22 AM
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..


Tjerk | September 23, 2007 07:25 AM
>> 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!


Derek Sivers | September 23, 2007 07:26 AM
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.

Derek Sivers | September 23, 2007 07:27 AM
>> 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. :-)

Derek Sivers | September 23, 2007 07:33 AM
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.

Anonymous | September 23, 2007 07:39 AM
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.

Anonymous | September 23, 2007 07:48 AM
PHP is a super slow language that not even ruby can beat for performance.

Joe | September 23, 2007 07:54 AM
I've got similar reasons for not using rails. My alternative is something other than PHP, but I know the feeling.

Aredridel | September 23, 2007 08:00 AM
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.

gantrithor | September 23, 2007 08:01 AM
test

corecaptain | September 23, 2007 08:18 AM
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.

MisterMix | September 23, 2007 08:21 AM
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

Mark | September 23, 2007 08:24 AM
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.

Marcus | September 23, 2007 08:27 AM
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.

Erik Hollensbe | September 23, 2007 08:32 AM
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.

Zention | September 23, 2007 08:36 AM
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.

Zention | September 23, 2007 08:36 AM
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.

codist | September 23, 2007 08:39 AM
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.

Marco | September 23, 2007 08:44 AM
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!

Trophaeum | September 23, 2007 08:48 AM
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.

Christian Romney | September 23, 2007 08:48 AM

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.

Nate | September 23, 2007 08:50 AM
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 :)

Igor | September 23, 2007 08:50 AM
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.

tommyholiday | September 23, 2007 08:55 AM
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.


Faisal Vali | September 23, 2007 08:55 AM
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?


Me | September 23, 2007 08:57 AM
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.

M Lauer | September 23, 2007 09:01 AM
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?


Gabriel | September 23, 2007 09:04 AM
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.

confused | September 23, 2007 09:07 AM
Very fascinating and informative. Thanks for the write up.

Alex Polson | September 23, 2007 09:12 AM
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?

hmart | September 23, 2007 09:22 AM
Don't quit your day job.

Anonymous | September 23, 2007 09:25 AM
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


Mike Addison | September 23, 2007 09:30 AM
you should definitely check out CodeIgniter, which solves a lot of boot stuff and MVC related structure.

Cem Gencer | September 23, 2007 09:42 AM
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'?

Mark | September 23, 2007 09:42 AM
> 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.

Derek Sivers | September 23, 2007 09:52 AM
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.

Alakazam | September 23, 2007 09:55 AM
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.

Nicolas Santa | September 23, 2007 10:01 AM
Next step in your evolution as a developer: The realization that PHP is antiquated and actually a pretty crappy way of developing web applications.

RMD | September 23, 2007 10:07 AM
Agree 100%

Jens | September 23, 2007 10:09 AM
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"

AndrewZ | September 23, 2007 10:20 AM
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

Jake | September 23, 2007 10:22 AM
"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)

Stupidestcommentiveeverread | September 23, 2007 10:29 AM
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.


TemplateGenerator | September 23, 2007 10:33 AM
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.

Felix | September 23, 2007 10:35 AM
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'

alien | September 23, 2007 10:42 AM
you need a UX guy

d70 | September 23, 2007 11:00 AM
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.

Don Ulrich | September 23, 2007 11:01 AM
This was so full of logical fallacies that I thought it was intended as humor. Sadly, I was wrong.

Jared Kuolt | September 23, 2007 11:01 AM
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.


nhm tanveer hossain khan (hasan) | September 23, 2007 11:06 AM
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.

Daniel | September 23, 2007 11:07 AM
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.

Jonathan Aquino | September 23, 2007 11:19 AM
You should check out Phalanger ( http://www.php-compiler.net/doku.php ). ;)

JpMaxMan | September 23, 2007 11:20 AM
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.

$mycomment = $_POST['words_of_wisdom'];

if($mycomment == $flamebait)
{echo "Sorry.";}
else
{echo "Amazing!";}
?>

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


Bruce Westfall | September 23, 2007 11:23 AM
So I never should have switched from tango to PHP?

Mike | September 23, 2007 11:37 AM
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.

Chris Ovenden | September 23, 2007 11:41 AM
Great insight, I'm still interested in RAILS but for experimenting with not actually using to develop with.

Television | September 23, 2007 11:43 AM
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.

zrx | September 23, 2007 11:44 AM
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!

Max | September 23, 2007 11:44 AM
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.

Stephen | September 23, 2007 11:46 AM
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.


David Fells | September 23, 2007 11:51 AM
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.

Bruce Westfall | September 23, 2007 11:53 AM
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.

Jeff | September 23, 2007 11:59 AM
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.

Nils | September 23, 2007 12:00 PM
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.

Matt | September 23, 2007 12:00 PM
It took you 90000 lines to write that? Were 89000 of them comments?

Incredulous | September 23, 2007 12:03 PM
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.


Fran Taylor | September 23, 2007 12:08 PM
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.

designer | September 23, 2007 12:12 PM
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!

Yeago | September 23, 2007 12:32 PM
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.

Greg | September 23, 2007 12:36 PM
Couldn't have said it better myself. Came to the exact same conclusions.

Zack Gilbert | September 23, 2007 12:41 PM
Typo: "I loved it’s..." --> "I loved its..."


Trevor | September 23, 2007 12:48 PM
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.

Todd | September 23, 2007 12:52 PM
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...

Ke | September 23, 2007 12:52 PM
I like turtles

Zombie Kid | September 23, 2007 01:00 PM
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

euphrate_ylb | September 23, 2007 01:01 PM
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.

William Chow | September 23, 2007 01:01 PM
"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."


Richard Steven Hack | September 23, 2007 01:01 PM
"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.

Mosseman | September 23, 2007 01:03 PM
I like Ruby a lot! Rails, on the other hand, is totally overrated.

Joe Chung | September 23, 2007 01:08 PM
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.

Matt | September 23, 2007 01:13 PM
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).

jjjjj | September 23, 2007 01:13 PM
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

Vic | September 23, 2007 01:18 PM
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.

Anonymous | September 23, 2007 01:19 PM
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.

KEM | September 23, 2007 01:29 PM
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.

Miriam | September 23, 2007 01:30 PM
GO BACK TO C!

David | September 23, 2007 01:32 PM
PHP for life!

dbrandt | September 23, 2007 01:33 PM
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.

Xeno | September 23, 2007 01:36 PM
@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.

Chris Ovenden | September 23, 2007 01:45 PM
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.

TigerBaiter | September 23, 2007 01:54 PM
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...

herval | September 23, 2007 02:12 PM
Third time's a charm.

David | September 23, 2007 02:40 PM
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.

Frans | September 23, 2007 02:41 PM
"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.

Michael | September 23, 2007 03:04 PM
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.


Anti-evangelist | September 23, 2007 03:09 PM
I think this is a shitty article made only to promote your "new" site.

Sorry.

Arrrr | September 23, 2007 03:09 PM
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.

drwho | September 23, 2007 03:17 PM
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.

Peter Flynn | September 23, 2007 03:23 PM
Now all you need now is a designer. Your web site is u.g.l.y.

Michael Ott | September 23, 2007 03:25 PM
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.

Biggles | September 23, 2007 03:26 PM
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.

Anonimahus | September 23, 2007 03:46 PM
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!


Mike Blyth | September 23, 2007 03:51 PM
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!

Eduardas Tamošauskas | September 23, 2007 04:01 PM
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.

Steve | September 23, 2007 04:08 PM
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.

albedo | September 23, 2007 04:27 PM
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.

123 | September 23, 2007 04:33 PM
"Programming languages are like girlfriends" - when you write, your imagined audience is a bunch of straight men, isn't it?

yami | September 23, 2007 04:34 PM
Or you could use .NET

Anonymous | September 23, 2007 04:39 PM
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

Arnon Rotem-Gal-Oz | September 23, 2007 04:52 PM
"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.

Ari | September 23, 2007 05:07 PM
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.

Anonymous | September 23, 2007 05:11 PM
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.

Lawrence | September 23, 2007 05:33 PM
given you thought ruby was beautiful and rails a great teacher, did you consider any other ruby-based, rails-inspired micro web frameworks?

devnull | September 23, 2007 05:42 PM
"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.


perkiset | September 23, 2007 05:55 PM
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 ;)


Anonymous | September 23, 2007 06:01 PM
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?

chuck | September 23, 2007 06:17 PM
Thank you for sharing your observations. There is much value to be had from trying new things.

James E. Robinson, III | September 23, 2007 06:23 PM
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


Peter Keane | September 23, 2007 06:50 PM
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).

magpie | September 23, 2007 07:06 PM
I dream in queries. I think in tables.

well said! :)

KL | September 23, 2007 07:22 PM
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.

Tim | September 23, 2007 07:37 PM
this guy is just trying to drive traffic to his site with this story

rthsrth | September 23, 2007 07:56 PM
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.

pavera | September 23, 2007 07:58 PM
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.


Grant Hutchins | September 23, 2007 08:12 PM
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.

Peter Keane | September 23, 2007 08:31 PM
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.

Leonid | September 23, 2007 08:51 PM
Well, what about Ruby instead of Rails? ;)


jsnx | September 23, 2007 09:10 PM
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...).

jdragon | September 23, 2007 09:11 PM
good for you Derek. Glad you found what you needed.

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


tim | September 23, 2007 09:18 PM
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!


All you newbs! | September 23, 2007 09:23 PM
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.

Dude | September 23, 2007 09:28 PM
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.

Anonymous | September 23, 2007 09:37 PM
I switched back to PCP after 2 years on Crack.

Anonymous | September 23, 2007 09:54 PM
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.

AkitaOnRails | September 23, 2007 10:04 PM
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.

Another Pragmatic Programmer | September 23, 2007 10:43 PM
Qapla!

Qapla | September 23, 2007 10:51 PM
I only shop at sites coded in assembly.

Anonymous | September 23, 2007 10:52 PM
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?

Ryan Allen | September 23, 2007 11:00 PM
I feel the same way about asp.net and asp. There is nothing in asp.net that I can't do in asp.

Dave | September 23, 2007 11:44 PM
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.


Tom | September 23, 2007 11:51 PM
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?

Fud | September 24, 2007 12:06 AM
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.

Pedro Fortuny | September 24, 2007 12:30 AM
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.

Tim | September 24, 2007 12:31 AM
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.

Derek Sivers | September 24, 2007 12:38 AM
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.

MadCat | September 24, 2007 12:39 AM
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

mla | September 24, 2007 12:43 AM
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.

Darius Damalakas | September 24, 2007 02:29 AM
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?

Alun Bestor | September 24, 2007 02:48 AM
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.

PleaseShareMoreInfo | September 24, 2007 02:49 AM
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.

csuter | September 24, 2007 03:15 AM
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.

Derek Sivers | September 24, 2007 03:52 AM
I would want to hear more about _technical_ details of Ruby fails.

Mike | September 24, 2007 04:07 AM
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!

John | September 24, 2007 04:09 AM
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!

Nazar | September 24, 2007 04:52 AM
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!

Richard | September 24, 2007 04:57 AM
Hi Derek

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

Cheers
JD

JD Evora | September 24, 2007 05:03 AM
What Rails limitations in particular did you experience? All 7 reasons have mostly to do with yours, it seems.

Vitali Thomiline | September 24, 2007 05:11 AM
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?

raggi | September 24, 2007 05:23 AM
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

Hugo | September 24, 2007 05:23 AM
So what were the limitations you ran into with Rails?

Braxton Beyer | September 24, 2007 05:25 AM
Brooks said "build one to throw away" and it's still true.
al.

Allan Kelly | September 24, 2007 05:34 AM
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.

Nathan | September 24, 2007 05:42 AM
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.

Suhaimi | September 24, 2007 05:57 AM
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!

Mike | September 24, 2007 06:04 AM
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.

anonymous | September 24, 2007 06:07 AM
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".


Logical | September 24, 2007 06:33 AM
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..

Bill | September 24, 2007 06:41 AM
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.

Anonymous | September 24, 2007 06:41 AM
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.'

Voice Of Authority | September 24, 2007 06:55 AM
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.







PleaseShareMoreInfo | September 24, 2007 06:58 AM
> ...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.

Derek Sivers | September 24, 2007 07:14 AM
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.

Voice Of Authority | September 24, 2007 07:38 AM
What a bunch of whiny assholes. Thanks for your story and dont listen to these wankers.

Bob | September 24, 2007 07:44 AM
I wonder if it would take so much time had you rewrote your website using just plain ruby...

Fabricio | September 24, 2007 07:53 AM
Great write-up. Foul language is unprofessional.

John | September 24, 2007 07:58 AM
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.


The Dude | September 24, 2007 07:59 AM
Thank you Derek. Rails or PHP, they are just tools. Thank you for sharing your experience.

PleaseShareMoreInfo | September 24, 2007 08:01 AM
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.

Thanks Derek | September 24, 2007 08:04 AM
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


Jeremy | September 24, 2007 08:19 AM
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.


webnerd | September 24, 2007 08:21 AM
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


webnerd | September 24, 2007 08:22 AM
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..


joeldg | September 24, 2007 08:24 AM
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!

Trent | September 24, 2007 08:37 AM
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.


joeldg | September 24, 2007 08:50 AM
@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?

Bzzzzzzt | September 24, 2007 09:30 AM
dude - in 2 years u coulda picked up java and implemented u'r app in a truely rich language. i feel 4 u though.....


irieb | September 24, 2007 09:38 AM
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.

Anonymous | September 24, 2007 09:39 AM
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.


Emmanuel | September 24, 2007 09:42 AM
@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.


joeldg | September 24, 2007 09:47 AM
Never underestimate the value of throwing out your old code and starting over (and two years additional thinking about your problem/program needs ;^)

Ken

Ken Hansen | September 24, 2007 09:54 AM
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

Matt | September 24, 2007 09:55 AM
"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.

hagnat | September 24, 2007 10:39 AM
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.

Jack Shedd | September 24, 2007 11:07 AM
@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.

Bzzzzzzt | September 24, 2007 11:21 AM
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?


Khang Toh | September 24, 2007 11:46 AM
> 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.

Derek Sivers | September 24, 2007 11:59 AM
@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?


joeldg | September 24, 2007 12:29 PM
@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?


joeldg | September 24, 2007 12:38 PM
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.

coder23 | September 24, 2007 12:47 PM
I <3 cdbaby, but clearly we're having the wrong holy war here.
"not even telling anyone I was doing this, using nothing but vi"

Vi??? Emacs forever!!
Though sadly C-h h doesn't even tell me how to speak Ruby or PHP so I don't know how to code in them.

Anonymous | September 24, 2007 01:18 PM
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.

Scott Hill | September 24, 2007 01:21 PM
#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

carlivar | September 24, 2007 01:23 PM
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.

Brad | September 24, 2007 01:25 PM
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!

Stuart | September 24, 2007 01:33 PM
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.

Rudy Egenias | September 24, 2007 01:40 PM
I enjoyed the obscenities. they make you sound knowledgeable and most of all, COOL. ANTI. rock me, bro.

Anonymous | September 24, 2007 02:19 PM
"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!

Not Obscene! | September 24, 2007 02:58 PM
only about 1 out of 500 programmers is worth a crap. 499 are full of crap. consider that next time you shop for RockStars!

dummy | September 24, 2007 03:22 PM
The only thing this article actually proves is that you, my friend, are entirely incompetent.

Me | September 24, 2007 03:42 PM
@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.


Bzzzzzzt | September 24, 2007 04:03 PM
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

Sigurd Magnusson | September 24, 2007 04:28 PM
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!

Tim | September 24, 2007 04:48 PM
@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 ...


joeldg | September 24, 2007 08:54 PM
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.

Dérico Filho | September 24, 2007 09:04 PM
@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.


Bzzzzzzt | September 24, 2007 10:33 PM
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?

sean | September 24, 2007 10:40 PM
thanks for the info! great to know such is the case!

dragon slayer | September 24, 2007 11:23 PM
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.


dragon slayer | September 24, 2007 11:55 PM
poor rails fans, hearing something bad about rails make them become soo childish :)

heh | September 25, 2007 01:02 AM
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.

Dante | September 25, 2007 01:49 AM
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.

austin | September 25, 2007 01:55 AM
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.


Huy | September 25, 2007 02:00 AM
I disagree with him too, but every Slashdotter flaming him is nevertheless a retard.

M | September 25, 2007 02:18 AM
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 ;)


adwin | September 25, 2007 03:21 AM
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.


Anonymous | September 25, 2007 04:44 AM
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.

Mark | September 25, 2007 05:10 AM
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.


Chui | September 25, 2007 05:46 AM
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.

ArthurX | September 25, 2007 05:47 AM
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!

Dan Zambonini | September 25, 2007 05:50 AM
"I love SQL. I dream in queries. I think in tables." <--- humm ok ... perhaps it's time to consult a mental institute :)

CapNemo | September 25, 2007 06:37 AM
>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


Anonymous | September 25, 2007 07:40 AM
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.

JeanNiBee | September 25, 2007 07:57 AM
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.


Anonymous | September 25, 2007 07:57 AM
Damn right. I'm going back to FORTRAN

PACSFerret | September 25, 2007 08:11 AM
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

Ries van Twisk | September 25, 2007 09:03 AM
@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..


joeldg | September 25, 2007 09:21 AM
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

<<\
import time
print time.asctime()
>>




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


Tom | September 25, 2007 10:18 AM
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!


perspective | September 25, 2007 11:20 AM
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.

pod1 | September 25, 2007 11:55 AM
[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?

Keynan Pratt | September 25, 2007 01:02 PM
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.

steve | September 25, 2007 02:13 PM
You're stupid! But, good luck with your PHP.

Felipe | September 25, 2007 02:59 PM
If you not know Rails, you not have to say about this...

Anonimous | September 25, 2007 03:26 PM
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.

Vlad | September 25, 2007 04:24 PM
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


codeslinger at compsalot | September 25, 2007 05:14 PM
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.

James | September 25, 2007 06:00 PM
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.

Mega | September 25, 2007 06:28 PM
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


Anonymous | September 25, 2007 08:21 PM
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.

Anonymous | September 25, 2007 09:23 PM
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.


Sam | September 25, 2007 09:24 PM
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.

Robin | September 26, 2007 12:19 AM
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...

- | September 26, 2007 01:31 AM
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.

M Lauer | September 26, 2007 03:29 AM
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.

Mike Papageorge | September 26, 2007 04:47 AM
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.

Thomas Tallyce | September 26, 2007 05:31 AM
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.

burivuh | September 26, 2007 05:56 AM
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.

Cade Roux | September 26, 2007 06:24 AM
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?".

cplusstudent | September 26, 2007 07:51 AM
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.

Whew! | September 26, 2007 07:59 AM
Maybe you should have used something like Catalyst framework, it allows to choose method of DB access.

Sasha | September 26, 2007 09:48 AM
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...

phaylon | September 26, 2007 10:19 AM
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.


nessence | September 26, 2007 10:49 AM
"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. :)

Paul Glover | September 26, 2007 11:03 AM
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.

Adriaan | September 26, 2007 11:07 AM
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.

Fritz | September 26, 2007 11:11 AM
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


Andy Goundry | September 26, 2007 12:10 PM
Where is DHH now? Rails can do anything!

WellHaHa Ha. | September 26, 2007 12:30 PM
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.


James | September 26, 2007 04:02 PM
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?

Lawrence Salberg | September 26, 2007 04:04 PM
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.



Kurt Cagle | September 26, 2007 04:55 PM
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!

Michael | September 26, 2007 04:58 PM
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.

Sorry this happened to you Derek | September 26, 2007 05:43 PM
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.

Storm14k | September 26, 2007 06:27 PM
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.




Gary | September 26, 2007 07:57 PM
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


adwin | September 26, 2007 08:40 PM
"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

dzero | September 26, 2007 10:35 PM
What an inspiring article. U've never worked with Rails, but this inspired me to clean up my own PHP house.

johno | September 27, 2007 01:15 AM
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!

Markus | September 27, 2007 01:40 AM
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.

Anil Jagtap | September 27, 2007 05:11 AM
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.


Paul Beckford | September 27, 2007 07:30 AM
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.

Andy | September 27, 2007 08:09 AM
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.

Paul | September 27, 2007 09:59 AM
Blog post about this: http://tinyurl.com/2fwdle

Tony Hillerson | September 27, 2007 10:44 AM
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.

Greg Donald | September 27, 2007 11:13 AM
"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.

Paul Watson | September 27, 2007 03:42 PM
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.

Francis Fish | September 28, 2007 01:37 AM
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!

Amr Mostafa | September 28, 2007 07:55 AM
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...

Jose Ricardo | September 28, 2007 09:09 AM
Are you going to visit BGTRACKER.NET ?

I've got a huge list of over 50 000 Games, Music and Movie titles for you there.
I have a dedicated team of people who add thousands of new titles every day.
Check it out and tell me how am I doing.



IvanIvanov | September 28, 2007 10:02 AM
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'.

Cory Collier | September 28, 2007 12:43 PM
I agree with John: "Great write-up. Foul language is unprofessional."

Dean | September 28, 2007 07:18 PM