3 ms·

> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly

> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question. So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer. Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.

vlovich123 2y ago
And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.
- immibis 2y ago
  This is the extreme end of the static checking spectrum - so extreme that you can spend hours or days per line of code, and it's so slow that about five people in the world do it on production code (and their customers pay handsomely for knowing it has been checked this way).
  - vlovich123 2y ago
    Sure. But even there you start with an understanding of how you want to solve the problem and then spend all your time writing the proof in a way that the computer can prove that you have indeed solved it correctly. At all times you generally start with an idea of a solution - you might prototype stuff to test out different solutions and how you like them but with things that are less pure R&D you need to prototype less.
tsimionescu 2y ago
TDD in this sense of building a test suite before ever having working code, or even worse, the style of TDD that Uncle Bob presents in his book, where you write some test code, then some production code to make the test pass, then some more test code, then some more production code etc. is a fantasy and/or a disaster. Especially if we're talking at the level of unit testing: unless you have a very clear outline of the code that you're going to write, and unless the problem is very well specified, you'll throw away 90% of the tests you've written as your code evolves, wasting inordinate amounts of time in the process. Regular static typing (assuming you don't go to the level of dependent types or something) has the advantage that it is extremely quick to write, compared to an equivalent test. So even if you get the types wrong 90% of the time on the first pass, you've still wasted only a trivial amount of time (consider how long it takes to write "int foo(int x)" versus tests that fail if "foo(x)" accepts anything except an int, or returns anything except an int for any int input - and how much work you'd throw away if you later realize you have to replace int with string).
- pydry 2y ago
  >unless the problem is very well specified Why wouldnt you decide what your code should do before writing it?
  - jstanley 2y ago
    Why wouldn't you just get everything right the first time and never need to learn anything new?
    - pydry 2y ago
      Getting everything right the first time != deciding what you're trying to achieve before you write the code to achieve it.
      - tsimionescu 2y ago
        If you write unit tests for what you're trying to achieve, and then after you achieve it it turns out you didn't get everything right and the code was supposed to do something different, then those unit tests were almost pure waste: you have tests that assert your code is doing the wrong thing (which you thought was the right thing intially). So not only is the code wasted, the unit tests that tested it, which are likely much more code overall, are added waste.

vlovich123 2y ago

And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.

immibis 2y ago
This is the extreme end of the static checking spectrum - so extreme that you can spend hours or days per line of code, and it's so slow that about five people in the world do it on production code (and their customers pay handsomely for knowing it has been checked this way).
- vlovich123 2y ago
  Sure. But even there you start with an understanding of how you want to solve the problem and then spend all your time writing the proof in a way that the computer can prove that you have indeed solved it correctly. At all times you generally start with an idea of a solution - you might prototype stuff to test out different solutions and how you like them but with things that are less pure R&D you need to prototype less.

tsimionescu 2y ago

TDD in this sense of building a test suite before ever having working code, or even worse, the style of TDD that Uncle Bob presents in his book, where you write some test code, then some production code to make the test pass, then some more test code, then some more production code etc. is a fantasy and/or a disaster. Especially if we're talking at the level of unit testing: unless you have a very clear outline of the code that you're going to write, and unless the problem is very well specified, you'll throw away 90% of the tests you've written as your code evolves, wasting inordinate amounts of time in the process. Regular static typing (assuming you don't go to the level of dependent types or something) has the advantage that it is extremely quick to write, compared to an equivalent test. So even if you get the types wrong 90% of the time on the first pass, you've still wasted only a trivial amount of time (consider how long it takes to write "int foo(int x)" versus tests that fail if "foo(x)" accepts anything except an int, or returns anything except an int for any int input - and how much work you'd throw away if you later realize you have to replace int with string).

pydry 2y ago
>unless the problem is very well specified Why wouldnt you decide what your code should do before writing it?
- jstanley 2y ago
  Why wouldn't you just get everything right the first time and never need to learn anything new?
  - pydry 2y ago
    Getting everything right the first time != deciding what you're trying to achieve before you write the code to achieve it.
    - tsimionescu 2y ago
      If you write unit tests for what you're trying to achieve, and then after you achieve it it turns out you didn't get everything right and the code was supposed to do something different, then those unit tests were almost pure waste: you have tests that assert your code is doing the wrong thing (which you thought was the right thing intially). So not only is the code wasted, the unit tests that tested it, which are likely much more code overall, are added waste.