3 ms·

I think never have I written generic code for summing up numbers AND concatenating strings. Even the Haskell people would agree I think. So the design problem i

I think never have I written generic code for summing up numbers AND concatenating strings. Even the Haskell people would agree I think. So the design problem is in overloading `+` for string and list concatenation in Python in the first place. But I guess in terms of strings let's take a moment and remember the one truly good design decision that Python devs made about strings (which isn't usual for an imperative language). Strings are immutable by default.

noelwelsh 6y ago
It's very common in data processing to sum up stuff (e.g. unique visitors, total visitors, total revenue, etc.) To handle this you typically want to write a generic library that makes summing up stuff easy. I can't think of an example where you'd want to add up strings (more likely lists of strings) but it is definitely the case for other data structures (sets, vectors, lists, numbers, etc.)
- kragen 6y ago
  Python sum() can handle summing up other data structures, although, as with foldl, you may have to give it an initial accumulator argument: >>> import numpy as np >>> xs = np.arange(9).reshape((3,3)) >>> xs array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) >>> sum(xs) # builtin sum, not numpy sum array([ 9, 12, 15]) >>> sum([[3, 11], [5]], []) [3, 11, 5] >>> sum([(3, 11), (5,)], ()) (3, 11, 5) However, that doesn't work for strings; there's a special-case check for that.
Avi-D-coder 6y ago
We don't just write generics over types of strings ([Char], Text, etc..) we write over Semigroups and Monoids. Concatenation with <> is standard practice.
lmm 6y ago
> I think never have I written generic code for summing up numbers AND concatenating strings. Even the Haskell people would agree I think. Erm, Haskell people write code that can do this all the time - you write stuff in terms of generic monoid and then it just does. I can even think of a concrete case where I used those two examples: I had essentially a report that looped over a bunch of rows and accumulated something as a secondary effect, and in one client's case that was a string explaining what had happened, and in another client's case that was a count of how many things had been processed.
- still_grokking 6y ago
  So you've written (of course type safe) generic code that was in principle able to achieve the same effect as described in https://stackoverflow.com/questions/9032856/what-is-the-explanation-for-these-bizarre-javascript-behaviours-mentioned-in-the https://stackoverflow.com/questions/9032856/what-is-the-expl... ? ;-) Batman!
  - rowanG077 6y ago
    No. He was talking about monoids. The content in the link you are talking about aren't monoids.
    - still_grokking 6y ago
      Do the implementation details matter if you could achieve the same result?
      - rowanG077 6y ago
        It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands. It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants.
        still_grokking 6y ago
        >It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands. I would argue that that's not true. JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result. >It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants. That's backwards to my point. I tried to point out that having generic code which can operate on (almost) arbitrary data structures mixing for example natural numbers or lists of arbitrary things will lead in the end to the same puzzling results as the "classical JS-Batman" example. Don't get me wrong, generics are a great tool! But imho it's easy to "overstretch" their usage until a point where things become "so generic" that your functions can operate on "almost everything" but the results become as surprising as the alleged "JS insanities". Something like the Monoid abstraction is incredibly powerful (most languages can't express such an abstraction in a sensible way even). Using such a powerful tool to abstract over some very concrete and banal things (that would be handled better separately as they're "not the same", no matter there may be a deep mathematical connection) is not a good architecture imo. If your code handling "concrete things" is written in a very generic and abstract way you won't have any "normal" tools left on your belt in case you would need to abstract over that stuff you've just written (at this point you could enter type-level programming or something that will achieve something similar but you will than end up with laughable complex code to handle in the end banal business logic). https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power

noelwelsh 6y ago

It's very common in data processing to sum up stuff (e.g. unique visitors, total visitors, total revenue, etc.) To handle this you typically want to write a generic library that makes summing up stuff easy. I can't think of an example where you'd want to add up strings (more likely lists of strings) but it is definitely the case for other data structures (sets, vectors, lists, numbers, etc.)

kragen 6y ago
Python sum() can handle summing up other data structures, although, as with foldl, you may have to give it an initial accumulator argument: >>> import numpy as np >>> xs = np.arange(9).reshape((3,3)) >>> xs array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) >>> sum(xs) # builtin sum, not numpy sum array([ 9, 12, 15]) >>> sum([[3, 11], [5]], []) [3, 11, 5] >>> sum([(3, 11), (5,)], ()) (3, 11, 5) However, that doesn't work for strings; there's a special-case check for that.

Avi-D-coder 6y ago

We don't just write generics over types of strings ([Char], Text, etc..) we write over Semigroups and Monoids. Concatenation with <> is standard practice.

lmm 6y ago

> I think never have I written generic code for summing up numbers AND concatenating strings. Even the Haskell people would agree I think. Erm, Haskell people write code that can do this all the time - you write stuff in terms of generic monoid and then it just does. I can even think of a concrete case where I used those two examples: I had essentially a report that looped over a bunch of rows and accumulated something as a secondary effect, and in one client's case that was a string explaining what had happened, and in another client's case that was a count of how many things had been processed.

still_grokking 6y ago
So you've written (of course type safe) generic code that was in principle able to achieve the same effect as described in https://stackoverflow.com/questions/9032856/what-is-the-explanation-for-these-bizarre-javascript-behaviours-mentioned-in-the https://stackoverflow.com/questions/9032856/what-is-the-expl... ? ;-) Batman!
- rowanG077 6y ago
  No. He was talking about monoids. The content in the link you are talking about aren't monoids.
  - still_grokking 6y ago
    Do the implementation details matter if you could achieve the same result?
    - rowanG077 6y ago
      It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands. It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants.
      - still_grokking 6y ago
        >It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands. I would argue that that's not true. JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result. >It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants. That's backwards to my point. I tried to point out that having generic code which can operate on (almost) arbitrary data structures mixing for example natural numbers or lists of arbitrary things will lead in the end to the same puzzling results as the "classical JS-Batman" example. Don't get me wrong, generics are a great tool! But imho it's easy to "overstretch" their usage until a point where things become "so generic" that your functions can operate on "almost everything" but the results become as surprising as the alleged "JS insanities". Something like the Monoid abstraction is incredibly powerful (most languages can't express such an abstraction in a sensible way even). Using such a powerful tool to abstract over some very concrete and banal things (that would be handled better separately as they're "not the same", no matter there may be a deep mathematical connection) is not a good architecture imo. If your code handling "concrete things" is written in a very generic and abstract way you won't have any "normal" tools left on your belt in case you would need to abstract over that stuff you've just written (at this point you could enter type-level programming or something that will achieve something similar but you will than end up with laughable complex code to handle in the end banal business logic). https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power