blocks may map onto function passing in JavaScript at a high level, but they also do some things that are different in important ways.
Most notably, all code in Ruby blocks, including return, super, and yield, execute as if in the original context. This means that you can return from inside a block, and it will return from the original method the block was created in.
This is especially useful for custom iterators. In contrast, code inside a "built-in iterator" (for and while loops) in JavaScript is executed in the original scope, while code in a custom iterator (forEach, map, etc) is executed in a new scope.
This makes custom iterators in JavaScript clumsier to use than the same in Ruby. ES6 adds a way to implement custom iteration in JavaScript that hooks into the for construct, but the benefit of this feature is not limited to iterators.
Further, the new JavaScript iterators cannot be used to implement functionality like map and reduce (take a look at Ruby's Enumerable module for other examples), they essentially hardcode a forEach construct into the language, which is useful, but is not the same.
Edit: Just to be clear, the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language. Ruby's compliance with Tennet's correspondence principle (x ~ lambda x) creates many new opportunities for block use that may be missed by people familiar with function passing in a non-correspondence language like JavaScript.
"blocks may map onto function passing in JavaScript at a high level, but they also do some things that are different in important ways."
Didn't mean to imply they're in every way analogous anymore than I meant to imply that Haskell and Prolog are virtually identical. :)
Mostly I was looking for an example of a concept where other programmers seemed to think it was likely I'd've had limited exposure to and perhaps even trouble wrapping my head around (passing code) until I'd done it the same language where they'd come to understand/use it (Ruby).
"the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language."
If the keyword there is can, I don't disagree, both in the specific and general case. I know that even subtle differences between semantics can be important to both expressiveness and idiomatic constructs, I think it's credible that habit often results in trying to carry idioms over, and that a programmer who is only taught the syntax of Blam could be writing Blub in it for a while.
What I don't agree with some developers on is that this is a matter of constraint instead of trajectory -- that the languages a programmer already knows necessarily indicate the difficulty they'll have with adapting to differences and wielding them effectively.
To work with your example, it may be a decent guess that it might never occur to someone who hasn't worked in a purely TCP language to return or yield from inside a passed block, but I have my doubts that it'd be any kind of reliable predictor of how quickly they could wield the concept after explaining that it's kosher and showing an example where it's advantageous.
Most notably, all code in Ruby blocks, including return, super, and yield, execute as if in the original context. This means that you can return from inside a block, and it will return from the original method the block was created in.
This is especially useful for custom iterators. In contrast, code inside a "built-in iterator" (for and while loops) in JavaScript is executed in the original scope, while code in a custom iterator (forEach, map, etc) is executed in a new scope.
This makes custom iterators in JavaScript clumsier to use than the same in Ruby. ES6 adds a way to implement custom iteration in JavaScript that hooks into the for construct, but the benefit of this feature is not limited to iterators.
Further, the new JavaScript iterators cannot be used to implement functionality like map and reduce (take a look at Ruby's Enumerable module for other examples), they essentially hardcode a forEach construct into the language, which is useful, but is not the same.
Edit: Just to be clear, the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language. Ruby's compliance with Tennet's correspondence principle (x ~ lambda x) creates many new opportunities for block use that may be missed by people familiar with function passing in a non-correspondence language like JavaScript.