Hacker News new | past | comments | ask | show | jobs | submit login

So many people in the thread saying this. But in my experience refactoring large code bases in both Java and Javascript, it's roughly the same. Ultimately the real answer will have to come from a peer reviewed study, because as the post suggests, these sorts of things are not as intuitive as people think



I have done multiple times both refactoring of untyping JS and JS fully typed with Flow. With the latter after the Flow compiler stopped complaining one can expect things to work. With the former despite extensive tests sometimes it took weeks to fix bugs caused by the refactoring.

Granted this is personal experience and I may be simply not careful enough to do untyped refactoring, but few people I talked about that shared the experience.


Anecdotes don't really count for much, of course, but the balance is against you, here. It is clearly and evidently true that when you refactor, static typing systems find a lot of errors that you would discover at runtime in dynamically-typed systems. It's true almost by definition.

It can still be fine if you're being meticulous and know the codebase well enough, but otherwise, you'll miss corner cases in parts of the code with less test coverage or typical interaction. When you accidentally occasionally have a string in place of a number deep in some data structure, you might not notice for a long time.


Java does not have anything like strong typing. Likewise C. Results comparing to Java or C are intrinsically useless and actively misleading.

Studies insisting static typing has no effect always assume the runtime-typed program is less buggy than it really is.


How are you defining strongly typed here? Wikipedia says the definition is loose [1] but also says that Java is usually considered stronger than many other languages

[1]: https://en.wikipedia.org/wiki/Strong_and_weak_typing


Java's type system is only passively useful. There is no way to put it to work on behalf of designers to deliver more powerful libraries, unlike C++, Haskell, and, to a lesser but still significant degree, Rust.


Does your JavaScript require higher test coverage to achieve the same level of safety?


Hard to measure, the javascript I worked with was mostly front-end, which is harder to write automated tests for. Not impossible, but the higher friction naturally leads to less tests, especially given how frequent the front-end changes. "Level of safety" would also need better quantification. Something that a peer-reviewed study would be better suited for




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: