> So, it doesn't matter if your code is correct or not?

I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. I honestly don't see the correlation.

> And that leaves more time to design things right and test the stuff that actually matters.

I'm not gonna get into a religious flamewar; if you prefer static typing, all the power to you and I'm not interested in convincing you otherwise.

However, I fail to see how having to write "int", "str", etc before or after a variable name impacts the design process in any way.

As for testing:

- A test in Go:

    func TestAvg(t *testing.T) {
    	for _, tt := range []struct {
    		Nos    []int
    		Result int
    	}{
    		{Nos: []int{2, 4}, Result: 3},
    		{Nos: []int{1, 2, 5}, Result: 2},
    		{Nos: []int{1}, Result: 1},
    		{Nos: []int{}, Result: 0},
    		{Nos: []int{2, -2}, Result: 0},
    	} {
    		if avg := Average(tt.Nos...); avg != tt.Result {
    			t.Fatalf("expected average of %v to be %d, got %d\n", tt.Nos, tt.Result, avg)
    		}
    	}
    }

- The exact same test in python:

    def test_average():
        for param in [
        	{'nos': (2, 4), 'res': 3},
        	{'nos': (1, 2, 5), 'res': 2},
        	{'nos': (1,), 'res': 1},
        	{'nos': (), 'res': 0},
        	{'nos': (2, -2), 'res': 0},
        ]:
            assert average(*param['nos']) == param['res']

In a real situation, tests like this one need to be written and the fact that in Go we're specifying types doesn't change a thing, so I'm not convinced that not writing the types means that in a dynamic language I have to test stuff that doesn't matter. For that matter, I'm having a hard time imagining a scenario where the type wouldn't be tested anyway so back to my "... and?"

But, again, I'm also not trying to convince you otherwise. Different approaches for different folks.

> I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter.

Well, that quote was your entire sentence. It wasn't out of context. So:

> every time the code changes, it would be great if a test somewhere broke

There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.

About the types, their entire point is that they save you from writing the tests. What the compiler proves, you do not test. If your compiler won't prove anything, you'll have to write all the tests.

As an example, you forgot to test if `'nos': ("", None)` yields the correct error.

> As an example, you forgot to test if `'nos': ("", None)` yields the correct error.

It isn't in the go code either.

> There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.

Why, exactly? I'm not following your inference there; again, walk me through that one.

Let me be more explicit: what exactly did you think I meant with that line? Again, I don't see how it implies that "it doesn't matter whether the code is correct".

> About the types, their entire point is that they save you from writing the tests.

Ok, this is getting circular so I'll just ask you to give me an example of a test that would be absolutely required in a dynamic language but not in a static one.

Mind you, that isn't going to convince me one way or another in the "static vs dynamic" flamewar since I subscribe to the idea that more tests is better. I'm asking mostly out of curiosity.