5 ms·

This will be fun. I’m glad we now have some performance improvements to some common methods. For those considering playing with Ruby, you should! One thing I’m

• dreix 8y ago
  Aren't they like arrow functions in JavaScript?
  • avandecreme 8y ago
    Just parameters that are functions, except that you can only have one per function. I still fail to see the advantage of blocks over being able to pass functions as arguments like in other languages.
    • kbp 8y ago
      One nice feature of blocks is that `return` will return from the enclosing function, rather than the block, so you can write: def find(x, l) l.each do |y| return y if y == x end end Where in Lisp you'd use (return-from find x) and in other languages you might pass in a continuation or use a special return value protocol. It's a nice solution for higher order functions that are supposed to feel more language-level. Also, you can pass functions as arguments like in other languages; lambdas behave like you would expect them to.
  • ufmace 8y ago
    A lot of this kind of stuff is more about language and standard lib culture than strict language features. Ex - Rust actually has exceptions, technically, in the form of Panics, and you can infact catch them. But the culture of Rust is strongly against using panics in that way. Basically never catch panics and only allow them to happen when you're okay with the whole program blowing up. Use Option and Result and check them if you care about your program not blowing up. Similarly, Ruby has nice blocks, and many other languages have similar closure support. But Ruby's support is so built-in from day 1 and heavily used in the standard library and the general culture of Ruby gems. Many of the methods in Enumerable take blocks, making it easy to chain a bunch of functional stuff together, even without any support gems and from the earliest days of Ruby.
  • PopeDotNinja 8y ago
    Blocks are essentially just anonymous functions.
• ch_123 8y ago
  Scala and Kotlin let you achieve something similar, without requiring a dedicated `yield` keyword, as well as not introducing yet another type of function into the language... Personally, I always found the number of different types of function in Ruby to be bewildering. Scala even allows multiple blocks to be passed in, used to good effect in the Cats effect `bracket` function, amongst others.
• mikekchar 8y ago
  I'm not so sure about the block thing. I mean I like having first class function-like objects, but you've got blocks and procs and both of these are different from bound and unbound methods. I would prefer that there was a single function type, personally. I wonder if I'm missing something, though. Is there an advantage to distinction between blocks and procs that ruby makes?
  • ravenstine 8y ago
    A block is a proc. ```ruby def foo &bar return bar end foo {} # => #<Proc:0x00007ff23783c4e0@(irb):16> ``` But I do agree that I don't quite understand the need for the distinction between procs and methods, or the need for unbound methods; I would think that methods could just be either bound to one object or another, as unbound methods are useless for the fact that they won't work at all unless they are bound.
    • int_19h 8y ago
      I think they rather meant the difference between procs and lambdas (e.g. wrt return).
• e12e 8y ago
  > what makes ruby unique and awesome, BLOCKS! Similar to blocks in Smalltalk and Self, surely? Still, having worked with ruby a fair bit the past year, it does deliver much of what Smalltalk does (not surprising, as ruby borrows heavily from smalltalk). https://www.gnu.org/software/smalltalk/manual/html_node/Invoking-code-blocks.html#Invoking-code-blocks https://www.gnu.org/software/smalltalk/manual/html_node/Invo...
  • deleted 8y ago
    [deleted]
• hamandcheese 8y ago
  I love ruby, but I kind of consider blocks an antifeature compared to, say, JavaScript arrow functions (where you can actually call return and not inanvertsntly break out of the entire enclosing function).