6 ms·

> To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. I've coded using static and dyn

> To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability. But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler". A better test suite can have exponential more value on maintainability than types. > Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1] So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved. [1] https://github.com/giltayar/proposal-types-as-comments/#community-usage-and-demand https://github.com/giltayar/proposal-types-as-comments/#comm...

azangru 5y ago
> A better test suite can have exponential more value on maintainability than types. A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types. The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase. Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.
- kemiller2002 5y ago
  I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function. Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.
  - vlovich123 5y ago
    I think "truly expert programmer" is hypothetical. I don't think I encounter many programmers that prefer to eschew typing unless it's a quick one-off script. Typing your code takes maybe 1-10% of the time it takes to right (if that). It provides far more value than tests. Just like Rust's ownership model in the type system provides much better results than C++'s implicit ownership model + tests.
    - kemiller2002 5y ago
      That's exactly my point. There are very few people that are real experts, people that can see code and reason everything in their heads with little or no help. There really aren't any. Everyone thinks they are, but they aren't. Having types helps the rest of us understand what is going.
  - danbruc 5y ago
    I always say that Types are not there for the truly expert programmer. They are there for the rest of us. I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.
    - azangru 5y ago
      > beginners pick languages without [much] typing because it is or at least it seems easier to get started It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners. You don't see much lisp among beginners, despite the absence of type notation.
      - kazinator 5y ago
        > It's hard to tell whether the reason beginners pick languages is because they are not typed No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about. > You don't see much lisp among beginners, despite the absence of type notation. Lisps are simply not widely promoted to beginners; there aren't enough people to do that. Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.
b6dybuyv 5y ago
I guess there are differences between how static typing is implemented. I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act. It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.
zarzavat 5y ago
Unit tests aren’t a replacement for static types. Tests aren’t machine readable so you lose all those nice IDE refactoring features and have to manually keep them up to date. Also running a test suite takes time, it takes a lot longer to run a test suite than it does to get live typecheck, which means you cannot use tests while you are editing. And you probably don’t want to clog up your test suite with endless “x is a Y” tests. In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.
deleted 5y ago
[deleted]
eyelidlessness 5y ago
> Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability. > But unfortunately it does not bring that much value. If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place. People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it. In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.

azangru 5y ago

> A better test suite can have exponential more value on maintainability than types. A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types. The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase. Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.

kemiller2002 5y ago
I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function. Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.
- vlovich123 5y ago
  I think "truly expert programmer" is hypothetical. I don't think I encounter many programmers that prefer to eschew typing unless it's a quick one-off script. Typing your code takes maybe 1-10% of the time it takes to right (if that). It provides far more value than tests. Just like Rust's ownership model in the type system provides much better results than C++'s implicit ownership model + tests.
  - kemiller2002 5y ago
    That's exactly my point. There are very few people that are real experts, people that can see code and reason everything in their heads with little or no help. There really aren't any. Everyone thinks they are, but they aren't. Having types helps the rest of us understand what is going.
- danbruc 5y ago
  I always say that Types are not there for the truly expert programmer. They are there for the rest of us. I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.
  - azangru 5y ago
    > beginners pick languages without [much] typing because it is or at least it seems easier to get started It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners. You don't see much lisp among beginners, despite the absence of type notation.
    - kazinator 5y ago
      > It's hard to tell whether the reason beginners pick languages is because they are not typed No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about. > You don't see much lisp among beginners, despite the absence of type notation. Lisps are simply not widely promoted to beginners; there aren't enough people to do that. Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.

b6dybuyv 5y ago

I guess there are differences between how static typing is implemented. I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act. It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.

zarzavat 5y ago

Unit tests aren’t a replacement for static types. Tests aren’t machine readable so you lose all those nice IDE refactoring features and have to manually keep them up to date. Also running a test suite takes time, it takes a lot longer to run a test suite than it does to get live typecheck, which means you cannot use tests while you are editing. And you probably don’t want to clog up your test suite with endless “x is a Y” tests. In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.

deleted 5y ago

[deleted]

eyelidlessness 5y ago

> Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability. > But unfortunately it does not bring that much value. If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place. People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it. In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.