Hacker News Reader

> At work we recently did a timed programming problem solving competition.

Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to maintainable codebases far beyond their prototype phase.

> In any case, this article was a fun one to read:

> https://medium.com/javascript-scene/the-typescript-tax-132ff...

It might be fun, but it reads like a movie review where the author gives arbitrary scores and somehow determines TypeScript's ROI based on that(?). The rest of the article mostly appeals to authority, as the author pushes his books, expertise and vast experience as proof, something you seem to be doing as well.

I feel like the mentioned "To Type or Not to Type" paper[1] is a more realistic study of the benefits of static typing, despite TS detecting "only" 15% of possible bugs. That's still 15% of bugs detected _during development_ that the programmer doesn't have to think about, and doesn't have to write thousands of very trivial tests to _maybe_ catch them locally or worse yet, in CI. This in practice never actually happens, let alone in code reviews!

Yes, static typing is not a panacea. But it's a tool that has high chances of producing higher quality software, something that is sorely needed in JS land.

[1]: http://earlbarr.com/publications/typestudy.pdf

Also, if you are using a statically typed language there are tools for property based testing like QuickCheck which eliminates the need to write those thousands of very trivial tests. I've seen one advertised for JavaScript but you can't guarantee it'll find everything thanks to typecasting.

At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems.

If you're looking at the kind of requirements that can be implemented in under an hour, of course a stronger, more static type system isn't likely to gain you much. It's highly unlikely that such a program is going to have lots of different people working on it over a period of possibly years, or that it's going to use lots of different but possibly related data structures, or that it's going to develop libraries with hundreds or thousands of little utility functions for working with those data structures.

However, drawing conclusions about the merits of a stronger, more static type system based on this sort of challenge is like arguing that a language where all code has to be in defined modules and functions is much less efficient than a scripting language like Python because in the latter you can write a "Hello, world!" program in literally one line.

Strongly typed programs tend to have less bugs. There's been a few systematic surveys of large open-source projects looking at the number of issues raised/bugs found and they all show the same results.

I recently joined a company that uses formal methods and Haskell for a globally distributed system and I can't imagine going back to JavaScript for something similar. Being able to reason about a system is important and it's almost impossible to reason about non-statically typed systems.

I don't seen how problem solving competitions are any measure of worth for a language. That's like saying, teams that wrote tests didn't complete as many of the problems, so we shouldn't write tests. What about maintainability, ease of refactoring, catching of bugs during compliation time etc. There are tradeoffs to everything, you just have to decide what matters most to you.

> None of the TypeScript teams got past level 5. All of the rest got past level 15.

The TypeScript-using teams also wrote a bunch of machine-verifiable documentation and code navigation tools, so I'm not surprised it was slower. I can tell you without even looking at them which codebases will tend to be more pleasant to join as a new developer. Though probably doing that extra, unrewarded work for some kind of challenge where speed is paramount wasn't the best idea.

Yeah, Typescript does slow a project down.

It's not even about using types. Sometimes you get stuck trying to resolve Typescript issues that are not part of your core problem.

Sounds like you just don't know how to cast a type for your specific case rather than a TS bug, which is fair to say as sometimes you need decent time to learn how to do it.