5 ms·

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. Being dynamic doesn't preclude variables from being type checke

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. Being dynamic doesn't preclude variables from being type checked by the runtime. Reading this just sounds like "javascript has no built in support for type checking, so lets pretend it's not possible" All the time people spent making weird unreadable 'fat functions', but you still can't define the types of arguments you want to receive?

sedeki 8y ago
I guess he means ”knows [at compile time]”
- qaq 8y ago
  if someone invented a typed superset of JS life could be so much easier Oh wait ...
  - stephenr 8y ago
    Typescript doesn’t actually do runtime checking though does it? So if I wrote a library in ts and someone called the built js directly it wouldn’t have any type checking would it?
    - qaq 8y ago
      When you are doing interop between languages a lot of things can go wrong. Rust is pretty much doing compile time checks too.
    - mattbierner 8y ago
      No it doesn't. This may not be a popular opinion for those coming from C or Java, but runtime type checks in JavaScript are usually an anti-pattern. If my function defines a contract that the caller violates by passing in null or undefined, then my function should raise an exception when it tries to access `undefined.xyz` or whatever. Otherwise, embrace the duck! If the function can work with what it was given, it should instead of trying to enforce some Java-esque type system at runtime using typeof or instanceof. But be pragmatic. If there is some critical area of your app that absolutely must never ever throw, typecheck away (although this is JS after all, so it still may throw if it damn well pleases).
      - stephenr 8y ago
        > If the function can work with what it was given, it should How do you know that it "can work" based purely on the name of the function? > But be pragmatic I am. I consider javascript a last-resort option, only really useful for adding minor enhancements client side. Beyond that, I don't use it.
        mattbierner 8y ago
        Documentation and/or a type checker. Jsdocs are both documentation for programmers and can be enforced using tooling like the closure compiler or typescript JavaScript is no different from most other dynamic languages this way
        stephenr 8y ago
        So, 'hope'. This is exactly why I can't take javascript seriously for anything besides basic UI enhancements to a web page.
        mattbierner 8y ago
        I’m sorry that I commented on this article. Knew it was a trap. I’ve been writing functional-style for a long time and just wanted to share a bit of what I’ve learned. Use whatever tools work for you, but also don’t disparage or dismiss other tools because they have different strengths and weaknesses than what you know or appreciate. There is no need for proselytizing; these are just tools after all! I like JavaScript and TypeScript because they have let me quickly build many great things and share them with people. I also subjectivity find writing in them to be enjoyable. I may always turn to a different language if it is more productive and enjoyable than js/ts for the task at hand.
arcticbull 8y ago
The runtime is unhelpful unless your tests include 100% code coverage.
- stephenr 8y ago
  Huh? If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.
  - arcticbull 8y ago
    Typechecking at the runtime level means that you have to write tests that traverse every single code path to make sure your code works the way you expect. You can just do this at compile time with static typing. Saves you a lot of boiler plate tests you don't need to write yourself to assert the same thing.
    - stephenr 8y ago
      In the context of JS 'compile time' refers to.. TS? My point was that if your TS project is used in a non-TS context (i.e. the compiled JS is called from regular JS code, not compiled TS code, you no longer have that compile step. I also think you've misunderstood what I mean. I'm talking about native language level support for typed function arguments at the javascript level, not relying on TS to provide that.
    - int_19h 8y ago
      This is where terminology fails us. I really wish the terms "static typing" and "dynamic typing" as presently used would be gone entirely. What you're saying is that explicit type annotations can be enforced at compile time. However, they can also be enforced at runtime, and they're no less safe for that - you just see the errors later, but any call that would be blocked by a static type checker can similarly be blocked by a dynamic checker. I think that's what OP refers to by "runtime checking", not writing explicit asserts.
      - 8y ago
int_19h 8y ago
> Being dynamic doesn't preclude variables from being type checked by the runtime. It kinda does, because in a dynamically typed (as colloquially defined - if you want to debate that definition, that's another discussion) language, variables don't have types - values do.
- stephenr 8y ago
  Ok, if you want to be pedantic about it, fine. Nothing precludes values from being type checked.
  - int_19h 8y ago
    Type checked against what, if a variable doesn't have a type? There are contexts in which two values are involves, where we can at least check that the types are matching (or reasonably compatible), like (a + b). JS is a massive failure in that regard, too, and there are dynamic languages that do it far better - e.g. in Python, ("1" + 2) is a runtime type error, not 3. But in the context of this thread, I feel that's not what we're talking about. We're really talking about contracts - and contracts require typed bindings (variables, function arguments etc), not just typed values. Which means that they do require static type annotations. As we've discussed in another subthread, those annotations might be checked dynamically - but they still have to be declared statically by the coder, which makes the type system effectively static from their perspective. To put it differently: if you require types to be declared explicitly, there's no reason to not check them statically. Dynamic checking of static types really only makes sense for gradual typing systems, where code with static type annotations might be called from some non-annotated code, and you want it to be possible without forcing static typing on the caller. At that point, yes, you can have a dynamic type check in the callee, which ensures that if code without type annotations doesn't actually get the types right, things fail fast at the static/dynamic typing boundary, instead of allowing it to propagate into the statically typed code (as is the case in e.g. TS today).
    - stephenr 8y ago
      > if you require types to be declared explicitly, there's no reason to not check them statically. I think some of this thread is suffering from confusing terms so, my entire point is this: There is no native way in javascript to say that the first argument of function foo must be an instance of class Bar (which in JS could be a string or an array or some custom object or even a DOM element - everything is an object and thus has a 'class'). The common response is "use typescript" which means you write the code with argument type declarations, and then compile to javascript. This (in theory) means any code you've written in the project in TS which calls our foo() function, will warn/error if the first argument isn't an instance of class Bar. But, and this is the problem: it's not enforced by javascript, it's "enforced" (for whatever definition of enforced typescript uses) by the TS compiler. So if I then use the compiled JS of function foo() and call it from native JS (i.e. not compiled by TS) - it won't tell me I have the wrong type. THAT is my issue.

sedeki 8y ago

I guess he means ”knows [at compile time]”

qaq 8y ago
if someone invented a typed superset of JS life could be so much easier Oh wait ...
- stephenr 8y ago
  Typescript doesn’t actually do runtime checking though does it? So if I wrote a library in ts and someone called the built js directly it wouldn’t have any type checking would it?
  - qaq 8y ago
    When you are doing interop between languages a lot of things can go wrong. Rust is pretty much doing compile time checks too.
  - mattbierner 8y ago
    No it doesn't. This may not be a popular opinion for those coming from C or Java, but runtime type checks in JavaScript are usually an anti-pattern. If my function defines a contract that the caller violates by passing in null or undefined, then my function should raise an exception when it tries to access `undefined.xyz` or whatever. Otherwise, embrace the duck! If the function can work with what it was given, it should instead of trying to enforce some Java-esque type system at runtime using typeof or instanceof. But be pragmatic. If there is some critical area of your app that absolutely must never ever throw, typecheck away (although this is JS after all, so it still may throw if it damn well pleases).
    - stephenr 8y ago
      > If the function can work with what it was given, it should How do you know that it "can work" based purely on the name of the function? > But be pragmatic I am. I consider javascript a last-resort option, only really useful for adding minor enhancements client side. Beyond that, I don't use it.
      - mattbierner 8y ago
        Documentation and/or a type checker. Jsdocs are both documentation for programmers and can be enforced using tooling like the closure compiler or typescript JavaScript is no different from most other dynamic languages this way
        stephenr 8y ago
        So, 'hope'. This is exactly why I can't take javascript seriously for anything besides basic UI enhancements to a web page.
        mattbierner 8y ago
        I’m sorry that I commented on this article. Knew it was a trap. I’ve been writing functional-style for a long time and just wanted to share a bit of what I’ve learned. Use whatever tools work for you, but also don’t disparage or dismiss other tools because they have different strengths and weaknesses than what you know or appreciate. There is no need for proselytizing; these are just tools after all! I like JavaScript and TypeScript because they have let me quickly build many great things and share them with people. I also subjectivity find writing in them to be enjoyable. I may always turn to a different language if it is more productive and enjoyable than js/ts for the task at hand.

arcticbull 8y ago

The runtime is unhelpful unless your tests include 100% code coverage.

stephenr 8y ago
Huh? If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.
- arcticbull 8y ago
  Typechecking at the runtime level means that you have to write tests that traverse every single code path to make sure your code works the way you expect. You can just do this at compile time with static typing. Saves you a lot of boiler plate tests you don't need to write yourself to assert the same thing.
  - stephenr 8y ago
    In the context of JS 'compile time' refers to.. TS? My point was that if your TS project is used in a non-TS context (i.e. the compiled JS is called from regular JS code, not compiled TS code, you no longer have that compile step. I also think you've misunderstood what I mean. I'm talking about native language level support for typed function arguments at the javascript level, not relying on TS to provide that.
  - int_19h 8y ago
    This is where terminology fails us. I really wish the terms "static typing" and "dynamic typing" as presently used would be gone entirely. What you're saying is that explicit type annotations can be enforced at compile time. However, they can also be enforced at runtime, and they're no less safe for that - you just see the errors later, but any call that would be blocked by a static type checker can similarly be blocked by a dynamic checker. I think that's what OP refers to by "runtime checking", not writing explicit asserts.
    - 8y ago

int_19h 8y ago

> Being dynamic doesn't preclude variables from being type checked by the runtime. It kinda does, because in a dynamically typed (as colloquially defined - if you want to debate that definition, that's another discussion) language, variables don't have types - values do.

stephenr 8y ago
Ok, if you want to be pedantic about it, fine. Nothing precludes values from being type checked.
- int_19h 8y ago
  Type checked against what, if a variable doesn't have a type? There are contexts in which two values are involves, where we can at least check that the types are matching (or reasonably compatible), like (a + b). JS is a massive failure in that regard, too, and there are dynamic languages that do it far better - e.g. in Python, ("1" + 2) is a runtime type error, not 3. But in the context of this thread, I feel that's not what we're talking about. We're really talking about contracts - and contracts require typed bindings (variables, function arguments etc), not just typed values. Which means that they do require static type annotations. As we've discussed in another subthread, those annotations might be checked dynamically - but they still have to be declared statically by the coder, which makes the type system effectively static from their perspective. To put it differently: if you require types to be declared explicitly, there's no reason to not check them statically. Dynamic checking of static types really only makes sense for gradual typing systems, where code with static type annotations might be called from some non-annotated code, and you want it to be possible without forcing static typing on the caller. At that point, yes, you can have a dynamic type check in the callee, which ensures that if code without type annotations doesn't actually get the types right, things fail fast at the static/dynamic typing boundary, instead of allowing it to propagate into the statically typed code (as is the case in e.g. TS today).
  - stephenr 8y ago
    > if you require types to be declared explicitly, there's no reason to not check them statically. I think some of this thread is suffering from confusing terms so, my entire point is this: There is no native way in javascript to say that the first argument of function foo must be an instance of class Bar (which in JS could be a string or an array or some custom object or even a DOM element - everything is an object and thus has a 'class'). The common response is "use typescript" which means you write the code with argument type declarations, and then compile to javascript. This (in theory) means any code you've written in the project in TS which calls our foo() function, will warn/error if the first argument isn't an instance of class Bar. But, and this is the problem: it's not enforced by javascript, it's "enforced" (for whatever definition of enforced typescript uses) by the TS compiler. So if I then use the compiled JS of function foo() and call it from native JS (i.e. not compiled by TS) - it won't tell me I have the wrong type. THAT is my issue.