4 ms·

> So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languag

by theamk 5y ago

> So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages ... Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages". It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent. That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.

ok123456 5y ago
This is pretty much my feeling. I'm not adding types because I have some kind of brain rot that makes me need AbstractFactoryBeanContainerAnnotationFactory. I like adding type annotation because it means you can do static analysis on your code base. Without it, you need exhaustive coverage tests to demonstrate what exactly can be returned.
cxr 5y ago
> That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. It's also helpful to consider whether they constitute unnecessary requirements[1]. Most mainstream JS code is rife with problems like this—including rampant mis-/over-use of triple equals. (I call this "going out of your way to do the wrong thing".) 1. https://www.teamten.com/lawrence/programming/dont-invent-unnecessary-requirements.html https://www.teamten.com/lawrence/programming/dont-invent-unn...
- johncolanduoni 5y ago
  In what situation do you want the whole spectrum of `==` behavior in JS, other than possibly the `undefined == null` case? I’d argue exercising any of the other type conversion cases like `1 == true` or implicit `valueOf/toString` makes the code much harder to understand.
  - cxr 5y ago
    To ask the question is to fundamentally misunderstand the context. Please do check out the link. It's not a matter of wanting "the whole spectrum" of double equals (and then justifying that). You need to justify the requirements you're imposing. The article I linked gives an excellent example of why unnecessary requirements should be avoided. Aside from that, overuse of triple equals is almost always a code smell that indicates the contributor is coming from a place of following cargo cult advice instead of solid understanding. (And in the case of the cargo cult advice about triple equals, it's not even very logical advice. I.e. it's not just the people following the advice who aren't thinking it through—the people dispensing it tend to be engaged in shallow thinking, too.) For example, anyone who asks you in a code review to replace `typeof(x) == y` with 'typeof(x) === y` has no solid reason whatsoever for that change (and will never have any; there is no argument that will hold up under scrutiny).
bayesian_horse 5y ago
Adding types to an overly complicated and unreadable javascript codebase helped me to make sure I understand it before I refactor it.

by theamk 5y ago

ok123456 5y ago

This is pretty much my feeling. I'm not adding types because I have some kind of brain rot that makes me need AbstractFactoryBeanContainerAnnotationFactory. I like adding type annotation because it means you can do static analysis on your code base. Without it, you need exhaustive coverage tests to demonstrate what exactly can be returned.

cxr 5y ago

> That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. It's also helpful to consider whether they constitute unnecessary requirements[1]. Most mainstream JS code is rife with problems like this—including rampant mis-/over-use of triple equals. (I call this "going out of your way to do the wrong thing".) 1. https://www.teamten.com/lawrence/programming/dont-invent-unnecessary-requirements.html https://www.teamten.com/lawrence/programming/dont-invent-unn...

johncolanduoni 5y ago
In what situation do you want the whole spectrum of `==` behavior in JS, other than possibly the `undefined == null` case? I’d argue exercising any of the other type conversion cases like `1 == true` or implicit `valueOf/toString` makes the code much harder to understand.
- cxr 5y ago
  To ask the question is to fundamentally misunderstand the context. Please do check out the link. It's not a matter of wanting "the whole spectrum" of double equals (and then justifying that). You need to justify the requirements you're imposing. The article I linked gives an excellent example of why unnecessary requirements should be avoided. Aside from that, overuse of triple equals is almost always a code smell that indicates the contributor is coming from a place of following cargo cult advice instead of solid understanding. (And in the case of the cargo cult advice about triple equals, it's not even very logical advice. I.e. it's not just the people following the advice who aren't thinking it through—the people dispensing it tend to be engaged in shallow thinking, too.) For example, anyone who asks you in a code review to replace `typeof(x) == y` with 'typeof(x) === y` has no solid reason whatsoever for that change (and will never have any; there is no argument that will hold up under scrutiny).

bayesian_horse 5y ago

Adding types to an overly complicated and unreadable javascript codebase helped me to make sure I understand it before I refactor it.