> I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execu

> I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite. Yes, this is exactly what I meant. Well, I was really arguing for both, static and strong typing, although my argument concentrated more on the "static" part, as that gives you safety and correctness guarantees that cannot be achieved with assertions and unit testing at all. > A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent. I relied on type inference a lot when writing OCaml code. However, I noticed that on some places I still want explicit types. (I just don't want to be forced to type them on every variable.) For example, on most function definitions an explicit type helps a lot. Otherwise, the compiler can only tell you that your function call doesn't match your function - but can't tell you whether your function is wrong, or the code using it. With an explicit typing of the function, you know exactly which side is wrong. Also, in case it is the function, you'll note this when writing the function, not later on when trying to use it.