> I still maintain that the practice of naming things matters. > Let’s say that you had a function that took two numbers, added them together and returned the result. What would you call that function? You might call it add, or maybe sum.

const add = (a, b) => {
  return a + b;
};

add(2, 2);

But it's not (+ a b), it's (a, b) => a + b

It would be (fn [a b] (+ a b))

it is unnamed

+ is a name

and its so amazing we reduced it to two lines and one character.

But i take your point, if you had to pass that function in clojre you would write #(+ %1 %2)

but you could just pass (apply + <some collection) though apprently thats slower then (reduce + <some collection>) in some cases i cant remember.

+ is not the thing here

😄

the specific configuration of symbols is

But yeah, I have to say, I also got frustrated even with that, since 'add' and 'sum' are entirely different mathematical concepts and thus different functions

but the more frustrating part for me was that they identify a problem and then bring a worse solution on it 😄

> + is not the thing here @U0VQ4N5EE what do you mean?

I mean, the author is attempting to make an argument about fitting names and compares add with badger and tapioca and children. It's clearly a bad argument, since children is part of the React API. So I am not trying to defend it. That said, I think because + operator can be imagined as a function (or even have a language where it actually is a function that does exactly what they say the new function would do) doesn't mean that the author is talking about the same function. I can do this little bit of steelmanning their argument so that I can focus on the much bigger inaccuracies in the article.

And I wouldn't even care about it, if I wouldn't agree with the premise.