Why blocks make Ruby methods slower

Re:Why blocks make Ruby methods slower by zem on Friday February 27, 2015 @04:32PM (#9121494)

yielding in a method without an explicit block parameter is actually my favourite design decision in all of ruby. it basically means every method gets a "free" optional block passable to it at call time, which in turn means that the language highly encourages (syntactically) code designs where a method implements some pattern and then yields to the calling code to fill in the details. compare ruby's "File#open" with common lisp's "with-open-file" - it was just the natural thing to do in ruby, versus having to implement something specifically for the open-file case in lisp.

[ Parent | on HN ]

Re:Why blocks make Ruby methods slower by rat87 on Saturday February 28, 2015 @06:22AM (#9123418)

I'm a guy who hasn't written that much ruby, I'm mostly writing python these days but I understand a lot of the concepts have written a bit of ruby and wish that some python things could be more like ruby.

Also I'm a guy who took a Smalltalk class taught by a passionate teacher back when I was getting my degree.

Smalltalk is one of the main parents of ruby. It's less practical then ruby in many ways but its more pure/simpler.

To me ruby's blocks/yield is one of the ugliest of parts of ruby. In Smalltalk just about everything is objects and messages. In Smalltalk Blocks are just special syntax for BlockClosure objects that you evaluate by sending the 'value' method on them and they don't have to be passed at the end, you can pass multiple blocks(if you want ideas of why you might want to do this see some of the c# linq overloads: https://msdn.microsoft.com/en-us/library/system.collections.... (or some thread/future like thing with a run action and an exception callback) although I admit many of them can be done with an extra map function.

Ruby Blocks aren't objects, yield is not a method, it's harder to assign/store closure to variables and pass them around.

I may be wrong but I was under the impression that blocks are the way they are because they are a speed hack, the original ruby being a simple interpreter and blocks allowed the common pattern of defining and passing a closure to the method calling the closure without overhead of allocating/initializing/gc a block closure object.

Other objections ruby doesn't seem to be a language that the number of arguments in the function declaration doesn't bear resemblance to the number of arguments you can pass ala javascript I don't see why blocks should be special, I don't want to glance at the body of the function to see if it expects a block or not.

Also if you want to overload on block_given? you can use a named/default argument at the end defaulting to nil.

[ Parent | on HN ]

Re:Why blocks make Ruby methods slower by masklinn on Friday February 27, 2015 @04:40PM (#9121531)

> it was just the natural thing to do in ruby, versus having to implement something specifically for the open-file case in lisp.

Uh what?

1. File#open is a special implementation, the canonical opening of a file is File#new

2. with-open-file is just a wrapper macro around unwind-protect/open/close

[ Parent | on HN ]

Re:Why blocks make Ruby methods slower by zem on Friday February 27, 2015 @05:40PM (#9121831)

i meant that it's a natural thing to do in ruby to implement patterns like open/yield/close or decorate/sort/undecorate as methods that yield to a block. with-open-file was probably a bad example, but from experience it does change the feel of the language when you have to explicitly specify a closure argument versus when you just expect that your method should allow for a block to be attached to the method call. i'm not saying that these things aren't possible in other languages, just that ruby's "free" block makes them a culturally default thing to do.

[ Parent | on HN ]