5 ms·

I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a

by nsonha 4y ago

I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a form of documentation). Programming is too hard?

camgunz 4y ago
Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.
- nsonha 4y ago
  no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
  - camgunz 4y ago
    Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
    - nsonha 4y ago
      The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
      - camgunz 4y ago
        > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.

by nsonha 4y ago

camgunz 4y ago

Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.

nsonha 4y ago
no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
- camgunz 4y ago
  Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
  - nsonha 4y ago
    The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
    - camgunz 4y ago
      > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.