This breaks the HN guidelines. If you're going to comment on a flamewar topic, you need to do better than this, even when someone else posted flamebait. Especially then.
(I'm not saying this is how to code, but I'm clarifying that you don't have to think about types to get the semantics/precision. You just want to think about types, can't help thinking about types, or something else, you tell me.)
Nope. No thinking in types required there.
> I am simply saying I want "plus" semantics to be identical to "+".
Yup. And that's exactly what the code that Drup pasted does.
> If "+" is capable enough to add the String "one" and "two" together
Yup. And that's exactly what the code that Drup pasted will do.
If you're telling me you don't have to think about types, then you and I are on the same page.
But it sounds like we're talking Haskell here, so afaik, somewhere Haskell is going to ask you to specify types so that it can complete its type-proof (i.e., compile.)
If you're saying No, Haskell doesn't need that, then I'm afraid you have a dynamic language on your hands.
Prelude> myfun x y = x ^ 2 + 2 * y * x - y ^ 2
Prelude> myfun 3 6
9 myfun x y = x ^ 2 % 2 * y * x - y ^ 2 55 % 102 would produce 55102
And if your answer is "I only need it to work on integers" then don't blame Haskell when I choose to specialise it to Int!
This is a silly example, of course, but the real world isn't short on creativity/silliness.
Suppose your types are Strings. And your plus operator can add "one" and "two", but fails adding roman numeral "I" and "II", my guess is you'll another type/ADT into your static typing called RomanNumeral so that your type proofer will check you at compile.
Meanwhile I will do exactly nothing because my product manager says he doesn't care if the user types in roman numerals.
Which means I will be building my next business feature while you're still doing type math.
Hmm, no. Why would you guess that? That makes no sense at all.
If you say "I choose just String. I.e., I overload String to contain both types of values. Then you are doing dynamic typing. So why in that case do you choose dynamic verification, but in other cases not? What is your criteria for when you choose static types versus dynamic types? Or do you just go by instinct?
There are genuine arguments between static and dynamic typing. The assumed annoyance of writing type signatures is only a valid point for specific type systems such as Java, and is certainly not a generic concern.
As usual: https://ro-che.info/ccc/17
When my product manager comes to me and says "I want a button here that when you press it, it add the user-entered value in input box 1 to the value in input box 2."
Okay, done:
(button :on-click #(+ (box1-value box2-value)))
Let's say that night I wake up sweating realizing that the user could type in the String "one" and "two".
Thankfully this before my push to production, so I go re-implement "+" to support English numbers.
Okay, now I go live. Well, now my user types in roman number "I". And a weird value is produced.
My product manager doesn't care about this class of users, so great I do nothing.
The point of this is that every step of the way, my choice to type check or not is a la carte. Not forced down my throat. Types are my tool, not my religion.
Clojure does have a few features that support dynamic dispatch, so there may be some games there to play as well.
The key point though is that "+" is really just my name for something that "adds two numbers together" -- that is strong enough semantics for me to express my function/business problem in terms of it. How I grow the supported range of that function...there are a number of ways I could go about that.
Also, the fact that types are dynamic doesn't mean you don't have to think about them, you still have either type errors (like in most lisps) or implicit coercions (like in JS, you probably don't want that).