There are plenty of differences between JavaScript and Ruby, but I think one thing that hasn't necessarily been covered too often is the way these two languages treat blocks differently.
In Ruby, the most common kinds of blocks are those passed to various Array, Hash, and Enumerable methods,
like map and each. Like this use, on line 12:
Here's sample output when the coinflip is heads:
The important thing about these kinds of blocks is that these blocks, as in the block that I passed to the Enumerable#inject method,
are not formal: they are not in themselves
objects, they cannot be directly referenced, they cannot be passed as arguments; they're just syntax. But
Ruby has so much functionality for blocks: if you formalize a block by turning it into an instance of the Proc class,
or store it in variable form as a lambda, you
can certainly use it as an object. This isn't just Ruby—plenty, if not most, languages have block objects.
"1970 - Guy Steele and Gerald Sussman create Scheme. Their work leads to a series of "Lambda the Ultimate" papers culminating in "Lambda the Ultimate Kitchen Utensil." This paper becomes the basis for a long running, but ultimately unsuccessful run of late night infomercials. Lambdas are relegated to relative obscurity until Java makes them popular by not having them." ~ from "A Brief, Incomplete, and Mostly Wrong History of Programming Languages"
So in Ruby, we can store blocks as lambdas inside of variables, and call on them by invoking
the method call onto the variable, and passing it any arguments that it requires. Observe:
What's happening here? We created a lambda object by simply using the keyword lambda, assigned
that to a variable add, and specified the lambda block with the block {|x, y| x + y}.
Then, on line 13, we called it using add.call and passing it the two number arguments, which satisfy
the requirements for x & y in the lambda block, and x + y (num1 + num2) is produced. Is the output identical?
Ok, cool, it totally is identical! Does JavaScript have a similar functionality? Why yes, yes it does:
Other than no sleep functionality, and struggling to generate a random number to take a random
sample from the coins array, the difference between this script and the Ruby one is the way that function
in add is embedded into the variable. Very cool! Looks a lot like a lambdas!
Here's the difference. In Ruby, lambdas are rarely used. It is much more common to pass blocks implicitly or explicitly to a method when calling it to run. When we explicitly pass a block to a method, we have to use an ampersand (&) symbol to denote to the method that that argument is a block. Alternatively, we can implicitly pass a block to a method, and don't need to either declare it as an argument when it is passed, nor embed the block in a variable. Here's the same example with an implicit block: notice how it is being called to run below the method definition, and how it is being called upon:
Does JavaScript have something like this? Well, it definitely has explicit blocks, and it calls them callback
functions. In fact, the JavaScript example used above includes a nameless callback function inside of the add variable. No, it doesn't look
like you can implicitly pass a block the way we're doing with the Ruby example above, but JavaScript's functions are so easily embeddable as
callback functions that there's no reason to pine for Ruby's approach.
So here's the takeaway. Ruby thinks pretty seriously about blocks, Procs, and lambdas. It formalizes Procs and lambdas with special rules
like what happens when you use the keyword return inside of one. It allows you to call or run the block and pass it things as well
as making a distinction between that and creating your own external method, running that by passing it an argument, and capturing the result. But JavaScript
isn't as demanding of carefulness: it's common practice to create callbacks, embed functions as values for variables, call on them and pass things
to them inside and outside of functions, and more. It's a wonderful, functional free-for-all. Both approaches—and both cultures, really—have their
own history and purpose, and both work great even though they are different.