2 ms·

> Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority

> Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. > Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function. I wouldn't agree with that. Issues with string/number conversions, strings being treated like arrays and unexpected undefined/null (these are particularly bad) are common in my experience in JavaScript. Even if they're not particularly common, you really think having to define a few interfaces takes so much time it nullifies the benefit of automatic error checking? Writing an interface is way less effort than writing a test as well, plus you get automatic refactoring tools, autocomplete and automatic error checking in return. I really can't see why you'd want to give all that up to save a few keystrokes. I've done years of JavaScript after moving from typed languages like OCaml, C++, Java and Coq, and it's horrible trying to write large apps in plain JavaScript without types.

chrisco255 9y ago
Unexpected nulls are common in typed languages like Java and C# as well. I know some static functional languages go much further and offer superior protection and reliability. I'm willing to believe that. However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Also, because there's mutable state everywhere buried in Java classes, you get many more logic errors. At the end of the day, I think simplicity is the best hedge against errors. However, I tend to agree that statically typed, functional languages are probably the best for preventing errors.
- seanwilson 9y ago
  > However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Type inference solves the extra typing issue and Java isn't a great example of a strongly typed language. For JavaScript, you can use TypeScript which has type inference and non-null checking. There's also BuckleScript or Reason if you want to code in OCaml so there's practical ways to get this safety in JavaScript. > At the end of the day, I think simplicity is the best hedge against errors. You can have static types + simplicity though which is better than just simplicity. Types and immutability constrain the behaviour of your program to make it simpler to reason about.

chrisco255 9y ago

Unexpected nulls are common in typed languages like Java and C# as well. I know some static functional languages go much further and offer superior protection and reliability. I'm willing to believe that. However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Also, because there's mutable state everywhere buried in Java classes, you get many more logic errors. At the end of the day, I think simplicity is the best hedge against errors. However, I tend to agree that statically typed, functional languages are probably the best for preventing errors.

seanwilson 9y ago
> However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Type inference solves the extra typing issue and Java isn't a great example of a strongly typed language. For JavaScript, you can use TypeScript which has type inference and non-null checking. There's also BuckleScript or Reason if you want to code in OCaml so there's practical ways to get this safety in JavaScript. > At the end of the day, I think simplicity is the best hedge against errors. You can have static types + simplicity though which is better than just simplicity. Types and immutability constrain the behaviour of your program to make it simpler to reason about.