> Which in at least some cases means ignoring bugs

Indeed, but simplicity is the name of the game for exploratory programming. It's difficult to explore using languages requiring a lot of ceremony.

But then, that's when the time and funding constraints come in and prevent rewriting in more type sound languages. Which is why we end up with buggy python (if speed not an issue) or buggy C (if speed is an issue).

There are alternate paths. For example, APL tries to be terse enough that you can have the whole thing on a single screen. That's another attempt at bug prevention.

For example, I do my data wrangling in J.

> languages requiring a lot of ceremony

Some statically-typed languages don't require a lot of ceremony.

Is it a bug if it never happens? Another way to say it, would you pay money to prevent a problem you don’t have?

> Is it a bug if it never happens? Another way to say it, would you pay money to prevent a problem you don’t have?

Let me rephrase that: Is it a bug if I don't know about it? Another way to say it, would you pay money to prevent a problem you're not (yet) aware of?

Saying the bugs "never happen" is basically saying "I always write bug-free code."

I feel languages that don't have type checking (or where it's sloppy), force developers perform semi-automated testing (i.e. unit tests to catch type issues) when they could have systematic, fully-automated testing (for type issues, at least)

Right, but some people are doing data wrangling by themselves with python in a jupyter notebook. These aren’t production systems, and static type checking slows you down without adding much value.

That’s all I’m saying, the data analyst that has some edge case “bug” that never gets executed probably shouldn’t pay the upfront overhead cost of type checking.

Is having buggy, unused code lying around a good thing?

It’s not always bad, and dealing with it has a cost. The cost is not always worth. It may be worth it most of the time, but not always.