Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U

My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)

The top comment on that video, in light of the points being made in this thread, is quite ironic:

"And because of this 'improved safety' we have millions of drivers out there who drive even faster and take even more risks, because they think the new cars are so much safer. "

(of course this comment is silly, the number of motor vehicle deaths per capita is about a third of what it was 50 years ago: https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_i...)

This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system.

Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.

You just reminded me of my old driving instructor.

"All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless."

The line between empowerment and victim blaming is surprisingly thin. ;)

That was cool!

I agree with both, really. Those defects are our fault, and they are there because we aren't careful enough with the code we write. We know about these things, and yet, we don't work to prevent them. We either handwave them away, or we give into management pressures to just get the thing out the door.

Now, that said, one of the ways you can work to prevent these things is to use better tools. Like languages that don't let you make those kinds of mistakes as easily.

I can see how that would be popular but it's wrong.

You can take that same reasoning and say we should build web projects in C or assembly because any defects are our own fault.

Let's be honest. That's bollocks. It's just the same old "real programmers use X" line. I'm sure there's an XKCD that parodies it.

Sure we need more discipline. Who doesn't? Yet that discipline is far better spent on doing what the compiler can't. It makes no sense doing what a computer can do unless it's really necessary. That's why we're programmers after all, right?

Using C as an example is a straw man. There's been A LOT of progress since C. Can you say the same for Java or Python? Not as much.

No it's not. It's the same argument we've had about any kind of progress in programming languages since we started using higher level languages (I.e Fortran and up).

He didn't condemn Kotlin and swift. He is saying that they aren't necessary and don't solve the original problem. That the constant search for a new framework or of language that will fix everything is a futile attempt to avoid learning how to more effectively code with the tools you already have.

In one of the linked posts he says that 100% test coverage might not be truly achievable, but it's nonetheless a valid asymptote to aspire to.

I think that exact argument applies to designing ever-safer, ever-better languages. You might never have the perfect tools that ensure 100% program correctness, but it's sure as hell what a tool-maker should aspire to.

His argument mostly makes sense up to the point where he says tests are the only solution... Why not default to overriding the safeties, then use them where your reasoning says they ought to hold? Cheaper than writing a bunch of tests just to guard against null pointers.

Personally I’d prefer my language to let me fuck up.

> Personally I’d prefer my language to let me fuck up.

And as a (completely hypothetical) competitor of yours, I would support you using a language that encourages you to fuck up frequently.

There is a difference between letting you and encouraging you to fuck up. I have given Rust a go, but its tricky to understand, and that seems like a language designed not to let you fuck up.

y tho. you can have safety and expressivity...

it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.

What strongly typed static languages are you talking about?

> proving to the compiler that this thing is actually compatible with that thing

I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing.

Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development.

What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code.

This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one.

And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.

As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).

> proving to the test suite and proving to your teammates that this thing is actually compatible with that thing.

I really don't know where that canard comes from. My test suites rarely if ever explicitly test compatibility.

They test for specific values: if I do this and that, do I get the value that I expect. The type "test" gets covered implicitly, because if it's not the correct type, it will also not be the correct value.

The problem is that without knowing the type in question you don't know the values you're testing with cover all of the possible cases. When interfacing with an external dynamically-typed function this requires attempting to reverse-engineer the types from the definition (and recursively for all the functions it calls).