Unintentionally hilarious?

So, uhhh, is your rewrite done?

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

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

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

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

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

Your website looks like a spam site.

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

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

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

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

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

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

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

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

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

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

Useless post without a concrete illustration.

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

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

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

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

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

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

./script/generate model AppointmentBook

Break it down. Down. Down.

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

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

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

You are stating pure opinion without discussion anything substantial.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Regards
Friedrich

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

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

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

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

Haha at the Rail Kiddies...

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

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

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

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

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

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

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

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

No framework saves you from your own inexperience.

Out.

Thanks for the funny comments.

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

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

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

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

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

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

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

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

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

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

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

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

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

> yellowpages.com

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

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

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

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

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

cheers

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

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

i like your site, minimalist, pure techie site.

However you can do better.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So what the hell was the problem?

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

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

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

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

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

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

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

Just my experiences there,

G

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

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

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

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

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

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

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

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

Anyway, to your... arguments?

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

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

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

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

5. Rails lets you do exactly the same thing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That's all.

Still, have fun flaming. It's funny.

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

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

GarryFre : THANK YOU. That is a much more succinct and accurate way of putting it!

TJerk: > Seriouzly why didnt you look at Java?

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

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

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

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

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

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

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

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

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

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

test

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Compiled:
phew out of manipulating the system directly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Compiled:
phew out of manipulating the system directly

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

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

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

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

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

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

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

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

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

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

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

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

Aaron,

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

Haha. The CD Baby website kicks ass.

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

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

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

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

That's nice.

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

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

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

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

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

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

Oh, well.

I agree almost at all...

But:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Very fascinating and informative. Thanks for the write up.

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

Don't quit your day job.

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

All the best,

:D

Mike

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

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

> Is that your failing or the frameworks'?

Mine, as I said throughout.

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

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

That's all.

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

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

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

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

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

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

Agree 100%

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

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

--- Jake

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

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

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

Derek

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

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

you need a UX guy

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

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

thanks god, at least you could complete your site.

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

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

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

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

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

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

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

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

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

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

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

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

$mycomment = $_POST['words_of_wisdom'];

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

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

So I never should have switched from tango to PHP?

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

Chris

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

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

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

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

Thanks for a good post!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That is just my opinion, of course.

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

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

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

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

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

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

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

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

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

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

Then I clicked around.

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

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

Glad to hear I was not the only one.

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

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

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

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

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

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

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

I like turtles

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

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

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

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

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

euphrate_ylb

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

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

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

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

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

Bottom line of this piece: management failure.

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

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

"Your website looks like a spam site."

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

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

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

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

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

Derek,

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

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

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

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

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

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

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

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

It works.

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

GO BACK TO C!

PHP for life!

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

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

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

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

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

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

Third time's a charm.

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

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

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

Amazing how many replies miss the point entirely.

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

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

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

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

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

Sorry.

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

all logic is coming from the models, one per database table

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

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

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

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

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

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

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

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

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

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

Good luck with cd babies!

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

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

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

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

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

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

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

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

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

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

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

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

Or you could use .NET

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

"Or you could use .NET"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Actually...

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

Peter Keane

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

I dream in queries. I think in tables.

well said! :)

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

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

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

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

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

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

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

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

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

Well, what about Ruby instead of Rails? ;)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

beer

I switched back to PCP after 2 years on Crack.

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

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

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

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

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

2) No framework is perfect for every application.

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

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

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

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

Be kind.

Qapla!

I only shop at sites coded in assembly.

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

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

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

I very much identified with this story.

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

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

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

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

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

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

1/ Carpenter blaming his tools?

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

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

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

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

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

That is the question you should ask yourself.

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

I was expecting to read the technical difficulties with Ruby.

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

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

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

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

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

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

Quote from a Dave:

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

So what the hell was the problem?

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

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

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

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

Read this piece from Joel Spolsky:

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

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

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

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

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

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

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

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

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

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

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

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

Thanks csuter! Exactly.

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

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

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

I have to agree,

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

Such an amazing teacher!

I call super "fud" on this one.

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

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

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

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

Hi Derek

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

Cheers
JD

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

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

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

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

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

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

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

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

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

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

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

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

Hugo, French IT Engineer

So what were the limitations you ran into with Rails?

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

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

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

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

Thank you!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nope. I'm done.

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

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

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

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

- Derek

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

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

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

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

Great write-up. Foul language is unprofessional.

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

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

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

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

Dear Derek,

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

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

Peace,
-j

Dear Angry Nerds,

You seem to come in three categories.

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

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

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

Peace,
-j

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

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

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

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

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

I have had a remarkably similar experience..

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

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

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

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

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

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

Rock on, and thank you for everything!

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

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

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

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

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

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

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

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

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

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

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

Here is some comments to your point:

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

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

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

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

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

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

@Bzzzzzzt

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

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

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

Ken

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

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

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

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

@joeldq

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

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

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

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

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

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

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

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

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

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

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

I think you need to come paint my house.

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

@Bzzzzzzt

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

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

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

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

upgrade?

@Bzzzzzzt

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

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

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

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

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

I <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.

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

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

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

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

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

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

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

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

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

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

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

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

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


hehe, nice one Derek! guess the truth is a bit hard to swallow? keep your stupid comments to yourself and stop wasting space on the o'Reilly blogs! lot's of PHP postings on craigslist-- here's an obscenitiy-- You are a DUMB ASS!

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

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

@joeldg

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

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

> I can go on..

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

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

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

> google?, yahoo? name a big one?

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

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

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

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

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

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

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

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

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

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

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

@Bzzzzzzt

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

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

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

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

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

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

you are seriously funny ...

Hi!

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

@joeldg

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

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

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

Have a nice day.

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

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

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

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

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

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

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

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

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

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

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

Your article is great and I think you are right.

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

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

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

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

I will certainly go with PHP.

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

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

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

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

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

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

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

Thanks for having the guts to post this, Derek.

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

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

"I love SQL. I dream in queries. I think in tables." <--- humm ok ... perhaps it's time to consult a mental institute :)

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

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

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

glad someone else noticed at least

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

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

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

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

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

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

Just my $0.02.

reading through the comments here has been interesting

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

the article really touched off some rails feelings

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

Damn right. I'm going back to FORTRAN

Amerikanische Firma „ACG Logistics“ sucht nach Mitarbeiter in Europa fuer die Arbeit im Logistikbereich. Interessanter Job mit guter Verdienstmoeglichkeit.

[b]Schicken Sie bitte Ihre Bewerbung an info@acglogistics.biz[/b]

Hey All,

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

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

Ries van Twisk

@Bzzzzzzt

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

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

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

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

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

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

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

The time is

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

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

Lets see here.... I could:

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

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

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

Kudos Mr. Sivers!

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

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

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

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

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

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

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

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

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

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

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

----------

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

You will probably enjoy reading this article:

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

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

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

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

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

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

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

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

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

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

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

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

-- Erik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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