4 ms·

JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of

by stiff 12y ago

JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of NaN many common coding mistakes end up producing mysterious errors pointing somewhere far away from the place in the code that actually produced the problem in the first place. Basically JavaScript continues propagating null/undefined/NaN in many situations where other languages, including other dynamic ones like Ruby and Python, raise an error much earlier. There are other issues as well, JavaScript doesn't check function arity on function calls (the arguments not supplied just get the "undefined" value), control structures do not introduce a new lexical scope etc.

jackweirdy 12y ago
Really? I find it happens as often as NullPointerExceptions. Viva la Maybe type
drderidder 12y ago
Yeah, that can be confusing. On the other hand, if you write unit / functional tests then testing for invalid inputs one of the first things you'll probably do. Your comment makes me think a fuzzer to test all those falsey values could be useful.
- stiff 12y ago
  A lot of JavaScript is UI code though, so unit tests might not be possible, and a suite of comprehensive functional tests with something like Selenium gets dog slow very fast, in my experience.
- nardi 12y ago
  In general, this argument is self-defeating: "I don't need a type checker because I write unit tests." Obviously that means you need a type checker, because then you don't have to write 70-90% of your unit tests. Unit tests require time and energy to produce, run, and maintain. A type-checking compiler can remove much of this burden from the developer.
ep103 12y ago
yeah, but all of these examples would just be fixed if your devs are required to write unit test coverage of their js
Touche 12y ago
I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.
- arjie 12y ago
  But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test. Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.
  - Touche 12y ago
    I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain? I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception. I get the benefit of optional type checking without a compile step in development like with Flow.
    - arjie 12y ago
      Well, I assumed you'd want to spot that error before it happens rather than when it does. The exception being thrown by the assert (at run-time) means that the user sees the failure. That's sub-optimal, right? So you'd ensure that there is testing of all code that calls this code in order to trigger the exception ahead of time if that occurs. Or am I misunderstanding? It just seems that the assert applies the constraint too late in the process. It doesn't ensure you have the right type once you've deployed. Instead it ensures failure on wrong type, which is something different.
      - Touche 12y ago
        I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated. Sure it's less certain than what you get from a compiler; that's the tradeoff for not having to compile in development. Since most JavaScript code is not type-sensitive it's only important in code that you are more than likely going to be testing heavily anyways.

by stiff 12y ago

jackweirdy 12y ago

Really? I find it happens as often as NullPointerExceptions. Viva la Maybe type

drderidder 12y ago

Yeah, that can be confusing. On the other hand, if you write unit / functional tests then testing for invalid inputs one of the first things you'll probably do. Your comment makes me think a fuzzer to test all those falsey values could be useful.

stiff 12y ago
A lot of JavaScript is UI code though, so unit tests might not be possible, and a suite of comprehensive functional tests with something like Selenium gets dog slow very fast, in my experience.
nardi 12y ago
In general, this argument is self-defeating: "I don't need a type checker because I write unit tests." Obviously that means you need a type checker, because then you don't have to write 70-90% of your unit tests. Unit tests require time and energy to produce, run, and maintain. A type-checking compiler can remove much of this burden from the developer.

ep103 12y ago

yeah, but all of these examples would just be fixed if your devs are required to write unit test coverage of their js

Touche 12y ago

I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.

arjie 12y ago
But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test. Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.
- Touche 12y ago
  I don't understand what you mean by "But in a rare code path, that may not to be triggered." Can you explain? I wasn't suggesting using tests; I was suggesting using asserts. Directly in the function that is type sensitive. If that function is ever called with an incorrect type it will throw an exception. I get the benefit of optional type checking without a compile step in development like with Flow.
  - arjie 12y ago
    Well, I assumed you'd want to spot that error before it happens rather than when it does. The exception being thrown by the assert (at run-time) means that the user sees the failure. That's sub-optimal, right? So you'd ensure that there is testing of all code that calls this code in order to trigger the exception ahead of time if that occurs. Or am I misunderstanding? It just seems that the assert applies the constraint too late in the process. It doesn't ensure you have the right type once you've deployed. Instead it ensures failure on wrong type, which is something different.
    - Touche 12y ago
      I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated. Sure it's less certain than what you get from a compiler; that's the tradeoff for not having to compile in development. Since most JavaScript code is not type-sensitive it's only important in code that you are more than likely going to be testing heavily anyways.