> which can be equally dangerous

Bash is weakly typed, which is a different concept than dynamic typing.

Dynamically typed languages prevent bugs that weakly typed languages don't, so from this point of view, the latter are unambiguously "more dangerous" than the former.

A dynamic type system is an incremental improvement over a weakly typed type system, and still will not guard against runtime errors. They are equally dangerous w.r.t runtime errors.

Not that I endorse the “equally dangerous” comment, but if you're interested in configuration management with a language based around a powerful static type system, may I note the existence of Propellor? https://propellor.branchable.com/

The concept of "guard against runtime errors" doesn't make much sense.

Technically speaking, even languages with strong safeguards (random examples: Golang, Rust) can't "guard against runtime errors", because it's possible to panic a program by performing an out-of-bounds array access (which classifies as "runtime error" in a very strict sense).

A concept that makes sense is the amount of safeguards provided by a language (/type system), however, this depends entirely on the use case; it's an intentional choice of the developer.

It gives you the option to use static typing, if you so desire.

I'm not sure how not having a type system is safer than having a type system. What makes it feel more dangerous?

When talking about Python in 2020 i think most people imply you are running Mypy, which does a very good job at statically analyzing python almost to strongly typed language level. Plus, as others said, weak and dynamic are not same thing.

So does Bash, though.

And Bash does not support static typing at all, unlike Python. Not sure what their argument even is.

Python doesn't support static typing either unless you're using mypy which is experimental. Bash and Python both however have strong types, although Bash's are weaker than Python's.

Right, but Python gives you the illusion of safety. And the person I was replying to was trying to dismiss this interesting Ansible alternative because it was written in a language he doesn’t like.

Python with type annotations can actually be pretty safe. There are also typechecked Python variants being developed. At any rate, I’d say the defect rate in Bash is incredibly higher than it is in Python, and 90% of that is due to unquoted string expansion. Try putting spaces in your paths and you’ll quickly see how 75% of the Unix stack breaks.

Somehow that is not a real problem in practice. Maybe whitespace is not needed in paths that much. If a need to store a random byte string in a file name appears once in a year, one can encode it into hexadecimal or base64 with % replacing /.

That's sort of like saying, lack of pointer safety is not a real problem in practice. Yes, you can work around it, but when it's a problem for production systems dealing with sensitive or untrusted data it's a huge problem.

I don't see how the two compare. As a programmer, you need pointers for dynamic allocation. You don't need to use whitespace in paths, ever. It is a convenience for the user.

Whitespace in paths occur, similar to how buffer overflows occur. It's the job of the programmer to understand this and guard against it; but many don't. And all you need is one bash script that does something like this

  rm -rf $path

to go from working one day to having deleted an entire directory tree just because someone named their file

  "foo ."