Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

(1..100).inject(&:+)

weblog.raganwald.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: (1..100).inject(&:+)

#51

Post by mrtron »

raganwald wrote: post #21
mrtron wrote: post #19

Earlier quoted context omitted.

I think that style of code is rather hard to read and really doesn't add any functionality that couldn't be done in a much more readable way in the same number of characters. So I am wondering why the author thinks its so fantastic. As for developing the language, I am usually for flexibility and allowing anything to be modified, however this type of change strikes me as not very useful.

"I am usually for flexibility and allowing anything to be modified, however this type of change strikes me as not very useful." That's entirely the point. If you are in favour of flexibility, you have to accept that people will use it for all sorts of things, not just ones you like.

I was talking about the fact that they are making that change on the core language. Providing the flexibility is different from putting it in the language.

Anyways, I don't really care, saying anything other than 'I love ruby' is shunned anyways.

Re: (1..100).inject(&:+)

#52

Post by raganwald »

mdemare wrote: post #50
raganwald wrote: post #34

Earlier quoted context omitted.

"After learning more languages, Ruby is starting to become pretty ugly to me, but somehow people keep managing to ignore all its faults, make little hacks like these, and be very productive with it." When I first saw it, I wondered why anyone would want this irregular little language when they could just use Smalltalk or Scheme. An early rant asked why I have to know the difference between a block and a Proc: why the…

For those who think the above is pretty tame and have been using it for years, we've got a series on our blog where we introduce and discuss a new method every day. http://blog.rubyenrails.nl/articles/category/daily_method Here we create a to_proc method for Hash: http://blog.rubyenrails.nl/articles/2008/02/26/a-hash-is-a-f...

I subscribe to the series and enjoy it. I hadn't seen Hash#to_proc, I look forward to considering the possibilities carefully...

Re: (1..100).inject(&:+)

#53

Post by gregwebs »

gregwebs wrote: post #33
spydez wrote: post #6

Anyone want to explain that code to someone who doesn't know Ruby?

The way to write this in ruby without extending the symbol class is (1..100).inject { |acc, n| acc + n } inject is a left fold or a reduce- it applies the function {acc + n} to each element in a list (or array) where acc is the result of the last function application. For such a simple function, all we need is the knowledge that we are adding, which is contained in the symbol '+', representing the addition method. So…

bloggified now:

http://thoughtfolder.com/2008-02-25-a-detailed-explanation-o...

Re: (1..100).inject(&:+)

#54

Post by raganwald »

mrtron wrote: post #51
raganwald wrote: post #21

Earlier quoted context omitted.

"I am usually for flexibility and allowing anything to be modified, however this type of change strikes me as not very useful." That's entirely the point. If you are in favour of flexibility, you have to accept that people will use it for all sorts of things, not just ones you like.

I was talking about the fact that they are making that change on the core language. Providing the flexibility is different from putting it in the language. Anyways, I don't really care, saying anything other than 'I love ruby' is shunned anyways.

"saying anything other than 'I love ruby' is shunned anyways."

Well... I welcome criticism of Ruby. Please say whatever you like in a comment right on the post.

I've never shied away from writing about the things in Ruby that irritate me. How else will we progress if we don't scratch when we have an itch?

Re: (1..100).inject(&:+)

#55

Post by dusklight »

tel wrote: post #46
dusklight wrote: post #44

So just out of curiosity .. what do you think is the most beautiful way to right the equivalent code in arc?

In this case, the "equivalent" code isn't a line that produces the same result, but is instead a line that illustrates the dynamic culture of the given language's evolution. For Arc, right now, practically every line is an equivalent.

Well okay let me elaborate on my question.

pg has stated that code brevity is one of the main design goals of arc. But what is pretty obvious is that code brevity is not the only consideration. It is desirable to be able to write very short code, but it should be readable as well. If you write very short code that is difficult for other people to read, that is bad enough. If you write very short code that ends up being difficult even for yourself to read -- then we have a problem.

The above ruby code snippet is a great example of code where reducing the length not only did not reduce readability, but actually increased it. I know some people have complained about it being obfuscated on this board. But to me, and I am sure to a number of other people on this board, it was easy to understand, intuitive even.

so .. in arc, what would be a similar way to create a list of numbers from 1 to 100, and to evaluate the sum of that list?

Re: (1..100).inject(&:+)

#56

Post by foonamefoo »

mattjones wrote: post #31

To some degree, using open classes is just how you write functions in Ruby. Say there exists a class called Errors in some Ruby library. It doesn't have an each() method, but I'd like it to. Nobody would complain if I wrote a function each_error() which took an Errors object as an argument. Reopening the Errors class and giving it an each() method is the way you do that in Ruby, and it's not really any more dangerous…

Then lets say you packaged that up as a library. Another guy did the same thing, but it worked a little different. Now random code breaks.

Re: (1..100).inject(&:+)

#57

Post by gregwebs »

gregwebs wrote: post #33
spydez wrote: post #6

Anyone want to explain that code to someone who doesn't know Ruby?

The way to write this in ruby without extending the symbol class is (1..100).inject { |acc, n| acc + n } inject is a left fold or a reduce- it applies the function {acc + n} to each element in a list (or array) where acc is the result of the last function application. For such a simple function, all we need is the knowledge that we are adding, which is contained in the symbol '+', representing the addition method. So…

actually, brackets represent a block. A block is converted to class Proc with '&'. If the object that '&' is used on is not a block, Ruby will first attempt to convert it into a Proc by calling to_proc

A Ruby block is always associated with a method, and cannot be captured in a variable without converting it back into a proc. This is done by 'removing' the '&'

  def return_block &block
    return block
  end

Re: (1..100).inject(&:+)

#58

Post by tel »

dusklight wrote: post #55
tel wrote: post #46

Earlier quoted context omitted.

In this case, the "equivalent" code isn't a line that produces the same result, but is instead a line that illustrates the dynamic culture of the given language's evolution. For Arc, right now, practically every line is an equivalent.

Well okay let me elaborate on my question. pg has stated that code brevity is one of the main design goals of arc. But what is pretty obvious is that code brevity is not the only consideration. It is desirable to be able to write very short code, but it should be readable as well. If you write very short code that is difficult for other people to read, that is bad enough. If you write very short code that ends up bei…

That question is somewhat interesting just a little off-topic in this thread.

In Arc, that line would be:

   (reduce + (range 1 100))
which is nice, but not much different from Scheme. Pretty readable.

Re: (1..100).inject(&:+)

#59

Post by Readmore »

gregwebs wrote: post #33
spydez wrote: post #6

Anyone want to explain that code to someone who doesn't know Ruby?

The way to write this in ruby without extending the symbol class is (1..100).inject { |acc, n| acc + n } inject is a left fold or a reduce- it applies the function {acc + n} to each element in a list (or array) where acc is the result of the last function application. For such a simple function, all we need is the knowledge that we are adding, which is contained in the symbol '+', representing the addition method. So…

The reason I choose to continue with Ruby instead of moving to a language like Scheme has a lot to do with the community. There is so much activity in the Ruby and Rails communities that you can almost always find help with what you're trying to do, a library to make something easier, and great blogs with lots of little tricks. I just haven't seen that same level of community with languages like Scheme.

I'm not saying that you should choose your language based solely on the size of it's community (otherwise I would be pulling my hair out with Java) but the advanced features of Ruby, the expressiveness, and the community together make it a great place to be as a programmer.

Re: (1..100).inject(&:+)

#60

Post by ken »

foonamefoo wrote: post #56
mattjones wrote: post #31

To some degree, using open classes is just how you write functions in Ruby. Say there exists a class called Errors in some Ruby library. It doesn't have an each() method, but I'd like it to. Nobody would complain if I wrote a function each_error() which took an Errors object as an argument. Reopening the Errors class and giving it an each() method is the way you do that in Ruby, and it's not really any more dangerous…

Then lets say you packaged that up as a library. Another guy did the same thing, but it worked a little different. Now random code breaks.

It turns out not to be a problem in practice. I could list the 20 things I hate most about Ruby and the 20 things I hate most about Rails, and this wouldn't make either list. I don't know that I've ever seen it happen.

And on the "technically, could it happen?" side, sure, it could. You can also write a Java library that, in weird cases, could screw up other Java libraries, but the Java folks (even as much as they love to try to keep you safe) don't care, either.

Besides, "each" is quite standard in Ruby. Defining it to mean something other than "call the proc with each element, in order" would be weirdbad, like a C++ programmer defining operator+ to mean subtraction. If you do something weirdbad like that, your library deserves to lose.

Post reply on HN