4 ms·

It's amusing to see people realizing that type annotations are useful. They are practically the most important and most widely used form of unit testing and doc

It's amusing to see people realizing that type annotations are useful. They are practically the most important and most widely used form of unit testing and documentation. It's like discovering that bidet exists or something. Let's consider the ultimate programming language that is able to infer your business requirement before you do or you even knowing what it is. Its only limitation (perhaps by design) is that it just can't write it. It can perform this amazing static analysis of the code and tell things like "hey, the requirement said to return a JSON with the following keys X and Y, but you are missing X. Oh and also you forgot to mail John the patch for that client". Would programming in this language hard? OF COURSE! This language will constantly complain and wont run your program until you get your requirement exactly right. But I would argue this language is the best language to work with. You might say, "I will never ship a code because it will never be complete!" Well, dear friend, why not just admit that flaw and lower down your business requirement to include those deficiencies?

goto11 4y ago
Type annotations are not comparable to unit tests at all. Unit tests verifies correctness of the behavior, not just the types. E.g. if you have a mathematical function like min(), unit tests can verify it return the smallest of the inputs. Type annotations can at best verify that it returns a value of the same type as the input, but not if it is the smallest, largest or something random. Type annotations are great for documentation and as a basic sanity test. They are especially useful with tools like code analysis or refactoring tools. But types are is no way a substitute for unit tests.
- kajaktum 4y ago
  It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. How do you make sure your function that takes an `any` doesn't crash and burn or silently sneak through and write null to the database?
  - goto11 4y ago
    > It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.
    - kajaktum 4y ago
      A and B refers to the expected data type, yes.
      - goto11 4y ago
        So proving that `min(number, number)` returns a number is 99% as good as a unit test which shows that it returns the smallest number?
        kajaktum 4y ago
        yes because the set of possible inputs for A -> C is basically infinite. But min(A,B)=C is only 2^64^2. Why shouldn't you test for string, object, object of object, object with a certain kind of shape, or Number class as opposed to number primitive? How can you know it will or won't work from a unit test perspective? >inb4 just document it that is what types are for
        goto11 4y ago
        But the purpose of unit tests is to show that the code under test is correct, i.e. that min() return the smallest input, not just a random value of the same type. Static typing cannot do that, so it is in no way a substitute for unit tests. Static typing is a useful tool, just not a substitute for any unit tests. The risk of static typing is when it becomes a goal in itself and you start thinking correctness means the program satisfies the type checker.
  - 4y ago
- deterministic 4y ago
  That very much depends on the type system you use. With (for example) refinement types and dependent types you can prove your code correct with zero tests needed. Examples are F*, Idris, Agda, Coq etc.
  - techdragon 4y ago
    Prove the code is correct per the design, it doesn’t eliminate the possibility of design errors which can still benefit from tests (or QuickCheck like tools) to ensure that what you design does what you think it does … a critical component given how rarely you see these languages used to actually build large applications in the wild.
    - deterministic 4y ago
      The key difference is that with proven correct code you actually have a formal spec you can prove properties about. Without proven correct code you don’t even have a formal spec. Just a bunch of random tests (if you are lucky) that may or may not match your informal spec. And the argument that if you can’t prove your design correct then there is no point proving your code correct is a strange one. That’s like saying that there is no point writing tests because you can’t prove your design correct or guarantee that all tests needed will be written. Ehhhh nope. I have written and generated more than 9000 tests for a very large scale C++ applications that are used by large corporations around the world. And I haven’t had a bug in production for 5+ years. However I of course can’t prove that those tests cover everything or that my design is correct. But that doesn’t mean it isn’t worth doing.
      - pdimitar 4y ago
        Yeah, I feel way too many people mistake "we can't cover 100% of everything" with "it's not worth tightening the bolts". Strange conflation but a very common one indeed.
  - astrange 4y ago
    All well-formed code is always a correct version of itself (Curry-Howard correspondence). It's just that sometimes you thought it was a correct version of something else and turn out to be wrong about that. Since dependent type systems are just another kind of code, this is still true.
- kazinator 4y ago
  a * sin(x) + b * cos (-x) should have been a * sin(x) - b * cos (x) type isn't worth a damn here. In a lot of situations you have related values of exactly the same type: floats, strings, integers, Widget objects, which get mixed up. A warning about variable shadowing or unused variable can be worth more than a type diagnostic. E.g. suppose a * sin(x) - a * cos (x) is written by mistake. If that causes b to be an unused local variable, we get a valuable diagnostic.
nine_zeros 4y ago
I love typing. But python's type annotation is absolute garbage. The fact that you need to import types should tell you what a load of shit it is. All files now have type imports. Yuck. In addition, the only way type annotations are effective is if you use an editor that can parse types. Yuck. Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage.
- kajaktum 4y ago
  >Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage. No. Having types is always better than not. If you have a complex functionality, it is going to have a complex type. But now you KNOW its complex and not have to unravel its complexity for the 5th time this month. I had to write something like this recently: ``` pub SearchInfo { matches: Arc<HashMap<PathBuf, Vec<(usize, (usize, usize), String)>>> } ``` This is complex, yes, but just by reading the type and names given to it: 1. `Arc`. So that means it can be safely shared across thread. 2. `HashMap` from `PathBuf` to `X`. So I am probably mapping file/folders to X. 3. `Vec<(usize, (usize, usize), String)>`. So the first `usize` denotes the line number. `(usize,usize)` denotes the start and end characters and the `String` is the whole line itself! Just imagine unraveling this whole crap if its all simply a JavaScript `Object`.
  - pkolaczk 4y ago
    It would be probably better if you haven't used naked usize, but wrapped it into a new type. When I find types get complex, I introduce type aliases or structs. That X in your signature likely deserves a name.
  - tipsytoad 4y ago
    I'd convert that last tuple to struct, unlike the rest of the type it's undecipherable without some kind of documentation.
- 4y ago
not_enoch_wise 4y ago
“lower down your business requirement” I’m guessing you’ve never talked to someone requesting dev work on upwork
musicale 4y ago
> It's like discovering that bidet exists or something. They're known and readily available in the US, but never really caught on, even during and after widespread toilet paper shortages in 2020. Probably California would ban them anyway along with toilets that actually work.
noloblo 4y ago
haskell
noloblo 4y ago
pick fp and haskell / ocaml/ racket/ common lisp

goto11 4y ago

Type annotations are not comparable to unit tests at all. Unit tests verifies correctness of the behavior, not just the types. E.g. if you have a mathematical function like min(), unit tests can verify it return the smallest of the inputs. Type annotations can at best verify that it returns a value of the same type as the input, but not if it is the smallest, largest or something random. Type annotations are great for documentation and as a basic sanity test. They are especially useful with tools like code analysis or refactoring tools. But types are is no way a substitute for unit tests.

kajaktum 4y ago
It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. How do you make sure your function that takes an `any` doesn't crash and burn or silently sneak through and write null to the database?
- goto11 4y ago
  > It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language. Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.
  - kajaktum 4y ago
    A and B refers to the expected data type, yes.
    - goto11 4y ago
      So proving that `min(number, number)` returns a number is 99% as good as a unit test which shows that it returns the smallest number?
      - kajaktum 4y ago
        yes because the set of possible inputs for A -> C is basically infinite. But min(A,B)=C is only 2^64^2. Why shouldn't you test for string, object, object of object, object with a certain kind of shape, or Number class as opposed to number primitive? How can you know it will or won't work from a unit test perspective? >inb4 just document it that is what types are for
        goto11 4y ago
        But the purpose of unit tests is to show that the code under test is correct, i.e. that min() return the smallest input, not just a random value of the same type. Static typing cannot do that, so it is in no way a substitute for unit tests. Static typing is a useful tool, just not a substitute for any unit tests. The risk of static typing is when it becomes a goal in itself and you start thinking correctness means the program satisfies the type checker.
- 4y ago
deterministic 4y ago
That very much depends on the type system you use. With (for example) refinement types and dependent types you can prove your code correct with zero tests needed. Examples are F*, Idris, Agda, Coq etc.
- techdragon 4y ago
  Prove the code is correct per the design, it doesn’t eliminate the possibility of design errors which can still benefit from tests (or QuickCheck like tools) to ensure that what you design does what you think it does … a critical component given how rarely you see these languages used to actually build large applications in the wild.
  - deterministic 4y ago
    The key difference is that with proven correct code you actually have a formal spec you can prove properties about. Without proven correct code you don’t even have a formal spec. Just a bunch of random tests (if you are lucky) that may or may not match your informal spec. And the argument that if you can’t prove your design correct then there is no point proving your code correct is a strange one. That’s like saying that there is no point writing tests because you can’t prove your design correct or guarantee that all tests needed will be written. Ehhhh nope. I have written and generated more than 9000 tests for a very large scale C++ applications that are used by large corporations around the world. And I haven’t had a bug in production for 5+ years. However I of course can’t prove that those tests cover everything or that my design is correct. But that doesn’t mean it isn’t worth doing.
    - pdimitar 4y ago
      Yeah, I feel way too many people mistake "we can't cover 100% of everything" with "it's not worth tightening the bolts". Strange conflation but a very common one indeed.
- astrange 4y ago
  All well-formed code is always a correct version of itself (Curry-Howard correspondence). It's just that sometimes you thought it was a correct version of something else and turn out to be wrong about that. Since dependent type systems are just another kind of code, this is still true.
kazinator 4y ago
a * sin(x) + b * cos (-x) should have been a * sin(x) - b * cos (x) type isn't worth a damn here. In a lot of situations you have related values of exactly the same type: floats, strings, integers, Widget objects, which get mixed up. A warning about variable shadowing or unused variable can be worth more than a type diagnostic. E.g. suppose a * sin(x) - a * cos (x) is written by mistake. If that causes b to be an unused local variable, we get a valuable diagnostic.

nine_zeros 4y ago

I love typing. But python's type annotation is absolute garbage. The fact that you need to import types should tell you what a load of shit it is. All files now have type imports. Yuck. In addition, the only way type annotations are effective is if you use an editor that can parse types. Yuck. Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage.

kajaktum 4y ago
>Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage. No. Having types is always better than not. If you have a complex functionality, it is going to have a complex type. But now you KNOW its complex and not have to unravel its complexity for the 5th time this month. I had to write something like this recently: ``` pub SearchInfo { matches: Arc<HashMap<PathBuf, Vec<(usize, (usize, usize), String)>>> } ``` This is complex, yes, but just by reading the type and names given to it: 1. `Arc`. So that means it can be safely shared across thread. 2. `HashMap` from `PathBuf` to `X`. So I am probably mapping file/folders to X. 3. `Vec<(usize, (usize, usize), String)>`. So the first `usize` denotes the line number. `(usize,usize)` denotes the start and end characters and the `String` is the whole line itself! Just imagine unraveling this whole crap if its all simply a JavaScript `Object`.
- pkolaczk 4y ago
  It would be probably better if you haven't used naked usize, but wrapped it into a new type. When I find types get complex, I introduce type aliases or structs. That X in your signature likely deserves a name.
- tipsytoad 4y ago
  I'd convert that last tuple to struct, unlike the rest of the type it's undecipherable without some kind of documentation.
4y ago

not_enoch_wise 4y ago

“lower down your business requirement” I’m guessing you’ve never talked to someone requesting dev work on upwork

musicale 4y ago

> It's like discovering that bidet exists or something. They're known and readily available in the US, but never really caught on, even during and after widespread toilet paper shortages in 2020. Probably California would ban them anyway along with toilets that actually work.

noloblo 4y ago

haskell

noloblo 4y ago

pick fp and haskell / ocaml/ racket/ common lisp