Hacker News Reader

Comment by msellout | Hacker News Reader

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.

View on HN

> 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.

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

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.

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.

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).

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.

Reply on news.ycombinator.com