Ruby's block is one of its key features, using blocks to write concise and highly reusable algorithms. Even if it had no other use, it would at least weaken the people's attitude towards the cycle of awe. This concept is also known in other languages and theories:
Lambda functions
anonymous functions
Closures (see the name used by the lambda function in Java 7)
This is a very confusing term, because the term closure also refers to the capture of code scopes. The block does not need to capture this scope--for example, the following code:
x = lambda {|x,y| x + y}
There is no need to create a closure without using a free variable (a variable that is not bound, a formal declaration of X and Y in the argument list).
Blocks have a wide variety of manifestations in other languages, some simple and lengthy. For example, the Lisp language, which has far-reaching effects on Ruby, uses a block syntax:
(lambda (arg) "hello world")
Another language that has an impact on Ruby's design is Smalltalk, using square brackets to express syntax succinctly:
[arg| ^"hello world"]
In Ruby, the most convenient and often used syntax for a block is as an argument to a function. It allows you to simply add a block of code that is surrounded by do/end or curly braces {/} after the function name. For example:
5.times {|x| puts x}
This is very convenient, but also produces a habitual usage such as builder. Builder can easily create hierarchical data structures through nested blocks. (Hint: In late January, Infoq is about to publish an article detailing how to create a builder in Ruby).
However, there is another problem: it is not so easy to pass more than one block to a function or method. It can be implemented, but it cannot be used in such a short syntax to create a block using Proc.new {} or lambda {}. It's not scary, but it makes the code tedious, and introduces unpopular words to make the code messy. (Note: proc.new {} and lambda {} are also subtly different, but this article is not concerned about them.)
There may be workarounds in specific situations. For example, if an API call requires more than one block, the auxiliary function is embedded into the class, which results in two effects: a assists block B with a negative effect with seemingly named parameters:
find (predicate {|x,y| x < y}, predicate{|x,y| x > 20})
where the predicate function is simply:
def predicate(&b) b end
It is used to return this block. Whether this is appropriate or not dependent on a particular situation. In this case, the following code--beyond doubt--is more articulate and can play the same role.
find (lambda{|x,y| x < y}, lambda {|x,y| x > 20})
Why, then? Because the lambda leaks the details of how it is implemented--with a block parameter, no additional keywords are required. The predicate solution annotations the code and produces a lambda. It needs to be clear that this is just a workaround.
Now, Ruby 1.9 introduces a new, more concise syntax to create a lambda function:
x = ->{puts "Hello Lambda"}