5 ms·

As we have recently adopted TypeScript, this is a nice affirmation, but preventing bugs is only part of the benefit and I'm not sure it's the most important par

As we have recently adopted TypeScript, this is a nice affirmation, but preventing bugs is only part of the benefit and I'm not sure it's the most important part. TypeScript, in conjunction with a code editor that supports it, significantly improves the code editing experience. Sometimes I still have to chase down documentation, examples, etc. to figure out how to use something, but it happens far less often. In general, I feel like I can code faster and with more confidence. I assume all this is also true of Flow, though I've never used it.

seanmcdirmid 9y ago
The killer apps of static types are code completion, documentation, modelling rather than safety and performance. This makes TypeScript's unsoundness much more acceptable, though many in the type systems community still have a difficult time grocking this.
- taeric 9y ago
  Pretty sure the first code completion programs were in dynamic languages. With many environments, you literally asked the object what methods it had. Same for documentation.
  - seanmcdirmid 9y ago
    The first code completion system was in Alice Pascal circa 1986. Statically typed. After that, it appears in production for the first time in VS 97, still using static type information. It wasn't present in smalltalk IDEs before then, or LISP ones.
    - taeric 9y ago
      I'll confess this surprises me, but not overly so. I'll try to find what I was thinking of. Primarily, I thought you could do live reflection in lisp machines. Which is basically this.
      - seanmcdirmid 9y ago
        The primitives to do something isn't equivalent to doing it. So lisp machines had live reflection, but they didn't have the UX in place to surface the experience that we know today as code completion, they essentially didn't know that this feature existed or would be useful. As we know, UX is very important. A similar situation happens today when we argue about live programming. Smalltalk had the infrastructure in place (hot code replace, fix and continue) to do much of it, but never provided the UX for what we would recognize as a live programming experience. Defining the experience is as important, if not more, than being able to realize it.
        taeric 9y ago
        I'm not sure I appreciate the distinction here. I am not claiming that the original toolsets were the same as modern ones. In large, I would expect that was a limitation in memory and extra resources. Similarly, I expect the completion you are referencing is a far cry from modern completion. I remember early completion that I had access to was limited to available methods only. Was the referenced one more sophisticated? That is, I was really only trying to reference the primitives. Because, well, progress. :)
        seanmcdirmid 9y ago
        Alice Pascal's code completion isn't really sophisticated, just convenient. They needed it because it was a syntactic editor and typing things was inconvenient. It turned out to be a good idea (for exploration) outside of its original context (save on typing)...but it's discovery was basically an accident.
        taeric 9y ago
        I should add that I do appreciate being corrected here! I can't edit the parent post anymore to indicate that my claim was likely to be interpreted in a false way, unfortunately. Hopefully interested folks read down the thread.
        9y ago
    - flavio81 9y ago
      Lisp, with SLIME (Lisp IDE tool for Emacs), gives you coding completion with a dynamic language. This isn't exclusive for dynamic languages. However i don't want to debate "static" vs "dynamic". Static typing has advantages, it's simply that the advantages I see are performance (execution speed) ones. As mentioned above, i don't buy the idea that simple type errors are a serious speed bump in development speed.
      - seanmcdirmid 9y ago
        SLIME wasn't released until 2003. As an active promoter of live programming, I'm totally enthusiastic about code completion using dynamic type information. It just didn't happen before static types. Code completion on dynamic execution context is a bit challenging because you need to surface execution context somehow (which is a problem live programming focuses on).
        ratmice 9y ago
        it looks like guile's readline came in 97, with tab completion added in 98
        unkown-unknowns 9y ago
        Tab completion is often a small subset of code completion. When I think of tab completion I think of it being able to complete something you start typing based on what it knows to exist, but rarely does it understand much context. Code completion meanwhile knows context much better.
        ratmice 9y ago
        right, context did exist at that point but seems limited to filenames, and symbols afaict, obviously though you can obtain much more context in a statically typed environment
        deleted 9y ago
        [deleted]
  - dmix 9y ago
    Code completion goes beyond auto-completing method names on objects/modules. Either way this shouldn't be some tribal us vs them thing, both static/dynamic have well documented utility for different use-cases. But if we're going to make a generalization on which is easier or most capable to build complex editor integration around I'd say statically typed languages is the winner here.
    - taeric 9y ago
      Modern code completion does, yes. Just as static analysis goes beyond type checking of a language. The computing resources necessary to support modern tools is beyond what older tools had. I am not trying to make this an "us versus them." To the contrary, I'm trying to point out both toolsets have many of the same advantages. I will even concede that static languages do seem to have the better IDEs today. I assert that is as much a by product of money spent on development. Not a foregone conclusion of language design.
- maxxxxx 9y ago
  To me the big advantage of static typing is refactoring. I am dealing with a mid size JS codebase right now. It's well written but it's still really hard to refactor because you never know what code may break. In C# or C++ I can make a change and the compiler tells me what breaks. I haven't used TypeScript but it seems it will also make refatoring easier.
  - klodolph 9y ago
    At this point I've done about equal amounts of programming in JavaScript and TypeScript. Yes, that's a huge difference. Without that one difference, the languages seem really similar, especially since ES2015. I'm sure someone might chime in and say that good tests will cover that, but client-side JavaScript code can be difficult to test properly, so I'd rather just get the type checking for free.
- marcosdumay 9y ago
  I am deeply convinced the killer application of static types is polymorphism. Types create ways of organizing your code that are simply not available for dynamic languages. Unless, of course, you get out of your way writing dispatchers, as is usual in Python. But those are long, repetitive, bug-prone and can not really be made generic.
  - seanmcdirmid 9y ago
    You can have dynamic types that give you something similar. Overloading is much more difficult (though not impossible, few dynamic languages allow overloading outside of the receiver; e.g. In Dylan).
thepratt 9y ago
You hit the nail on the head. The biggest save for well structured teams would have to be revisiting tickets/speed of development. Having a compiler tell you: this field is missing, this field is wrong, a cannot be b saves a ton of time in terms of development validation (manual or automated).
- madeofpalk 9y ago
  As someone who grew up on Python and Javascript, I was never really that sold on typing, until I refactored something by changing a field on the model and Flow showed me all the places in the code that needed to be updated. Granted, other more mature type systems/IDE will automatically refactor, but this was a really big obvious win for me :)
logicallee 9y ago
The title is, provocatively, "to type or not to type." The top of the article makes it clear that it really, really, really will answer whether we should type or not type. From the top: >This is a terrific piece of work with immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use Facebook’s Flow or Microsoft’s TypeScript if so? Will they really catch bugs that would otherwise have made it to master? >TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code. In this comment I will address wherher this is really enough to deliver on that promise: Why is bugs a metric instead of bugs per programming hour, or hours of programming including fixing bugs, with or without typescript? Typescript adds types (and requires programmers to keep them in mind.) I think it's hardly controversial to claim that typed programs have a lower bug count because type errors are caught. It is also not controversial to claim that programming time is slowed down, because of the need to think of types. The question is: how much? If a programming language slowed everyone down by 5x but resulted in 75% fewer bugs, few people would choose it. Most people would choose bugs. If a programmer language was 100 times faster and only resulted in 5x as many bugs (so, instead of 100 times base rate, 500 times base rate) then I and practically everyone else would always choose it for almost everything. After all if it's 100x more productive you can take 80x productivity gain and sacrifice 20% of your programming wall time to spend on debugging. So real results around speed and bug count, as well as the insidiousness of bugs, are crucial. If the bug count were not increased in comparing a and b, but the second language had showstopping bugs that took 100x longer to find and fix, nobody would choose b. Bugs aren't just a number.
- kod 9y ago
  The article quantifies the time involved.
  - yorwba 9y ago
    Specifically, Table II gives mean times of 231.4 s (Flow) resp. 306.8 (TypeScript). So if you spend on average more than 5 minutes debugging errors that static typing could have prevented, you're probably better off just writing the annotations.
bastawhiz 9y ago
Flow has features that allow for IDE-like editing, but I'll be dammed if I ever managed to get it to work.

seanmcdirmid 9y ago

The killer apps of static types are code completion, documentation, modelling rather than safety and performance. This makes TypeScript's unsoundness much more acceptable, though many in the type systems community still have a difficult time grocking this.

taeric 9y ago
Pretty sure the first code completion programs were in dynamic languages. With many environments, you literally asked the object what methods it had. Same for documentation.
- seanmcdirmid 9y ago
  The first code completion system was in Alice Pascal circa 1986. Statically typed. After that, it appears in production for the first time in VS 97, still using static type information. It wasn't present in smalltalk IDEs before then, or LISP ones.
  - taeric 9y ago
    I'll confess this surprises me, but not overly so. I'll try to find what I was thinking of. Primarily, I thought you could do live reflection in lisp machines. Which is basically this.
    - seanmcdirmid 9y ago
      The primitives to do something isn't equivalent to doing it. So lisp machines had live reflection, but they didn't have the UX in place to surface the experience that we know today as code completion, they essentially didn't know that this feature existed or would be useful. As we know, UX is very important. A similar situation happens today when we argue about live programming. Smalltalk had the infrastructure in place (hot code replace, fix and continue) to do much of it, but never provided the UX for what we would recognize as a live programming experience. Defining the experience is as important, if not more, than being able to realize it.
      - taeric 9y ago
        I'm not sure I appreciate the distinction here. I am not claiming that the original toolsets were the same as modern ones. In large, I would expect that was a limitation in memory and extra resources. Similarly, I expect the completion you are referencing is a far cry from modern completion. I remember early completion that I had access to was limited to available methods only. Was the referenced one more sophisticated? That is, I was really only trying to reference the primitives. Because, well, progress. :)
        seanmcdirmid 9y ago
        Alice Pascal's code completion isn't really sophisticated, just convenient. They needed it because it was a syntactic editor and typing things was inconvenient. It turned out to be a good idea (for exploration) outside of its original context (save on typing)...but it's discovery was basically an accident.
        taeric 9y ago
        I should add that I do appreciate being corrected here! I can't edit the parent post anymore to indicate that my claim was likely to be interpreted in a false way, unfortunately. Hopefully interested folks read down the thread.
      - 9y ago
  - flavio81 9y ago
    Lisp, with SLIME (Lisp IDE tool for Emacs), gives you coding completion with a dynamic language. This isn't exclusive for dynamic languages. However i don't want to debate "static" vs "dynamic". Static typing has advantages, it's simply that the advantages I see are performance (execution speed) ones. As mentioned above, i don't buy the idea that simple type errors are a serious speed bump in development speed.
    - seanmcdirmid 9y ago
      SLIME wasn't released until 2003. As an active promoter of live programming, I'm totally enthusiastic about code completion using dynamic type information. It just didn't happen before static types. Code completion on dynamic execution context is a bit challenging because you need to surface execution context somehow (which is a problem live programming focuses on).
      - ratmice 9y ago
        it looks like guile's readline came in 97, with tab completion added in 98
        unkown-unknowns 9y ago
        Tab completion is often a small subset of code completion. When I think of tab completion I think of it being able to complete something you start typing based on what it knows to exist, but rarely does it understand much context. Code completion meanwhile knows context much better.
        ratmice 9y ago
        right, context did exist at that point but seems limited to filenames, and symbols afaict, obviously though you can obtain much more context in a statically typed environment
        deleted 9y ago
        [deleted]
- dmix 9y ago
  Code completion goes beyond auto-completing method names on objects/modules. Either way this shouldn't be some tribal us vs them thing, both static/dynamic have well documented utility for different use-cases. But if we're going to make a generalization on which is easier or most capable to build complex editor integration around I'd say statically typed languages is the winner here.
  - taeric 9y ago
    Modern code completion does, yes. Just as static analysis goes beyond type checking of a language. The computing resources necessary to support modern tools is beyond what older tools had. I am not trying to make this an "us versus them." To the contrary, I'm trying to point out both toolsets have many of the same advantages. I will even concede that static languages do seem to have the better IDEs today. I assert that is as much a by product of money spent on development. Not a foregone conclusion of language design.
maxxxxx 9y ago
To me the big advantage of static typing is refactoring. I am dealing with a mid size JS codebase right now. It's well written but it's still really hard to refactor because you never know what code may break. In C# or C++ I can make a change and the compiler tells me what breaks. I haven't used TypeScript but it seems it will also make refatoring easier.
- klodolph 9y ago
  At this point I've done about equal amounts of programming in JavaScript and TypeScript. Yes, that's a huge difference. Without that one difference, the languages seem really similar, especially since ES2015. I'm sure someone might chime in and say that good tests will cover that, but client-side JavaScript code can be difficult to test properly, so I'd rather just get the type checking for free.
marcosdumay 9y ago
I am deeply convinced the killer application of static types is polymorphism. Types create ways of organizing your code that are simply not available for dynamic languages. Unless, of course, you get out of your way writing dispatchers, as is usual in Python. But those are long, repetitive, bug-prone and can not really be made generic.
- seanmcdirmid 9y ago
  You can have dynamic types that give you something similar. Overloading is much more difficult (though not impossible, few dynamic languages allow overloading outside of the receiver; e.g. In Dylan).

thepratt 9y ago

You hit the nail on the head. The biggest save for well structured teams would have to be revisiting tickets/speed of development. Having a compiler tell you: this field is missing, this field is wrong, a cannot be b saves a ton of time in terms of development validation (manual or automated).

madeofpalk 9y ago
As someone who grew up on Python and Javascript, I was never really that sold on typing, until I refactored something by changing a field on the model and Flow showed me all the places in the code that needed to be updated. Granted, other more mature type systems/IDE will automatically refactor, but this was a really big obvious win for me :)

logicallee 9y ago

The title is, provocatively, "to type or not to type." The top of the article makes it clear that it really, really, really will answer whether we should type or not type. From the top: >This is a terrific piece of work with immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use Facebook’s Flow or Microsoft’s TypeScript if so? Will they really catch bugs that would otherwise have made it to master? >TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code. In this comment I will address wherher this is really enough to deliver on that promise: Why is bugs a metric instead of bugs per programming hour, or hours of programming including fixing bugs, with or without typescript? Typescript adds types (and requires programmers to keep them in mind.) I think it's hardly controversial to claim that typed programs have a lower bug count because type errors are caught. It is also not controversial to claim that programming time is slowed down, because of the need to think of types. The question is: how much? If a programming language slowed everyone down by 5x but resulted in 75% fewer bugs, few people would choose it. Most people would choose bugs. If a programmer language was 100 times faster and only resulted in 5x as many bugs (so, instead of 100 times base rate, 500 times base rate) then I and practically everyone else would always choose it for almost everything. After all if it's 100x more productive you can take 80x productivity gain and sacrifice 20% of your programming wall time to spend on debugging. So real results around speed and bug count, as well as the insidiousness of bugs, are crucial. If the bug count were not increased in comparing a and b, but the second language had showstopping bugs that took 100x longer to find and fix, nobody would choose b. Bugs aren't just a number.

kod 9y ago
The article quantifies the time involved.
- yorwba 9y ago
  Specifically, Table II gives mean times of 231.4 s (Flow) resp. 306.8 (TypeScript). So if you spend on average more than 5 minutes debugging errors that static typing could have prevented, you're probably better off just writing the annotations.

bastawhiz 9y ago

Flow has features that allow for IDE-like editing, but I'll be dammed if I ever managed to get it to work.