Hacker News Reader

Comment by swift | Hacker News Reader

I notice in your comments that you express concern about the development cost imposed by static typing, but then you later on state that you expect type errors to be caught by tests.

Here's the thing: test coverage is crucial on any large project, and we (hopefully) all agree that they're worth it, but tests can be very hard to write and impose a huge development cost. Static typing helps reduce that cost by reducing the number of tests you need to write. Generally, the more powerful the type system, the more the number of tests you need to write is reduced.

It's been my experience that the development cost of static typing is infinitesimal compared to the savings of having to write and maintain fewer tests. YMMV.

View on HN

> Static typing helps reduce that cost by reducing the number of tests you need to write.

Those type annotations are the tests, they're just run by the compiler. And once you realize that, you can start to ask: are these the most valuable tests to write? If I have a fixed amount of time to write & maintain tests, would that time be better spent testing things more likely to be incorrect?

In the case of TS, they go out the window at runtime... anything outside of your project that comes in (json via rpc or rest) or outside-in calls/callbacks don't enforce the type safety.

Yeah, and that's frustrating because it also eliminates the performance gains that come when you can determine what exact function will be called, rather than having to determine it at runtime. I guess that's the consequence of TS being a superset of JS.

> Those type annotations are the tests,

Disagree slightly. Type annotations are logical propositions and the compiler proves them for you.

That is to say: Tests can only prove the presence of bugs, not absence. Types prove the absence of (type-related) bugs. They essentially give you theoretically perfect test coverage (modulo bugs in the compiler).

> They essentially give you theoretically perfect test coverage (modulo bugs in the compiler).

Theoretically perfect test coverage, for a particular class of bugs. But that class of bugs isn't the most prevalent class, nor are they the hardest class to fix. So it still is a question of, is that the best place to put development time? And beyond that—are all type annotations equally relevant, or are there some that are very valuable, and some that are less so, and so an optionally typed language would be ideal in that regard?

> Theoretically perfect test coverage, for a particular class of bugs. But that class of bugs isn't the most prevalent class [snip]

Well, except maybe is is? They're certainly extremely severe when they occur. (Especially if your language is weakly typed like C/C++.)

Without the proper research, who knows? (I'm only talking about my own experience, so YMMV. I'm not even sure a proper metric for a 'fair' comparison can be constructed, even in theory, so again YMMV.)

EDIT: Just curious as a point of interest: What statically typed languages do you have non-trivial experience in? This is not a gotcha, or a haha-look-a-the-noob type question. I find that the quality of the $ST_LANG has a huuuuuuuge impact on how people perceive the value of $ST_IN_GENERAL... if that makes sense.

> Well, except maybe is is? They're certainly extremely severe when they occur. [...] Without the proper research, who knows?

Maybe is is? In general that hasn't been my experience (they happen, but not that often, and are usually easy to figure out).

I agree that research is needed to decide, but the research I've seen references doesn't seem to hold that up. But it's not something I've looked closely into; too much discussion about it ends up getting into holy war arguments, and I stay away.

> I'm only talking about my own experience, so YMMV.

Me as well :-)

> What statically typed languages do you have non-trivial experience in?

Java (which has a garbage type system) and Objective-C. I'm in the process of learning Swift and Scala, but I don't have much experience in either yet. More languages back when I was in college, but that was a while ago, and you don't really get non-trivial experience in college.

> I find that the quality of the $ST_LANG has a huuuuuuuge impact on how people perceive the value of $ST_IN_GENERAL...

I agree 100%. And it's not that I think ST is worthless—although Java's type system really tries its damnedest to make it worthless—but spending most of my time in Ruby, one of the wildest-west languages out there, I still don't find type errors cropping up very often, or being a major issue when they do. On occasion, sure, one can be hard to find. But they're really not a major source of error in my day-to-day life; and if ever a language were susceptible to them, it's Ruby.

Still, if the language used matters that much, then it's not just ST that's the solution, it's ST with a certain level of sophistication.

Test coverage is crucial as code matures and is finalized, not necessarily when it is prototyped - which is exactly where a type system gets in the way.

I disagree with the idea that you need to write more tests because of dynamic typing, my claim is that the tests you have to write anyway also cover type errors. Just running your code yourself covers most type errors.

Typing doesn't get in the way of prototyping code. On the contrary it's essential. When you're starting out a new project the tendancy to refactor is very high. Everything is changing and in flux as you go from nothing to something. Having static typing makes refactoring quick, easy, and most of all safe. Developing new projects for myself in TypeScript vs JavaScript is exponentially faster.

If you know types from, Java, then you're in for a treat.

TypeScript is so much better to work with. Most of the time it feels like ES2015.

I have this only from experience, no hard numbers, but I've seen the types make more and more sense with more developers developing the same app. If it's just upto 2 devs I would consider writing it in plain JavaScript. Currently we have around 8 devs in frontend and having type checking via Closure saved us so many times. It's also nice to use the same struct definitions both on Go server and in JS (we have the structs defined by protobufs and we generate both Go files and Closure JS annotations from it). It also gives us nice autocompletion in the IDE.

Reply on news.ycombinator.com