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

My Objection to Array#sum

github.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: My Objection to Array#sum

#51

Post by omouse »

jdminhbg wrote: post #41
omouse wrote: post #39

Earlier quoted context omitted.

Or you can have a sum method that accepts a block/lambda/anonymous function as an argument. This is done in Smalltalk with detectSum. people detectSum: [ :person | person age ]. items detectSum: [ :item | item price ].

In Ruby, this would be: class Array def detectSum(&block) self.map(&block).sum end end >> [1, 2, 3].detectSum {|i| i**2} => 14 Most Ruby people though would just call #map and #sum in succession on an ad hoc basis.

Ew, how inefficient. Here is the Smalltalk code:

    detectSum: aBlock
        "Evaluate aBlock with each of the receiver's elements as the argument. 
        Return the sum of the answers."
        | sum |
        sum := 0.
        self do: [:each | 
            sum := (aBlock value: each) + sum].  
        ^ sum
Anyway, my point still stands. Better to accept a block than to use a sum method that assumes the Array consists of numbers

Re: My Objection to Array#sum

#52

Post by scott_s »

calambrac wrote: post #50
scott_s wrote: post #49

Earlier quoted context omitted.

I think my interpretation is the more common one: http://en.wikipedia.org/wiki/Color_of_the_bikeshed http://catb.org/jargon/html/B/bikeshedding.html http://www.urbandictionary.com/define.php?term=bikeshedding All of these definitions require the issue to be of marginal benefit to the overall problem. The observation that people feel the need to contribute their opinion on matters they feel they know about is why bike…

You said "When I use the term...", a little phrase implying personal subjective interpretation, and that's was what I was responding to when I said "you can't just make up your definition", but okay, scratch that part. The more important point was that you can't call someone wrong when they're using the actual, original definition correctly, which I was (the link I included was how the term entered the geek lexicon).

I said that because, at that point, I realized we had a difference of definition, and I didn't know which one was more common. Having looked at it, I think what I say is the accepted definition - regardless of the origin.

But. All of this is a digression. The entire reason I said I don't think this is bikeshedding is because I think there's value in discussing why join is a member of strings and not sequences in Python. Understanding this point helps in understanding Python's design.

Re: My Objection to Array#sum

#53

Post by omouse »

raganwald wrote: post #8
wvenable wrote: post #7

I'm not a Ruby programmer so I have a simple question: Is it common to request whether an object implements a particular method before you make any sort of call? That seems considerably more fussy than strong typing of interfaces or even the type-hinting of interfaces that PHP has. I can't help thinking a cleaner solution is the more traditional way: Create a subclass called NumberArray that can only hold numbers and…

> Create a subclass called NumberArray that can only hold numbers and has specific methods for operating on them. I can't see anything wrong with this for some cases. Another way to get there would be to define a NumericCollection module that can be used to extend any Array.

How about create a method called detectSum that accepts a block as an argument. The block will return the specific field to use when summing.

This lets you skip subclassing.

Re: My Objection to Array#sum

#54

Post by nostrademons »

scott_s wrote: post #52
calambrac wrote: post #50

Earlier quoted context omitted.

You said "When I use the term...", a little phrase implying personal subjective interpretation, and that's was what I was responding to when I said "you can't just make up your definition", but okay, scratch that part. The more important point was that you can't call someone wrong when they're using the actual, original definition correctly, which I was (the link I included was how the term entered the geek lexicon).

I said that because, at that point, I realized we had a difference of definition, and I didn't know which one was more common. Having looked at it, I think what I say is the accepted definition - regardless of the origin. But. All of this is a digression. The entire reason I said I don't think this is bikeshedding is because I think there's value in discussing why join is a member of strings and not sequences in Pyth…

I find it really amusing that this has degenerated into a debate over the meaning of bikeshedding. Talk about bikeshedding!

Re: My Objection to Array#sum

#55

Post by calambrac »

nostrademons wrote: post #54
scott_s wrote: post #52

Earlier quoted context omitted.

I said that because, at that point, I realized we had a difference of definition, and I didn't know which one was more common. Having looked at it, I think what I say is the accepted definition - regardless of the origin. But. All of this is a digression. The entire reason I said I don't think this is bikeshedding is because I think there's value in discussing why join is a member of strings and not sequences in Pyth…

I find it really amusing that this has degenerated into a debate over the meaning of bikeshedding. Talk about bikeshedding!

A part of me wants to keep it going just for the irony value.

Re: My Objection to Array#sum

#56

Post by scott_s »

nostrademons wrote: post #54
scott_s wrote: post #52

Earlier quoted context omitted.

I said that because, at that point, I realized we had a difference of definition, and I didn't know which one was more common. Having looked at it, I think what I say is the accepted definition - regardless of the origin. But. All of this is a digression. The entire reason I said I don't think this is bikeshedding is because I think there's value in discussing why join is a member of strings and not sequences in Pyth…

I find it really amusing that this has degenerated into a debate over the meaning of bikeshedding. Talk about bikeshedding!

I recognized the irony, but well, bikeshedding. Can't resist.

Re: My Objection to Array#sum

#57

Post by nostrademons »

lacker wrote: post #35
nostrademons wrote: post #2

Python does this - sum/any/all are standalone functions, and join() is a member of the string class instead of the array class. Python also gets a lot of flack for it, as it seems like every month you can see someone complaining about why you use `"\n".join(lines)` to join an array instead of `lines.join("\n")`. People can't seem to wrap their head around it. Personally, I think the big mistake is to think objects sh…

"\n".join(lines) is confusing because you expect the complicated thing to be the object, and the simple thing to be the argument. The confusion is very basic. It would be cool but probably perlishly unadvisable if join,sum,any,all were just implemented as "\n".join(lines) -> lines.join("\n") sum(alist) -> alist.join(+) any(alist) -> alist.join(or) all(alist) -> alist.join(and)

That's what Haskell does. Your universal joiner is called "fold", sometimes pronounced "reduce" (Scheme/Python) or "inject" (Smalltalk/Ruby). From the Haskell prelude:

    sum = foldl (+) 0
    product = foldl (*) 1
    and = foldl (&&) True
    or  = foldl (||) False
    any p = or . map p
    all p = and . map p
    concat = foldl (++) []
    unlines = concat . map (++ "\n")
Google calls it "reduce" as well - this is what MapReduce is based upon.

(BTW, bad search query: [haskell unlines] gives me the Haskell prelude definition as the last result on the first page, even though that's the authoritative source. It gives me the Zvon and Informatik mirrors as #1 and #2, and then lots of useless discussion. Couldn't there be a way to boost "authoritative" sources up the rankings?)

Re: My Objection to Array#sum

#58

Post by raganwald »

cbeust wrote: post #42
ken wrote: post #26

Earlier quoted context omitted.

Reminds me of Kent Pitman's article about, among other things, why there's no generic deep-copy in Lisp: http://www.nhplace.com/kent/PS/EQUAL.html His answer is similar: just because you know the structure of something doesn't mean you know anything about its semantics. Because of this, I'm tending to believe that adding more strong-typing to languages is a losing battle, though I admit this raises more questions tha…

> Because of this, I'm tending to believe that > adding more strong-typing to languages is a > losing battle, I see this at the opposite. Just because an object says that it responds to a method doesn't guarantee that invoking said method will succeed. I'm not sure why the original poster is so surprised by this finding. Since this observation is valid in both statically and dynamically typed languages, I prefer a st…

A question and answer that might be relevant: http://www.reddit.com/r/ruby/comments/8ba5g/my_objection_to_...

Re: My Objection to Array#sum

#59

Post by DannoHung »

nostrademons wrote: post #2

Python does this - sum/any/all are standalone functions, and join() is a member of the string class instead of the array class. Python also gets a lot of flack for it, as it seems like every month you can see someone complaining about why you use `"\n".join(lines)` to join an array instead of `lines.join("\n")`. People can't seem to wrap their head around it. Personally, I think the big mistake is to think objects sh…

This is one of the reasons that I think newbs fuck up OO design so often; the way it's sold and the way that it can be used effectively are almost entirely divergent.

Re: My Objection to Array#sum

#60

Post by tetha »

zupatol wrote: post #20
jerf wrote: post #10

Earlier quoted context omitted.

The thing is, they aren't methods. They really aren't. They don't operate on an object using the object's local data. They are generic functions that use certain defined interfaces that many objects define. "list.join(str)" and "str.join(list)" are not the same . The list.join syntax only works for lists, but str.join takes any sequence , which is anything that implements the sequence protocol, including lists, dicts…

Well join should be on sequence instead of list then. To me it seems unnatural to see join on string because string feels more 'basic' than a sequence, so I would expect the sequence to know about strings rather than the opposite. But the argument against join on string is not as strong as the argument against sum on array.

I think, the join-akwardness in python mostly is a single-dispatch issue. Both variants, glue.join(sequence) and sequence.get_joined_by(glue) make some sort of sense, however, neither strikes all readers as the one obvious thing that obviously is right. (Compare similar single dispatch issues like: Will the employee have a add_to_department or will the department have a get_new_employee?) Thus, I think, the cleanest solution would be a generic method join(glue, string) so you just call join('\n', lines). This removes the question if the glue is more responsible in the join process or if the sequence is more important in the join process, because both are equally important.
Post reply on HN