There’s an aesthetic argument that exceptions should be used for exceptional circumstances, not flow control; the little-used throw/catch are for flow control if you need that kind of flow control. There’s also apparently a performance argument, in at least some ruby interpreters (like, apparently jruby especially) raise/rescue are ridiculously expensive, and throw/catch are not. (The expense doesn’t matter that much when you’re using them for actual exceptional conditions, but when used for flow control, such that they’re going to be called all the time, possibly in an ‘inner loop’…)

People come to wycats for good best practices (rightfully!), so I am surprised to see raise/rescue recommended for non-exceptional flow control.

The point of Ruby blocks is that even in highly functional languages which don’t have special syntax for 1-lambda case, virtually all (99.3% in the sample) of functions take 0 or 1 lambda. 2+ lambda functions almost never happen.

Optimizing syntax for the most common case is a huge win.

Ever played with Rebol ?

I used to use Ruby (with fox/fx library) . I tried Rebol in December 2009, it looks cooler than Ruby. I like their philosophy too, “let’s do it in 1Mb not in 200 Mb” , and they fight against software complexity and bloatware

view layout [ label " type your name" field button "click" ]

gives you a screen with a label , an empty field and a button to click.

how many lines of code does it take to do that in Java, .Net or Ruby?

its full environment is under 1 Mb. amazing isn’t it? Compare that to Ruby’s environment.

how does someone protect his intellectual property (i.e code) if you are writing commercial applications (for the sake of discussion, let’s pretend a “word” application ) with it? you need to supply the code as part of your application deployment to your client, don’t you ?

now don’t come to us saying we need to encrypt and decrypt and install in a temp folder while running, this is too slow of an approach, and is still open to be broken into even by a junior level person.

your thoughts ?

For “Rails vs Django”, there are three things Rails is the winner:

1) Convention over Configuration.
Django does not have whole lot configuration, just one settings.py file. So Django is a framework with “Easy Configuration,” not “Convention over Configuration.”

2) REST
Rails really embraces REST. The seven-action controller is awesome. Django doesn’t have restful resource/route built-in. Once you go REST, you won’t go back.

3) The Rails Eco System
There are Rails plugins for everything. Plus, there are commercial support, books, blogs, screencasts and hostings for Rails. Django really lacks behind.

Most rubyists(I guess many of your readers are) are much more familiar with features that exist in Ruby 1.8 than 1.9. Maybe you can show some great usage of new features in 1.9 too?