[jghn]

> But I also think it's clear that tool design impacts quality, safety, and efficiency

Yes, to an extent. And it's also the case that it usually doesn't matter. And that's my point.

I have also been someone like GP poster who has declared that it's physically impossible to produce valid software with XYZ tool in a team environment. And yet, there are oodles and oodles of counterexamples in the real world that proved me wrong and it worked AOK for them.

Could they all have been better off using another tool? Hypothetically yes. But their business needs (or whatever) were met and thus disproves a claim it can't be done.

[OutOfHere]

Business needs can be met in the short term only so long as the original developer of the project stays in the team. As soon as they leave, when excellent type definitions and annotations are missing, the project terminates because it's simply unmaintainable. I have seen this happen countless times. In other words, the deliverable will in the short term fool many clients who don't know better, but it is ultimately a scam.

[fc417fc802]

You're saying two different things there.

> it usually doesn't matter

This is what I'm disagreeing with. I can hammer a nail with a rock well enough in a pinch but extrapolating from that to "it doesn't matter if we save some cash by equipping our carpenters with rocks instead of hammers" is obviously wrong.

There's a whole continuum of less extreme examples of the same principle. The quality and purpose fit of your tools absolutely does matter but in the case of programming languages it's a bunch of nontrivial tradeoffs that vary from one project to the next so it's all quite fuzzy.

[jghn]

> I can hammer a nail with a rock well enough in a pinch

The original post to which I responded said "it's disastrous for code that requires development by a team". Anyone claiming that using Python in a production environment is "disastrous", or equivalent to hitting a nail with a rock, is being obtuse. It has and continues to happen all the time with no notable ill effects. It's not like these teams are using Brainfuck here, Python is one of the most mainstream languages in the world, and I don't think I need a cite to make the claim that many, many teams manage just fine with it.

When I said "it usually doesn't matter", i'm talking in terms of the most important metric for a team: are the business goals being met i na timely and cost efficient manner. And my experience has been that as much as I've been a zealot in the past claiming that this tool or that tool can't possibly achieve useful results, teams that do use those tools still manage to achieve their business goals. Meanwhile I could also look around and find plenty of teams using whatever the flavor of the week "ideal" tool is and find teams that aren't meeting their goals.

Now, in an absolute objective sense, is it true that some tools are better fit for some purposes than others? Of course. Is it true that some languages lend themselves to robust coding practices than others? Of course. But the world's not a vacuum, and one must do the calculus at a higher level because as I said, the most important metric for a development team is achieving business goals. Would adopting tool A over tool B (for any A, B) improve the business? That's when these questions get a lot murkier, and the relative advantages & disadvantages tend to drop into the "noise" category.

[fc417fc802]

I agree with you that it clearly works well enough in practice and I agree with you that it's murky - specifically I believe that there are substantial upsides provided by the language and its ecosystem.

> It has and continues to happen all the time with no notable ill effects.

But that statement of yours is patently false. The ill effects of duck typing and extreme flexibility in the face of massive code bases and large teams are incredibly well documented at this point. Literally the entire driving force behind typescript is directly analogous to the situation in the python world.

You might as well claim that concurrent programming in C or manual memory management have no notable ill effects. Even if there are places where you think they make more sense clearly they bring lots of fairly serious issues along for the ride.

[jghn]

We're using different metrics here.

Can it cause bugs? Yes. Do teams ship production code that meet their business goals? Also yes. The former doesn't necessarily preclude the latter. And as long as the business keeps on trucking along, complaining about the bugs and headaches is just a matter of engineering sensibilities. Which I agree with fully and grind my teeth every time.

If the business proceeds along just fine, having the perfect temple of dependently typed, category theoried, memory checked, fuzz tested software may have turned out to just be a waste of money.

If, on the other hand, the business does not proceed along just fine because the team can't get anything done due to not being able to understand that a float probably shouldn't go into a variable that's supposed to be a string, then yes, you're right.