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

31–40 of 65 posts

Re: My Objection to Array#sum

#31

Post by calambrac »

nostrademons wrote: post #30
calambrac wrote: post #24

Earlier quoted context omitted.

This is such a non-issue. Really. The parent posted the reasoning behind the decision, that reasoning is sound. Your disagreement is purely aesthetic, there's simply no practical reason why the current way is wrong. Please just accept that this is how it is, and stop complaining about it. Please?

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…

I completely agreed with your original point. The fact that we went from your comment to people actually bitching about join made me really sad.

I shouldn't have said that the join argument was "purely aesthetic", I should have said that it was "purely aesthetic and trivial", because you're right, aesthetics are important, and (imo) are reason enough to disallow multiline lambdas. How do you cross the line from trivial to not? I don't know exactly, but I do know that swapping the position of the involved nouns and taking up the same number of characters for a good technical reason doesn't.

Re: My Objection to Array#sum

#32

Post by _pius »

scott_s wrote: post #28
_pius wrote: post #17

I agree with you. That being said, I suspect that this turns out to be a cultural debate more than anything else. Remember, Ruby is a freedom language. Ruby could eliminate many of the issues you raise by being strictly typed, but of course that'd defeat the purpose. The whole thing is a question of trust. Do you trust clients enough to give them the syntactic sugar of Array#sum even if their arrays may not all be st…

Disclaimer: I'm not a Rubyist. I think saying "Ruby is a freedom language" is a cop-out for foregoing good design. It excuses us from having to think through if the design makes sense, because we can always throw up our hands and say "Ruby is a freedom language." But I also think that's not an entirely true statement: Ruby doesn't let programmers jump to any random line of code. (I did find a neat module that impleme…

I think saying "Ruby is a freedom language" is a cop-out for foregoing good design.

I think some people could use that designation as a cop-out, but I don't think I'm doing that above. The point I was trying to make is that Ruby, by design, is not strictly typed and allows you to do things like metaprogramming easily. I'm certainly not trying to be an apologist for poor design.

Re: My Objection to Array#sum

#33

Post by scott_s »

calambrac wrote: post #29
philh wrote: post #25

Earlier quoted context omitted.

Python is intended to be aesthetically pleasing in some sense, so I don't think aesthetic objections to some of its features are unwarranted.

This isn't one of the 'some'. http://en.wikipedia.org/wiki/Color_of_the_bikeshed

I don't think this is bike-shedding. That applies when people argue over two functionally equivalent options, often to the detriment of more important issues.

In this case, their objection is that it violates their intuition, but the placement of join is a natural result of how Python's types are defined. Defining join on all sequences would have real (annoying) implications.

Re: My Objection to Array#sum

#34

Post by calambrac »

scott_s wrote: post #33
calambrac wrote: post #29

Earlier quoted context omitted.

This isn't one of the 'some'. http://en.wikipedia.org/wiki/Color_of_the_bikeshed

I don't think this is bike-shedding. That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. In this case, their objection is that it violates their intuition, but the placement of join is a natural result of how Python's types are defined. Defining join on all sequences would have real (annoying) implications.

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?

Re: My Objection to Array#sum

#35

Post by lacker »

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)

Re: My Objection to Array#sum

#36

Post by lacker »

nostrademons wrote: post #30
calambrac wrote: post #24

Earlier quoted context omitted.

This is such a non-issue. Really. The parent posted the reasoning behind the decision, that reasoning is sound. Your disagreement is purely aesthetic, there's simply no practical reason why the current way is wrong. Please just accept that this is how it is, and stop complaining about it. Please?

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

Re: My Objection to Array#sum

#37

Post by scott_s »

calambrac wrote: post #34
scott_s wrote: post #33

Earlier quoted context omitted.

I don't think this is bike-shedding. That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. In this case, their objection is that it violates their intuition, but the placement of join is a natural result of how Python's types are defined. Defining join on all sequences would have real (annoying) implications.

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.

Re: My Objection to Array#sum

#38

Post by tjstankus »

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.

I would tend toward that idea: a module that can be included. Injecting a sum method into the object's ghost class also maintains scope of responsibility, but feels a bit more magic. I'd opt for less magic. At first, anyway. :)

Re: My Objection to Array#sum

#39

Post by omouse »

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

Re: My Objection to Array#sum

#40

Post by randallsquared »

jeffesp wrote: post #23
randallsquared wrote: post #14

Earlier quoted context omitted.

But does String#titlecase do the right thing for ß? :)

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.
Post reply on HN