6 ms·

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

by swift 10y ago

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.

mcphage 10y ago
> 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?
- tracker1 10y ago
  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.
  - mcphage 10y ago
    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.
- lomnakkus 10y ago
  > 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).
  - mcphage 10y ago
    > 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?
    - lomnakkus 10y ago
      > 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.
      - mcphage 10y ago
        > 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.
orgomon 10y ago
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.
- pixie_ 10y ago
  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.
- k__ 10y ago
  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.
- bubersson 10y ago
  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.

by swift 10y ago

mcphage 10y ago

> 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?

tracker1 10y ago
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.
- mcphage 10y ago
  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.
lomnakkus 10y ago
> 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).
- mcphage 10y ago
  > 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?
  - lomnakkus 10y ago
    > 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.
    - mcphage 10y ago
      > 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.

orgomon 10y ago

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.

pixie_ 10y ago
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.
k__ 10y ago
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.
bubersson 10y ago
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.