3 ms·

Also, TODAY type checking (and more important, how Types are used) is not the same than YESTERDAY types usage. Java, C++ and similar are terrible benchmark for

by mamcx 5y ago

Also, TODAY type checking (and more important, how Types are used) is not the same than YESTERDAY types usage. Java, C++ and similar are terrible benchmark for it. Before, types were almost for do taxonomy, with limited help to actually write CORRECT code, and more important, MODELING the domain was very verbose and with limited advantages!. Against that, no static types makes more sense. With o without the end result, result-wise was kinda the same, only that without you remove a lot of noise on the codebase. Only after a bit of the ML/oCalm/Haskell/etc type-system get in, and NULL removal becomes truly feasible, and some of the failures of error-prone software and how WRONG JS,C++ and for some extend, Java become more and more evident, then modern static types start to leverage a greater return of investment. It also come together with other improvements in tooling (that make more enjoyable type inference on IDEs, for example), composability, iterators/generators, etc and you get a very nice toolset. This is where everyone is converging, in some way or another.

Too 5y ago
Another way to phrase this is that in old languages, static types were added for the compiler, while in modern languages they are added for the developers (specifically, the teammates of the developer). This is why hybrid typing is so prevalent nowadays, as you don’t need to satisfy any internal need of the compiler, but you can still keep the documentation of models and interfaces that static typing gives, where desired. Performance is usually also a no-factor nowadays unless you have high demands. On top of this, the only reason JavaScript grew so large was that there was literally no other way to ship code to a user. IE6 was the universe. Nobody wrote code like this by choice. And those unfortunate souls that did still have scars from it. Remember this was also before CI checking every PR for correctness became as common as it is today. Because of all this, there will not be any “swing of the pendulum” back to the crazy era of untyped PHP, JavaScript without TS or python without mypy. This is something that is here to stay.
pron 5y ago
You may believe that, but the fact is that we haven't been able to find any evidence to support the fact that "new types" significantly increase correctness and have a greater return on investment, either compared to "old types" or in general, and not for lack of trying. At this point, it's okay to believe it, but I'd be very careful about being so sure about it. Large effects are very easy to detect and are hard to hide. The fact that we haven't been able to easily see the effect in any rigorous way, suggests that even if there is some positive effect, the most reasonable assumption we can make right now is that it is most likely small. Having had experience with both "new types" and "old types," my personal impression (which is certainly not rigorous or necessarily trustworthy) is that such claims about a big bottom-line impact are exaggerated. Sometimes people feel they're writing more correct programs more easily, but the bottom line doesn't quite support it.
- mamcx 5y ago
  > we haven't been able to find any evidence to support the fact that "new types" significantly increase correctness and have a greater return on investment Rust? A lot of people say Rust improve the game (I'm one of them). I have coded in +12 langs all my life,. Rust totally remove tons of issues (for me) that were present in the past just before shipping and even after. And I port the same project. The kind of issues I get of the Rust codebase are a fraction of what I has. --- And I think many studies show it?
  - pron 5y ago
    I was expecting someone would say that. There are very specific situations where a language has an advantage over an exceptionally "bad" language in the same domain, such as Rust vs. C or TypeScript vs. JS (for which we also have evidence of a ~15% improvement). But that doesn't mean that the very concept of "new types" generally has a big impact. E.g., it's easier to write more correct software in Rust than in C, but probably not than in Java or even (the untyped) Clojure. Rust is a special case because its main contribution is to use typing rules to solve a harmful problem that's well-known and particular to C (or C++).
    - john-shaffer 5y ago
      Clojure is strongly typed and dynamically typed, not "untyped". Much of its core behavior is built on interfaces like ISeq. It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.
      - pron 5y ago
        The term "untyped" means anything that isn't statically typed (or just "typed"). This is because (static) types and dynamic "types" are two very different objects, and only the former is called "types" in programming language theory and formal languages in general. I am well aware of clojure.spec, and it, as well as many other techniques employed in development, are probably among the reasons why types don't actually seem to have a big relative impact on correctness.

by mamcx 5y ago

Too 5y ago

Another way to phrase this is that in old languages, static types were added for the compiler, while in modern languages they are added for the developers (specifically, the teammates of the developer). This is why hybrid typing is so prevalent nowadays, as you don’t need to satisfy any internal need of the compiler, but you can still keep the documentation of models and interfaces that static typing gives, where desired. Performance is usually also a no-factor nowadays unless you have high demands. On top of this, the only reason JavaScript grew so large was that there was literally no other way to ship code to a user. IE6 was the universe. Nobody wrote code like this by choice. And those unfortunate souls that did still have scars from it. Remember this was also before CI checking every PR for correctness became as common as it is today. Because of all this, there will not be any “swing of the pendulum” back to the crazy era of untyped PHP, JavaScript without TS or python without mypy. This is something that is here to stay.

pron 5y ago

You may believe that, but the fact is that we haven't been able to find any evidence to support the fact that "new types" significantly increase correctness and have a greater return on investment, either compared to "old types" or in general, and not for lack of trying. At this point, it's okay to believe it, but I'd be very careful about being so sure about it. Large effects are very easy to detect and are hard to hide. The fact that we haven't been able to easily see the effect in any rigorous way, suggests that even if there is some positive effect, the most reasonable assumption we can make right now is that it is most likely small. Having had experience with both "new types" and "old types," my personal impression (which is certainly not rigorous or necessarily trustworthy) is that such claims about a big bottom-line impact are exaggerated. Sometimes people feel they're writing more correct programs more easily, but the bottom line doesn't quite support it.

mamcx 5y ago
> we haven't been able to find any evidence to support the fact that "new types" significantly increase correctness and have a greater return on investment Rust? A lot of people say Rust improve the game (I'm one of them). I have coded in +12 langs all my life,. Rust totally remove tons of issues (for me) that were present in the past just before shipping and even after. And I port the same project. The kind of issues I get of the Rust codebase are a fraction of what I has. --- And I think many studies show it?
- pron 5y ago
  I was expecting someone would say that. There are very specific situations where a language has an advantage over an exceptionally "bad" language in the same domain, such as Rust vs. C or TypeScript vs. JS (for which we also have evidence of a ~15% improvement). But that doesn't mean that the very concept of "new types" generally has a big impact. E.g., it's easier to write more correct software in Rust than in C, but probably not than in Java or even (the untyped) Clojure. Rust is a special case because its main contribution is to use typing rules to solve a harmful problem that's well-known and particular to C (or C++).
  - john-shaffer 5y ago
    Clojure is strongly typed and dynamically typed, not "untyped". Much of its core behavior is built on interfaces like ISeq. It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.
    - pron 5y ago
      The term "untyped" means anything that isn't statically typed (or just "typed"). This is because (static) types and dynamic "types" are two very different objects, and only the former is called "types" in programming language theory and formal languages in general. I am well aware of clojure.spec, and it, as well as many other techniques employed in development, are probably among the reasons why types don't actually seem to have a big relative impact on correctness.