How many times has six-months-hence you cursed you for this attitude?

Be honest.

So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Don't Need Guardrails. And, TBH, I see a lot of people who are the latter and very few who are the former--and most of that very few tend towards statically or at least optionally typed languages by default. So forgive me if I don't believe you.

Will you in two years? Will your coworkers? Will the contractor who has no context for the code understand it?

Like variable names, types convey information that are crucial to the understanding of your application.

Under the hood, there are "types", even if they are weak, so you'll need to know about implicit typing anyway. Making them explicit is both a way to test correctness and a way to document your code.

Meanwhile: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

'Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.'

And this is not just Microsoft–it's a pretty consistent finding across industry, that when programming in C/C++, memory safety issues make up around 65% to 70% of all issues.

What this tells us is that people in general can't guarantee the safety of their code, but an automated checker can.

And I suppose when those requirements never changed you never had to rewrite lots of these perfect functions or resort to “append only” programming in order to make sure regression was impossible instead of making large changes in place.

Forgive me, but it’s clear you have never worked on a program of any consequence, so it’s hard to read your comment and do anything but wish you the best while also completely ignoring its content.

It's like trying to convince experienced motorcyclists that you don't need a helmet because you're quite the driver. It's just defensive driving, people! That the helmet is some sort of crutch you've transcended, and maybe if everyone had a bit more skill -- like yourself -- they'd understand.

Yet it always seems to be half of the dynamically- vs statically-typed language debate.

That sounds fine, as long as no-one else will ever have to read or work on your code.

On these projects you often find yourself needing to work on higher levels of abstraction. Types help here by instantly telling you what the data is and providing hints.

Types take extra time to write and maintain, but they significantly reduce the difficulty of working on large projects.

Can you say the same about all your dependencies?

I and most people however are human and make mistakes sometimes. Worse, the bigger the project, the more you need to collaborate between people and sometimes teams. Types are almost like docs that check your code at compile time and reduce the chances of human error creating a production failure. Its not a panacea but its certainly nice to know that if I change a functions parameter, that the system breaks someone else's code depends on that function following a certain signature. At that point, I can either write a different function, message him to update his code or discuss how to make the changes together. All 3 cases are MASSIVE upgrades over fiding out shit broke in prod with some undefined behavior arising.

The only perfect decision I made is to accept that I make imperfect decisions, I wish I could attain the consistent perfection that you describe here.