4 ms·

Correspondingly, some objects don't need names at all. sorted(pairs, key=lambda p: p[1]) Though in that case you might prefer using the operator module.

Correspondingly, some objects don't need names at all. sorted(pairs, key=lambda p: p[1]) Though in that case you might prefer using the operator module. sorted(pairs, key=operator.itemgetter(1)) The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously.

epidemian 11y ago
I didn't understand the comment on Ruby. Aren't those examples equivalent to?: pairs.sort_by(&:last) No need for defining a block and naming its parameter either.
- msellout 11y ago
  Yes, the lambda was equivalent. However, the second example offers that it might be better to be more verbose and avoid the use of anonymous functions. In general, I prefer to define a block and name parameters. As the slideshow illustrated, it's all about having good taste as an author. Knowing your audience and all that. In fact, that might have been a good point to add to his slides--that different coding styles are appropriate for different teams and projects.
  - spoiler 11y ago
    I'm not sure if I am misunderstanding your argument, but it seems like you're complaining about the fact you can't pass "functions" to methods that accept a block? You can! :D times_two = -> (x) {x*2} # Proc (lambda) times_two = Proc.new {|x| x*2} # Proc [7, 13, 19, 23, 31].map(&times_two) Also, if you want to call a method on the objects, you could do: [7, 13, 19, 23, 31].map(&:to_s) Which is a bizarre syntax, if you ask me (actually, not really if you know how I works in the background, but it still does look bizarre IHMO).
techiferous 11y ago
> The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously. Ruby gives you enough tools to write code clearly with good names if you want to. I think your complaint might be more about the particular style of Ruby a certain programmer wrote than the language itself.
- msellout 11y ago
  Correct, though I find that a language is more about the community and culture than the syntax itself.
agumonkey 11y ago
With the functional composition and currification, you can get point free programming (variable-less definitions). Some people don't like it, I personally find it appealing (I like APL and such). To quote prof. Dan Grossman, lambda p: p[1] === lambda p: p.__getitem__(1) which he calls an `unnecessary wrapping` of itemgetter(1). Similar to `return true if <bool> else false` which most people would find redundant.

epidemian 11y ago

I didn't understand the comment on Ruby. Aren't those examples equivalent to?: pairs.sort_by(&:last) No need for defining a block and naming its parameter either.

msellout 11y ago
Yes, the lambda was equivalent. However, the second example offers that it might be better to be more verbose and avoid the use of anonymous functions. In general, I prefer to define a block and name parameters. As the slideshow illustrated, it's all about having good taste as an author. Knowing your audience and all that. In fact, that might have been a good point to add to his slides--that different coding styles are appropriate for different teams and projects.
- spoiler 11y ago
  I'm not sure if I am misunderstanding your argument, but it seems like you're complaining about the fact you can't pass "functions" to methods that accept a block? You can! :D times_two = -> (x) {x*2} # Proc (lambda) times_two = Proc.new {|x| x*2} # Proc [7, 13, 19, 23, 31].map(&times_two) Also, if you want to call a method on the objects, you could do: [7, 13, 19, 23, 31].map(&:to_s) Which is a bizarre syntax, if you ask me (actually, not really if you know how I works in the background, but it still does look bizarre IHMO).

techiferous 11y ago

> The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously. Ruby gives you enough tools to write code clearly with good names if you want to. I think your complaint might be more about the particular style of Ruby a certain programmer wrote than the language itself.

msellout 11y ago
Correct, though I find that a language is more about the community and culture than the syntax itself.

agumonkey 11y ago

With the functional composition and currification, you can get point free programming (variable-less definitions). Some people don't like it, I personally find it appealing (I like APL and such). To quote prof. Dan Grossman, lambda p: p[1] === lambda p: p.__getitem__(1) which he calls an `unnecessary wrapping` of itemgetter(1). Similar to `return true if <bool> else false` which most people would find redundant.