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

41–50 of 65 posts

Re: My Objection to Array#sum

#41

Post by jdminhbg »

omouse wrote: post #39
evanmoran wrote: post #16

The method should be: array .sum The article is correct .sum shouldn't be on an array, but sum shouldn't be global either. This is why generics exist.

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.

Re: My Objection to Array#sum

#42

Post by cbeust »

ken wrote: post #26
raganwald wrote: post #5

Earlier quoted context omitted.

[1, [2, 3]].respond_to?(:sum) => false I elided a discussion about this case from the post. For some arrays, a recursive sum is semantically valid. For other arrays a recursive sum is not semantically valid, and it is not a simple case of knowing whether all of the leaf elements respond to :+. So again, trying to implement this in the Array class doesn't work because containers are implementation rather than interfac…

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 statically typed one since at least, I don't need to verify that the object does respond to that method before calling it.

Re: My Objection to Array#sum

#43

Post by nostrademons »

lacker wrote: post #36
nostrademons wrote: post #30

Earlier quoted context omitted.

That was my point when I started the thread. The Python decision is objectively justified for technical reasons. Yet a large number of people viscerally feel it's wrong . I blame human irrationality - but then, programming languages are meant for humans, so shouldn't they accommodate our irrationality? Otherwise, you get something like Haskell. ;-) BTW, there are other cases where Python has gone the other way. Multi…

"if (NULL == foo)" and "'\n'.join(lines)" both feel wrong because you are putting the most complicated object last. The most complicated thing should go first so you can sooner figure out what the heck this line of code is talking about. I would support making the C compiler just disallow "if (x = y)".

OTOH, in languages that support first-class functions, it's pretty common to put the functional argument last because then it can wrap to another line without leaving dangling parameters:

    $.each(my_array, function(val) {
      // Do something
      // Do something else
    });
That's putting the most complicated object last, and feels much more natural than:

    $.each(function(val) {
      // Do something
      // Do something else
    }, my_array);
I suspect it's more that English has trained us to read "noun verb object" sentences. In an if statement, `foo` feels like the subject, and then "== NULL" is the predicate. In an array map, the array is the subject, and the function is the predicate. In the Python join example, the array feels like the subject, "join" is the verb, and "," is the object, which is what makes it seem so awkward. Ruby's array.sum feels more natural because the array is the subject and sum is an intransitive verb.

Re: My Objection to Array#sum

#44

Post by jerf »

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 anticipated this objection if you go back and re-read my post, but I'll blow out the point a bit more here: In Java terms, "sequence" is an interface.

You can't put join there. Because then you have to put add, any, none, all, reduce, filter, and so on and so forth for at least another ten or twenty base methods (ignoring everything else that applies just to the sequence protocol written by users), which every single implementation would then have to provide. No matter how abstractly beautiful it may be that this implements object-orientation dogma, in practice it's an idea too stupid to even begin to consider.

Re: My Objection to Array#sum

#45

Post by calambrac »

scott_s wrote: post #37
calambrac wrote: post #34

Earlier quoted context omitted.

That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. How does that not fit this situation? Because there's actually a good technical reason to do it the way it's currently done? Wouldn't that imply that there should be even less discussion of it?

No, because the discussion should be explaining that good technical reason. Which is what happened. Bike-shedding is when the arguments have relatively the same merit, and the choice makes little difference in the end. I don't think either applies. An example of bike-shedding in this context would be renaming join to fuse .

Bike-shedding is when someone feels the need to interject their opinion simply because the topic is something they feel they understand, regardless of whether that interjection actually contributes anything.

Bitching that '\n'.join(alist) should be alist.join('\n') is a favorite pastime of people who want to demonstrate that they've heard of OO programming. It's a perfect example of bike-shedding.

Re: My Objection to Array#sum

#46

Post by scott_s »

calambrac wrote: post #45
scott_s wrote: post #37

Earlier quoted context omitted.

No, because the discussion should be explaining that good technical reason. Which is what happened. Bike-shedding is when the arguments have relatively the same merit, and the choice makes little difference in the end. I don't think either applies. An example of bike-shedding in this context would be renaming join to fuse .

Bike-shedding is when someone feels the need to interject their opinion simply because the topic is something they feel they understand, regardless of whether that interjection actually contributes anything. Bitching that '\n'.join(alist) should be alist.join('\n') is a favorite pastime of people who want to demonstrate that they've heard of OO programming. It's a perfect example of bike-shedding.

When I use the term, I assume both sides have marginal arguments - so the resulting discussion is a waste of time. I use it this way to remind a group that we're not discussing something important. But if one of the sides has merit, than it's important for the other side to understand that.

Re: My Objection to Array#sum

#47

Post by calambrac »

scott_s wrote: post #46
calambrac wrote: post #45

Earlier quoted context omitted.

Bike-shedding is when someone feels the need to interject their opinion simply because the topic is something they feel they understand, regardless of whether that interjection actually contributes anything. Bitching that '\n'.join(alist) should be alist.join('\n') is a favorite pastime of people who want to demonstrate that they've heard of OO programming. It's a perfect example of bike-shedding.

When I use the term, I assume both sides have marginal arguments - so the resulting discussion is a waste of time. I use it this way to remind a group that we're not discussing something important. But if one of the sides has merit, than it's important for the other side to understand that.

You can't just make up your own definition of a well-known term and then call people wrong when they use it correctly:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/u...

Re: My Objection to Array#sum

#48

Post by davidmathers »

randallsquared wrote: post #40
jeffesp wrote: post #23

Earlier quoted context omitted.

But the point isn't that String#titlecase can't do the right thing here. I assume there is an implementation of titlecase that will work with ß. But I can't think of an Array#sum that will work for [1, "two"]. Of course your :) might have meant you were being funny, then I just totally missed your point and explained something you already know.

Well, there is a tenuous connection in that it's not obvious what to do for casing of ß. I wrote some unicode stuff for CL once and figuring this out was a nightmare. In any case, if you have two data types that that don't make any other sense as an addition, you could always just convert them both to bitfields and sum that... now I'm just being silly. Don't mind me.

According to wikipedia "ß".upcase is "SS", except in the case of legal documents it remains "ß".

I checked irb and "ß".upcase is "ß", so I guess strings in ruby are of type "german legal document."

I also just learned that the reason there's no uppercase ß is that no words start with ß, so titlecase would never touch it.

Re: My Objection to Array#sum

#49

Post by scott_s »

calambrac wrote: post #47
scott_s wrote: post #46

Earlier quoted context omitted.

When I use the term, I assume both sides have marginal arguments - so the resulting discussion is a waste of time. I use it this way to remind a group that we're not discussing something important. But if one of the sides has merit, than it's important for the other side to understand that.

You can't just make up your own definition of a well-known term and then call people wrong when they use it correctly: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/u...

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 bikeshedding happens, but it's not bikeshedding itself.

Re: My Objection to Array#sum

#50

Post by calambrac »

scott_s wrote: post #49
calambrac wrote: post #47

Earlier quoted context omitted.

You can't just make up your own definition of a well-known term and then call people wrong when they use it correctly: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/u...

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

Post reply on HN