News for hackers. Stuff that matters.
Re:Why We Chose Typescript by jmull on Saturday July 01, 2017 @11:55AM (#14677599)
But that's really a symptom of a "big ball of mud" design (non-design, really), where everything has dependencies scattered all over the system, and to change anything you have to consider everything.

Type checking can help you with a few kinds of problems you'll have trying to make changes in those kinds of systems, but you still have piles of problems and it doesn't do anything to help improve the underlying issue.

Static types can help you with some small problems, but that doesn't mean much when the problems you have are big.

Re:Why We Chose Typescript by epidemian on Saturday July 01, 2017 @01:51PM (#14678089)
> But that's really a symptom of a "big ball of mud" design (non-design, really)

Yep, that's exactly the problem :)

The thing is that, without ease of refactoring, it's very difficult to change that big ball of mud into something prettier. In fact, i'd say that without ease of refactoring it's kind of inevitable to fall into that big ball of mud "design" in the long run.

(Note: static type systems are not the only tools to help with refactoring. Good test coverage, style guidelines, a well documented / simple architecture, are of course very helpful too.)

Re:Why We Chose Typescript by davidjnelson on Saturday July 01, 2017 @06:28PM (#14679413)
Exactly. Static types ( I've used flow not typescript, but similar ) and good unit tests allow ridiculously easy and merciless refactoring of enormous swaths of code in an extremely short period of time with incredibly high confidence.

Integration tests ( not to be confused with functional tests / i.e.: selenium ) that test multiple classes in concert via input / expected output give the most bang for the buck, because you know your code works as a whole.

Re:Why We Chose Typescript by always_good on Saturday July 01, 2017 @01:01PM (#14677862)
Static types are especially useful in big ball of mud design because you can refactor it (like change the shape of a canonical object) and mechanically fix all write/read sites without running the code.

Not sure how that's a small problem unless you never refactor code.