3 ms·

As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems. People will ARGUE about the benefits of compile-

As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems. People will ARGUE about the benefits of compile-time checking. However, when people point to concrete benefits, they tend to point to TOOLING communication. (e.g. IDEs supplying functions/variables that provide the necessary type) during writing. Rarely do they notice these two are not the same thing. I'm not in a place to say which is objectively correct (I'm both biased and without the right kind of data), but I've seen this distinction come up time and time again. I think it's the most interesting part (also the only part that is interesting) about typing disputes.

naasking 7y ago
> Rarely do they notice these two are not the same thing. Types enable better tooling. That's why people mention tooling when types come up.
- munificent 7y ago
  Static types enable better static tooling. Dynamic types enable better dynamic tooling. :) These days, most programmers are very familiar with high quality static tooling (IDEs) but less familiar with high quality dynamic tooling.
  - ridiculous_fish 7y ago
    Right on. Here's an amazing example. Pharo Smalltalk has a feature where you can find methods by giving an example of the input and output you expect. Forget how to uppercase a string? Just write: 'eureka' . 'EUREKA' and the IDE will suggest the method asUppercase. It does this by dynamically invoking all of string's methods until it finds one whose output matches!
    - naasking 7y ago
      Neat, but not generalizable because methods often have side effects. You could easily know when this search is safe in a language that types side-effects, like Haskell. So types can enhance this feature too.
      - deleted 7y ago
        [deleted]
    - marcosdumay 7y ago
      This actually exploits a static component of the type. This would not work on a fully dynamic type system.
      - ridiculous_fish 7y ago
        I don't get it, why not?
        marcosdumay 7y ago
        On a fully dynamic type system, static analysis can't know what functions accept strings. It would have to try every single function, what is not viable, because many have side effects.
    - zaphirplane 7y ago
      Does the language have rm -fr method ? ;) Still. nice
  - naasking 7y ago
    Maybe! But you have to admit that having static types with an AST available provides considerably more program synthesis and intellisense possibilities than only having an AST.
    - ridiculous_fish 7y ago
      The dynamically typed case is not "only an AST," it's a living and breathing program. It made this HTTP request and performed some computation and read that file, and you can talk to it and learn all about its state!
      - naasking 7y ago
        Don't confuse dynamic typing with metaprogramming or fexpr. These are all orthogonal. Tooling for dynamically typed languages as a whole only have access to the AST, although some with the above features may have access to more.
  - xigency 7y ago
    Exactly. I think the dynamic tooling are things like macros. It seems that JavaScript is being used as the dynamically typed foil, where a better example would be Scheme.
- ergothus 7y ago
  My point being that when I ask why static is better (from people arguing that), they'll talk about compile-time checks, they won't talk about the tooling. When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks, they'll point to how they find it easier to write code because the IDE suggests things.
  - naasking 7y ago
    No dynamic type system can achieve the same safety properties as type systems like TyPiCal: http://www-kb.is.s.u-tokyo.ac.jp/~koba/typical/ http://www-kb.is.s.u-tokyo.ac.jp/~koba/typical/
  - revvx 7y ago
    I think it's hard to point to "bugs prevented by compile-time checks" because of the nature of type-checking. I could just say that every time the compiler refuses to compile my code due to a type error a bug is averted. Typos, wrong method signatures, interfaces not implemented correctly. All those things had the potential to be bugs. Small, detectable and perhaps even non-breaking, but it's still good to catch them early on. And of course, most of the time a good enough test suite would catch them. But having the compiler warning you is so much faster! And much more reliable too, because I'm not perfect and sometimes I make mistakes in my tests.
  - zbentley 7y ago
    > When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks Similarly, if you ask a writer who uses a pencil about the benefits of their approach versus a pen, they likely won't reference any specific times when they would have made un-erasable mistakes.
- Gibbon1 7y ago
  Tooling in this case replaces a lot of boiler plate unit tests. The stronger and more rigorous the typing the fewer ad hoc tests that need to be hand written. I think the cost is the tooling becomes more finicky about what you feed it. C weakly typed -> compile -> run-> crash -> WTF?!!! Rust strongly typed -> WTF? Why no compile!!
skybrian 7y ago
An intermediate goal when using static types is that the checked-in code should have type annotations that are guaranteed correct, so you can rely on them when reasoning about the code, either manually (just by reading it) or automatically (using tools). Traditionally this is done in a compiler, but it could also be done in another tool like some kind of linter, provided that it's always run before committing a patch and/or as part of a continuous build.
revvx 7y ago
Can I try giving a non-IDE example? I rarely use IDEs, but compile-time checks are super useful for me during refactoring. Sometimes I need to rename a class, a method name or a method signature that is used all over the program. I could use tests, but the compiler is much faster and much more comprehensive. So I change everything in one go and then only run the tests after that. The speed in itself is great, and helps me get much faster feedback than I can get with tests. It's also great during explorational programming, or during the prototype phase: some errors can be detected during compilation, so I'm not greeted with an easily avoidable runtime error. As for an example of a bug that would have been prevented by compile-time checking, I had one happen just last week. It was in a project with 100% test coverage, but we had undetected refactoring errors due to a lack of integration testing: there were (good) unit tests with mocks, but we missed them during refactoring, triggering a runtime error in production. We fixed that by writing a few simple integration tests and fixed the code. This happened just last week. No biggie, but would be avoided by a compiler.
- latch 7y ago
  Your first example has _nothing_ to do with static or dynamic typing. There are plenty of dynamic languages that will fail to compile or bootup with a helpful error message on a failed rename. This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages." If you've used JavaScript and you assign all of the challenges of writing JavaScript to dynamic typing, then ya, dynamic typing sucks. But the problem isn't dynamic typing, the problem is JavaScript.
  - revvx 7y ago
    In the first example I was merely answering the grandparent. They mentions that people talk about the advantages of compile-time checking but fail to give examples. I'm merely giving an example that other people failed to give them. > This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages." Friend, this is completely uncalled for. A single HN answer doesn't say anything about my experience with multiple languages.

naasking 7y ago

> Rarely do they notice these two are not the same thing. Types enable better tooling. That's why people mention tooling when types come up.

munificent 7y ago
Static types enable better static tooling. Dynamic types enable better dynamic tooling. :) These days, most programmers are very familiar with high quality static tooling (IDEs) but less familiar with high quality dynamic tooling.
- ridiculous_fish 7y ago
  Right on. Here's an amazing example. Pharo Smalltalk has a feature where you can find methods by giving an example of the input and output you expect. Forget how to uppercase a string? Just write: 'eureka' . 'EUREKA' and the IDE will suggest the method asUppercase. It does this by dynamically invoking all of string's methods until it finds one whose output matches!
  - naasking 7y ago
    Neat, but not generalizable because methods often have side effects. You could easily know when this search is safe in a language that types side-effects, like Haskell. So types can enhance this feature too.
    - deleted 7y ago
      [deleted]
  - marcosdumay 7y ago
    This actually exploits a static component of the type. This would not work on a fully dynamic type system.
    - ridiculous_fish 7y ago
      I don't get it, why not?
      - marcosdumay 7y ago
        On a fully dynamic type system, static analysis can't know what functions accept strings. It would have to try every single function, what is not viable, because many have side effects.
  - zaphirplane 7y ago
    Does the language have rm -fr method ? ;) Still. nice
- naasking 7y ago
  Maybe! But you have to admit that having static types with an AST available provides considerably more program synthesis and intellisense possibilities than only having an AST.
  - ridiculous_fish 7y ago
    The dynamically typed case is not "only an AST," it's a living and breathing program. It made this HTTP request and performed some computation and read that file, and you can talk to it and learn all about its state!
    - naasking 7y ago
      Don't confuse dynamic typing with metaprogramming or fexpr. These are all orthogonal. Tooling for dynamically typed languages as a whole only have access to the AST, although some with the above features may have access to more.
- xigency 7y ago
  Exactly. I think the dynamic tooling are things like macros. It seems that JavaScript is being used as the dynamically typed foil, where a better example would be Scheme.
ergothus 7y ago
My point being that when I ask why static is better (from people arguing that), they'll talk about compile-time checks, they won't talk about the tooling. When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks, they'll point to how they find it easier to write code because the IDE suggests things.
- naasking 7y ago
  No dynamic type system can achieve the same safety properties as type systems like TyPiCal: http://www-kb.is.s.u-tokyo.ac.jp/~koba/typical/ http://www-kb.is.s.u-tokyo.ac.jp/~koba/typical/
- revvx 7y ago
  I think it's hard to point to "bugs prevented by compile-time checks" because of the nature of type-checking. I could just say that every time the compiler refuses to compile my code due to a type error a bug is averted. Typos, wrong method signatures, interfaces not implemented correctly. All those things had the potential to be bugs. Small, detectable and perhaps even non-breaking, but it's still good to catch them early on. And of course, most of the time a good enough test suite would catch them. But having the compiler warning you is so much faster! And much more reliable too, because I'm not perfect and sometimes I make mistakes in my tests.
- zbentley 7y ago
  > When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks Similarly, if you ask a writer who uses a pencil about the benefits of their approach versus a pen, they likely won't reference any specific times when they would have made un-erasable mistakes.
Gibbon1 7y ago
Tooling in this case replaces a lot of boiler plate unit tests. The stronger and more rigorous the typing the fewer ad hoc tests that need to be hand written. I think the cost is the tooling becomes more finicky about what you feed it. C weakly typed -> compile -> run-> crash -> WTF?!!! Rust strongly typed -> WTF? Why no compile!!

skybrian 7y ago

An intermediate goal when using static types is that the checked-in code should have type annotations that are guaranteed correct, so you can rely on them when reasoning about the code, either manually (just by reading it) or automatically (using tools). Traditionally this is done in a compiler, but it could also be done in another tool like some kind of linter, provided that it's always run before committing a patch and/or as part of a continuous build.

revvx 7y ago

Can I try giving a non-IDE example? I rarely use IDEs, but compile-time checks are super useful for me during refactoring. Sometimes I need to rename a class, a method name or a method signature that is used all over the program. I could use tests, but the compiler is much faster and much more comprehensive. So I change everything in one go and then only run the tests after that. The speed in itself is great, and helps me get much faster feedback than I can get with tests. It's also great during explorational programming, or during the prototype phase: some errors can be detected during compilation, so I'm not greeted with an easily avoidable runtime error. As for an example of a bug that would have been prevented by compile-time checking, I had one happen just last week. It was in a project with 100% test coverage, but we had undetected refactoring errors due to a lack of integration testing: there were (good) unit tests with mocks, but we missed them during refactoring, triggering a runtime error in production. We fixed that by writing a few simple integration tests and fixed the code. This happened just last week. No biggie, but would be avoided by a compiler.

latch 7y ago
Your first example has _nothing_ to do with static or dynamic typing. There are plenty of dynamic languages that will fail to compile or bootup with a helpful error message on a failed rename. This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages." If you've used JavaScript and you assign all of the challenges of writing JavaScript to dynamic typing, then ya, dynamic typing sucks. But the problem isn't dynamic typing, the problem is JavaScript.
- revvx 7y ago
  In the first example I was merely answering the grandparent. They mentions that people talk about the advantages of compile-time checking but fail to give examples. I'm merely giving an example that other people failed to give them. > This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages." Friend, this is completely uncalled for. A single HN answer doesn't say anything about my experience with multiple languages.