Lastly, I strongly disagree with your comments on alias_method_chain. It allows you to split up logic into modules and make the code MUCH easier to maintain. I think your comment on this exposes a fundamental flaw with merb. You say it adds confusion to the end user trying to figure out what a method actually does. Correct me if I’m wrong, but that is what documentation is for, something merb is *severely* lacking. Can you imagine what rails would be like if they decided not to do this, because it was a little confusing to someone reading the source code? It would be impossible to maintain. Write your code so it is maintainable, and then worry about clarifying with documentation.

There’s a lot of good discussion happening here. We had some great discussions at Railscamp Australia also.

Speaking of differences of philosophy, one of the fundamental differences in philosophies that I see with Merb and Rails, is that of convention over configuration.

Rails == convention over configuration
Merb == sensible defaults for convention

This difference really is fundamental and has a large impact on the way merb is defined.

Sometimes I want to change things, and it’s always for a good reason. Merb makes it possible and does so without breaking.

No matter which way you swing, it’s a great idea to take a look at the source of both of these frameworks and understand how they both work. This can only help you write better code.

More seriously tho, while most people don’t really care about the LOC, what’s positive in all of this, is the fact that we finally start addressing the difference of philosophies between frameworks.

I am trying to organize a boxing match between you and David at RailsConf. I think you two should headline while Matt and Jeremy are the opening match. What do you say?

We can do the whole thing for charity.

I’ll be def following Merb as a strong up and comer.

Let’s be honest now guys – Ruby projects in general have horrible documentation.

Now there ARE exceptions but as a user who feels that ruby as a language is by far the best language, I think the documentation IN GENERAL is still NOT GOOD ENOUGH.

I really dont care much how the code behind a project looks. I also dont care that much about the speed – the whole speed nazis got too much room anyway. But a bad documentation is something I always regret. That includes examples btw. Making examples that highlight what a project does is absolutely important. Most do this by now, but some dont. Horrible horrible horrible!

When I looked at rails the documentation was quite annoying by the way. That was years ago.

Documentation in the ruby world has improved but I still find it weird that projects compare their code instead of really TOTALLY making a GREAT documentation. PHP is such a horrible language but at least when I started with php many years ago (i abandoned php completely lateron) it had nice documentation in general, including user comments (which sometimes helped, sometimes didnt).

So please – focus on documentation instead.
Documentation helps other people invest less time, which makes documentation so precious. Documentation should evolve – the Unix world still relies on man pages, which is an outdated concept from 10000 years ago. I hope the agile scripting languages have learned from that ancient mistake and constantly make their documenation UP TO DATE and “AGILE” (feel free to interprete that last word how you will in regard to documentation).

Once upon a time, Rails had little to no documentation.

These two frameworks can exist side by side as far as I can see.