4 ms·

I once attended a talk by someone who is or was big in the node.js world. He opened with the premise, "a static type check is just a stand-in for a unit test."

by phaedrus 10mo ago

I once attended a talk by someone who is or was big in the node.js world. He opened with the premise, "a static type check is just a stand-in for a unit test." I wanted to throw a shoe at him. A static type check doesn't stand in for "a" unit test; static typing stands in for an unbounded number of unit tests. Put another way, this common misconception by users of languages like Javascript and Python that unit testing is just as good as type checking (plus more flexible) is a confusion between the "exists" and "for all" logical operators.

lesuorac 10mo ago
If you care about the type of a parameter you can just add an assertion in the method /s
kccqzy 10mo ago
Plus, it is simply more enjoyable to design the types in your program than to write unit tests. The fun factor comes from operating on a higher level of abstraction and engages more of your brain’s puzzle-solving mode than just writing unit tests. Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used.
- zahlman 9mo ago
  > it is simply more enjoyable to design the types in your program than to write unit tests. I have tried both and I have no idea what you're talking about. > Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used. The entire point of dynamic typing is that you can think about interfaces rather than concrete types, which entails deep consideration of the properties of the object (semantics of the provided interface).
  - array_key_first 9mo ago
    That's not the entire point of dynamic typing, because all the interface stuff comes from statically typed languages. Some* dynamic languages borrowed it, but most use "implicit" interfaces - where the interface is whatever kind of works, I guess.
    - zahlman 9mo ago
      > because all the interface stuff comes from statically typed languages. No, it doesn't. It comes from theory that came after the languages. > Some* dynamic languages borrowed it, but most use "implicit" interfaces An implicit interface is an interface, and is exactly the sort of thing I'm talking about in GP. The point is that you think about the object in terms of its capabilities, rather than some proven-up-front categorization that it fits into. What it does, not what it is.
      - maleldil 9mo ago
        You can achieve this with structural subtyping, such as Go interfaces and Python protocols. Whether that is desirable is a different question.
seg_lol 10mo ago
Hundreds of unit tests replace a type. Start using properties and it is in the thousands. Most code should be typed. Python is great for prototypes, but once the prototype gels, you need types.
- baq 9mo ago
  Good that Python supports types then
  - lelanthran 9mo ago
    > Good that Python supports types then "Optional typing" is not the same as "Static typing". Great, my program will crash, because I forgot to opt-in to typing :-/
    - paulddraper 9mo ago
      C has void pointers.
      - lelanthran 9mo ago
        > C has void pointers. And? Void pointers are not the default type :-/ With Python I have to do extra work to get type errors. With C I have to do extra work to hide the type errors. I am battling to understand the point you are making.
        baq 9mo ago
        Hard to argue with an argument which isn’t internally coherent.
        array_key_first 9mo ago
        He's probably conflating static and strong typing. C is statically typed, but weakly typed - you need to throw away types to do a bunch of run of the mill things. Python is dynamically typed, but strongly typed, where it will just fail if typed don't resolve. C# and C++ are both statically typed and strongly typed, although C# more than C++ in practice.
pmontra 9mo ago
Good luck using static typing to model many real world unit tests for the programming languages people use most. I start with an easy example: those records should be sorted by date of birth. We can move on to more complicated scenarios.
- Jaxan 9mo ago
  The comment didn’t claim that types are a stand in for tests either! IMO, they are orthogonal.
  - zahlman 9mo ago
    The comment explicitly set out to refute the idea "...that unit testing is just as good as type checking" by describing the former as simply inferior.
    - Veserv 9mo ago
      No. They refuted the claim that "a static type check is just a stand-in for a unit test". That is a claim that you can just remove your type checks and replace them with unit tests at no loss. The comment stated that removing a type check just so you can replace it with a unit test is inferior. The prior state was already pre-supposed to have a type check/type checkable condition that you could replace. That is the literal converse of the claim in the response to that comment arguing that the comment stated that all unit tests can be replaced with type checks. Those are not at all the same claim. To make it even more clear the comment said: I saw a talk that said Type Check -> Unit Test. I said that is silly. Response said: Unit Test -> Type Check is not reasonable. So clearly your claim that Type Check -> Unit Test is silly is wrong.
- paulddraper 9mo ago
  No one claims that types are a stand in for all unit tests. They stand in for the banal unit tests.
- jodrellblank 9mo ago
  > "records should be sorted by date of birth." What's wrong with C#'s: System.Collections.Generic.SortedList<DoBDateTime, PersonRecord> ?
tasuki 9mo ago
> I wanted to throw a shoe at him. You should have!
imiric 9mo ago
Agreed. Besides, it's not like types don't matter in dynamically typed languages. The (competent) programmer still needs to keep types in their head while programming. "Can this function work with a float, or must I pass an int?" "This function expects an iterable, but what happens if I pass a string?" Etc. I started my career with JavaScript and Python, but over the years I've come to the conclusion that a language that hides types from programmers and does implicit conversion magic in the background does not deliver a better DX. It might make the language more approachable initially, and the idea of faster prototyping might be appealing, but it very quickly leads to maintenance problems and bugs. Before type hinting tools for Python became popular, I worked on many projects where `TypeError` was the #1 exception in Sentry by a large margin. Gradual and optional typing is better than nothing, but IME if the language doesn't require it, most programmers are lazy and will do the bare minimum to properly add type declarations. Especially with things like TypeScript, which makes many declarations difficult to read, write, and understand. I think that type inference is a solid middle ground. Types are still statically declared, but the compiler is smart enough to not bother the developer when the type is obvious.
- zahlman 9mo ago
  > Before type hinting tools for Python became popular, I worked on many projects where `TypeError` was the #1 exception in Sentry by a large margin. My experience is radically different. `ValueError` is far more common in my un-annotated Python, and the most common cause of `TypeError` anyway is the wrong order or number of arguments after a refactoring.
  - imiric 9mo ago
    Hhmm I could be misremembering if it was `ValueError` or `TypeError`. This was a few years ago. I know that typing issues were always the most frequent in any Python project I have worked on. How is your experience different?
zahlman 9mo ago
> A static type check doesn't stand in for "a" unit test; static typing stands in for an unbounded number of unit tests. You have conflated "a static type check" with "static typing". Unit tests stand in, in the same way, for an unbounded number of states of real-world input. They're simply being subjected to a trial verification system rather than a proof system. It turns out that writing proofs is not very many people's idea of a good time, even in the programming world. And the concept of "type" that's normally grokked is anemic anyway. > Put another way... Rhetoric like this is unconvincing and frankly insulting. You pass off your taste and opinion as fact, while failing to understand opposed arguments.
andrewl-hn 9mo ago
> "a static type check is just a stand-in for a unit test." This is not an original argument. Rich Hickey made a similar argument in his "Simple made easy" talk in 2011, though his focus was on a fact that every bug that easiest in a software system has passed unnoticed through both a type checker and a test suit. And even before that similar ideas of test suits being a suitable replacement for a type checker have percolated through Python and Ruby communities, too. I distinctly remember that the "tests makes static type checks unnecessary" was in fact so prevalent in JavaScript community that TypeScript had really hard time getting adoption in its first 3-4 years, and only the introduction of VSCode in 2015 and subsequent growth of its marketshare over Atom and SublimeText got more people exposed to TypeScript and the benefits of a type checker. Overall it took almost 10 years for Typescript to become the "default" language for web projects.

lesuorac 10mo ago

If you care about the type of a parameter you can just add an assertion in the method /s

kccqzy 10mo ago

Plus, it is simply more enjoyable to design the types in your program than to write unit tests. The fun factor comes from operating on a higher level of abstraction and engages more of your brain’s puzzle-solving mode than just writing unit tests. Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used.

zahlman 9mo ago
> it is simply more enjoyable to design the types in your program than to write unit tests. I have tried both and I have no idea what you're talking about. > Making yourself think about “for all x” rather than a concrete x forces your brain to consider deeply the properties of x being used. The entire point of dynamic typing is that you can think about interfaces rather than concrete types, which entails deep consideration of the properties of the object (semantics of the provided interface).
- array_key_first 9mo ago
  That's not the entire point of dynamic typing, because all the interface stuff comes from statically typed languages. Some* dynamic languages borrowed it, but most use "implicit" interfaces - where the interface is whatever kind of works, I guess.
  - zahlman 9mo ago
    > because all the interface stuff comes from statically typed languages. No, it doesn't. It comes from theory that came after the languages. > Some* dynamic languages borrowed it, but most use "implicit" interfaces An implicit interface is an interface, and is exactly the sort of thing I'm talking about in GP. The point is that you think about the object in terms of its capabilities, rather than some proven-up-front categorization that it fits into. What it does, not what it is.
    - maleldil 9mo ago
      You can achieve this with structural subtyping, such as Go interfaces and Python protocols. Whether that is desirable is a different question.

seg_lol 10mo ago

Hundreds of unit tests replace a type. Start using properties and it is in the thousands. Most code should be typed. Python is great for prototypes, but once the prototype gels, you need types.

baq 9mo ago
Good that Python supports types then
- lelanthran 9mo ago
  > Good that Python supports types then "Optional typing" is not the same as "Static typing". Great, my program will crash, because I forgot to opt-in to typing :-/
  - paulddraper 9mo ago
    C has void pointers.
    - lelanthran 9mo ago
      > C has void pointers. And? Void pointers are not the default type :-/ With Python I have to do extra work to get type errors. With C I have to do extra work to hide the type errors. I am battling to understand the point you are making.
      - baq 9mo ago
        Hard to argue with an argument which isn’t internally coherent.
      - array_key_first 9mo ago
        He's probably conflating static and strong typing. C is statically typed, but weakly typed - you need to throw away types to do a bunch of run of the mill things. Python is dynamically typed, but strongly typed, where it will just fail if typed don't resolve. C# and C++ are both statically typed and strongly typed, although C# more than C++ in practice.

pmontra 9mo ago

Good luck using static typing to model many real world unit tests for the programming languages people use most. I start with an easy example: those records should be sorted by date of birth. We can move on to more complicated scenarios.

Jaxan 9mo ago
The comment didn’t claim that types are a stand in for tests either! IMO, they are orthogonal.
- zahlman 9mo ago
  The comment explicitly set out to refute the idea "...that unit testing is just as good as type checking" by describing the former as simply inferior.
  - Veserv 9mo ago
    No. They refuted the claim that "a static type check is just a stand-in for a unit test". That is a claim that you can just remove your type checks and replace them with unit tests at no loss. The comment stated that removing a type check just so you can replace it with a unit test is inferior. The prior state was already pre-supposed to have a type check/type checkable condition that you could replace. That is the literal converse of the claim in the response to that comment arguing that the comment stated that all unit tests can be replaced with type checks. Those are not at all the same claim. To make it even more clear the comment said: I saw a talk that said Type Check -> Unit Test. I said that is silly. Response said: Unit Test -> Type Check is not reasonable. So clearly your claim that Type Check -> Unit Test is silly is wrong.
paulddraper 9mo ago
No one claims that types are a stand in for all unit tests. They stand in for the banal unit tests.
jodrellblank 9mo ago
> "records should be sorted by date of birth." What's wrong with C#'s: System.Collections.Generic.SortedList<DoBDateTime, PersonRecord> ?

tasuki 9mo ago

> I wanted to throw a shoe at him. You should have!

imiric 9mo ago

Agreed. Besides, it's not like types don't matter in dynamically typed languages. The (competent) programmer still needs to keep types in their head while programming. "Can this function work with a float, or must I pass an int?" "This function expects an iterable, but what happens if I pass a string?" Etc. I started my career with JavaScript and Python, but over the years I've come to the conclusion that a language that hides types from programmers and does implicit conversion magic in the background does not deliver a better DX. It might make the language more approachable initially, and the idea of faster prototyping might be appealing, but it very quickly leads to maintenance problems and bugs. Before type hinting tools for Python became popular, I worked on many projects where `TypeError` was the #1 exception in Sentry by a large margin. Gradual and optional typing is better than nothing, but IME if the language doesn't require it, most programmers are lazy and will do the bare minimum to properly add type declarations. Especially with things like TypeScript, which makes many declarations difficult to read, write, and understand. I think that type inference is a solid middle ground. Types are still statically declared, but the compiler is smart enough to not bother the developer when the type is obvious.

zahlman 9mo ago
> Before type hinting tools for Python became popular, I worked on many projects where `TypeError` was the #1 exception in Sentry by a large margin. My experience is radically different. `ValueError` is far more common in my un-annotated Python, and the most common cause of `TypeError` anyway is the wrong order or number of arguments after a refactoring.
- imiric 9mo ago
  Hhmm I could be misremembering if it was `ValueError` or `TypeError`. This was a few years ago. I know that typing issues were always the most frequent in any Python project I have worked on. How is your experience different?

zahlman 9mo ago

> A static type check doesn't stand in for "a" unit test; static typing stands in for an unbounded number of unit tests. You have conflated "a static type check" with "static typing". Unit tests stand in, in the same way, for an unbounded number of states of real-world input. They're simply being subjected to a trial verification system rather than a proof system. It turns out that writing proofs is not very many people's idea of a good time, even in the programming world. And the concept of "type" that's normally grokked is anemic anyway. > Put another way... Rhetoric like this is unconvincing and frankly insulting. You pass off your taste and opinion as fact, while failing to understand opposed arguments.

andrewl-hn 9mo ago

> "a static type check is just a stand-in for a unit test." This is not an original argument. Rich Hickey made a similar argument in his "Simple made easy" talk in 2011, though his focus was on a fact that every bug that easiest in a software system has passed unnoticed through both a type checker and a test suit. And even before that similar ideas of test suits being a suitable replacement for a type checker have percolated through Python and Ruby communities, too. I distinctly remember that the "tests makes static type checks unnecessary" was in fact so prevalent in JavaScript community that TypeScript had really hard time getting adoption in its first 3-4 years, and only the introduction of VSCode in 2015 and subsequent growth of its marketshare over Atom and SublimeText got more people exposed to TypeScript and the benefits of a type checker. Overall it took almost 10 years for Typescript to become the "default" language for web projects.