My point is that type errors can be syntax errors, runtime errors, or logic errors depending on the language being used. Types errors and syntax errors aren’t mutually exclusive and how much they overlap depends on the language being used.
The argument in my original post is based on the idea that it is better to find out about errors early instead of late. It is also better to get more information about them instead of less. Given this rule, syntax errors are the best type of error as the compiler will always find them and tell you about them immediately with a message that typically includes line numbers of other useful information. As a result, these bugs are found quickly and can generally be fixed quickly. Runtime errors wait until the code is run to manifest, but they typically crash a program with some type of message that again varies by language so you get some information. Logic errors just suck to debug because you have to notice that things are off in execution and then figure out why with minimal information.
So take my example error of obj.result instead of obj.results. In a statically typed language, most of the type errors, including this one, are syntax errors that you find out about immediately as they are reported by the compiler. In JavaScript, this could be a runtime error or a logic error, depending on what is happening with that value as JavaScript will happily give you an undefined for fields that don’t exist and the problem only manifests when you use that undefined for something. If that typo occurs in some code that is rarely executed you might never find it during normal usage and it could easily skip through testing. Even in the best case, you aren’t going to be told about your typo quickly. You have to run your program and execute it or perhaps you have a call in your test suite that will trip this. The key though is that you find out about it much later.
Yes, there are third-party tools that can find things like this earlier, but I would argue such things exist because they are filling a gap left by the original language. Basically, developers using that language realized that it wasn’t ideal and they needed something else to help them be productive in it, hence the tool was created. Why not just start with a language that does those things in the first place so you don’t need third-party tools to fill in the gaps? I would argue that statically typed languages with type inference are as expressive as scripting languages and as quick to write code in and also reduce development time in the long run because they tell you about your errors earlier.
