3 ms·

> That problem? Not using statically typed languages. TDD was invented by a Java programmer. How does that fit into your world view?

by hbrn 4y ago

com2kid 4y ago
Java's original type system, while static, was far from being powerful enough to provide strong guarantees of safety. Saying age is an int is great, but Java doesn't let you say age is an int ranging from 0 to 130. You can of course create an age object, but the constraints on that object cannot be expressed within the type system. So you have to add unit tests instead, the unit tests in effect extend the type system out to be as powerful as type systems from the 80s. Yay, progress! :/
- hbrn 4y ago
  > Java doesn't let you say age is an int ranging from 0 to 130 This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
  - com2kid 4y ago
    > This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer. Unit Tests are no different, except with worse syntax than built in language support. At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds. There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along. The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.
    - hbrn 4y ago
      > Ada solved this in the 80s, it isn't some unresolved field of comp sci Every solution comes at a cost. Where is Ada now? > Unit Tests are no different, except with worse syntax than built in language support. And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. > At least with support in the type system you can turn off range checks for production builds Sounds like dynamic typing with extra steps.
      - com2kid 4y ago
        > And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. So you don't advocate for unit tests, you don't want a powerful type system, what do you want? > Every solution comes at a cost. Where is Ada now? A source of features for newer languages, thus is the circle of programming language life. > Sounds like dynamic typing with extra steps. Static assertions based on build flags have been around for a very long time, in all sorts of languages. They are a performance/safety trade off.
        hbrn 4y ago
        > So you don't advocate for unit tests, you don't want a powerful type system, what do you want? "Write tests. Not too many. Mostly integration." Leave static typing for performance-critical sections. > They are a performance/safety trade off. So is dynamic typing. Only performance in this case means developer performance. Turns out most of our software is not landing airplanes, and developer performance is way more important than occasional non-critical bug that affects 5 users and gets fixed within a day.

> That problem? Not using statically typed languages. TDD was invented by a Java programmer. How does that fit into your world view?

by hbrn 4y ago

> That problem? Not using statically typed languages. TDD was invented by a Java programmer. How does that fit into your world view?

com2kid 4y ago

Java's original type system, while static, was far from being powerful enough to provide strong guarantees of safety. Saying age is an int is great, but Java doesn't let you say age is an int ranging from 0 to 130. You can of course create an age object, but the constraints on that object cannot be expressed within the type system. So you have to add unit tests instead, the unit tests in effect extend the type system out to be as powerful as type systems from the 80s. Yay, progress! :/

hbrn 4y ago
> Java doesn't let you say age is an int ranging from 0 to 130 This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
- com2kid 4y ago
  > This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer. Unit Tests are no different, except with worse syntax than built in language support. At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds. There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along. The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.
  - hbrn 4y ago
    > Ada solved this in the 80s, it isn't some unresolved field of comp sci Every solution comes at a cost. Where is Ada now? > Unit Tests are no different, except with worse syntax than built in language support. And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. > At least with support in the type system you can turn off range checks for production builds Sounds like dynamic typing with extra steps.
    - com2kid 4y ago
      > And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. So you don't advocate for unit tests, you don't want a powerful type system, what do you want? > Every solution comes at a cost. Where is Ada now? A source of features for newer languages, thus is the circle of programming language life. > Sounds like dynamic typing with extra steps. Static assertions based on build flags have been around for a very long time, in all sorts of languages. They are a performance/safety trade off.
      - hbrn 4y ago
        > So you don't advocate for unit tests, you don't want a powerful type system, what do you want? "Write tests. Not too many. Mostly integration." Leave static typing for performance-critical sections. > They are a performance/safety trade off. So is dynamic typing. Only performance in this case means developer performance. Turns out most of our software is not landing airplanes, and developer performance is way more important than occasional non-critical bug that affects 5 users and gets fixed within a day.