4 ms·

let plus x y = x + y This is a statically typed function. If you are going to talk about static typing, learn about type inference and avoid making yourself ri

by Drup 9y ago

let plus x y = x + y This is a statically typed function. If you are going to talk about static typing, learn about type inference and avoid making yourself ridiculous. 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).

wellpast 9y ago
You're missing my point. In your example, somewhere you have to express your types. So just move my example over to that point in your code.
- Drup 9y ago
  Sure. Just like somewhere, you have to define the semantics of + on the various primitive in your lisp-based system. Oh, surprise, you do that with a typecase/runtime type check. 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 https://ro-che.info/ccc/17
  - wellpast 9y ago
    It's not just about "writing type signatures". It's about expressing the semantics of your solution to some business problem. 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))) All I had to know was that the function contract/semantics of "+" is that it adds two numbers. Now I am done. 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.
    - deleted 9y ago
      [deleted]
    - tome 9y ago
      You re-implement the primitive operation "+" to support adding strings that name English numbers? Is that actually possible in Clojure, or did you mean something else?
      - wellpast 9y ago
        I guess it doesn't really matter. In Clojure "+" is namespaced, so if I need to have it support a broader range of inputs, I could just switch my usage to "new-+", or I could call my new version "+" and import it from its namespace. 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.
wellpast 9y ago
Another way to think about this. When you and I are defining "plus" in this way, you may be thinking types (and how they are inferred and everything). I am simply saying I want "plus" semantics to be identical to "+"... If "+" is capable enough to add the String "one" and "two" together, I'll take it. If one of my users types in a roman numeral "I" and "+" yields wrong behavior (throws, or produces bad value), then I have to think about types. But maybe that never happens... (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.)
- tome 9y ago
  > When you and I are defining "plus" in this way, you may be thinking types 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.
  - wellpast 9y ago
    I was simply responding to Drup's "the fact that types are dynamic doesn't mean you don't have to think about them"... 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.
    - tome 9y ago
      Where did I specify types here? Prelude> myfun x y = x ^ 2 + 2 * y * x - y ^ 2 Prelude> myfun 3 6 9
      - wellpast 9y ago
wellpast 9y ago
And more: 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.
- tome 9y ago
  > my guess is you'll another type/ADT into your static typing called RomanNumeral so that your type proofer will check you at compile. Hmm, no. Why would you guess that? That makes no sense at all.
  - wellpast 9y ago
    Well then what is your criteria for having a String that can represent both English spellings of numbers and a String that represents roman numerals. 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?
dang 9y ago
> avoid making yourself ridiculous 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

by Drup 9y ago

wellpast 9y ago

You're missing my point. In your example, somewhere you have to express your types. So just move my example over to that point in your code.

Drup 9y ago
Sure. Just like somewhere, you have to define the semantics of + on the various primitive in your lisp-based system. Oh, surprise, you do that with a typecase/runtime type check. 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 https://ro-che.info/ccc/17
- wellpast 9y ago
  It's not just about "writing type signatures". It's about expressing the semantics of your solution to some business problem. 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))) All I had to know was that the function contract/semantics of "+" is that it adds two numbers. Now I am done. 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.
  - deleted 9y ago
    [deleted]
  - tome 9y ago
    You re-implement the primitive operation "+" to support adding strings that name English numbers? Is that actually possible in Clojure, or did you mean something else?
    - wellpast 9y ago
      I guess it doesn't really matter. In Clojure "+" is namespaced, so if I need to have it support a broader range of inputs, I could just switch my usage to "new-+", or I could call my new version "+" and import it from its namespace. 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.

wellpast 9y ago

Another way to think about this. When you and I are defining "plus" in this way, you may be thinking types (and how they are inferred and everything). I am simply saying I want "plus" semantics to be identical to "+"... If "+" is capable enough to add the String "one" and "two" together, I'll take it. If one of my users types in a roman numeral "I" and "+" yields wrong behavior (throws, or produces bad value), then I have to think about types. But maybe that never happens... (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.)

tome 9y ago
> When you and I are defining "plus" in this way, you may be thinking types 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.
- wellpast 9y ago
  I was simply responding to Drup's "the fact that types are dynamic doesn't mean you don't have to think about them"... 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.
  - tome 9y ago
    Where did I specify types here? Prelude> myfun x y = x ^ 2 + 2 * y * x - y ^ 2 Prelude> myfun 3 6 9
    - wellpast 9y ago

wellpast 9y ago

And more: 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.

tome 9y ago
> my guess is you'll another type/ADT into your static typing called RomanNumeral so that your type proofer will check you at compile. Hmm, no. Why would you guess that? That makes no sense at all.
- wellpast 9y ago
  Well then what is your criteria for having a String that can represent both English spellings of numbers and a String that represents roman numerals. 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?

dang 9y ago

> avoid making yourself ridiculous 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html