I’d like to read the opinion of experts on whether compiled, strictly-typed languages help programmers write robust code easier, having their backs, checking for type mismatches, and in general, catching flaws in compile time that otherwise would be discovered in runtime ?

For some programs they do.
For some programs they require you to do things that are not really necessary to enable static checks that don’t catch anything.

Experts have no consensus. Personally, I favor traditional statically typed languages for most things.

Has unit testing in loosely typed, interpreted languages need to be more thorough because test cases need to assess things that in a compiled languages wouldn’t simply compile ?

Not necessarily. The general consensus is that unit tests are the quickest and easiest way to do that, but there is some debate if you need any more unit tests to effectively catch those errors or if the normal tests you’d write to test the functionality would catch it.

Need the programer in compiled, strictly-typed need to write less code since he/she doesn’t have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

If you’re doing instanceof in dynamic languages, that is a code smell (imo). So if you consider type annotations, type declarations, or variable declarations to be ‘code’ then yes, you’ll naturally write more code to do the overhead. If not, then it is debatable.

The main thing is that it is never so clear cut. Tooling is generally easier for statically typed languages. Type annotations help readability of code (so some argue). Not having type annotations helps readability of code (so some argue). There’s no good quantitative measurement to help. No consensus.

Yes, type-safety leads to more robust code. But at what cost?

You never find every bug in testing. The earlier you find a bug, the cheaper it is to fix (fewer people involved, less communication, etc). The cheapest way to fix a bug is to have your language or compiler prevent it from happening.

I had a client who had a standing bet for over a year, offering a free hamburger for finding an actual bug in my code. Type safety helped make that possible.

In general, compilers or languages preventing bugs is a good thing, but it can be taken to an extreme. XSLT does not allow you to update the value of a variable. As a result, you have to use recursion to make a simple loop (I’m writing this in pig-java/pig-C because XSLT has awful syntax which I fail to remember):

function sumList(x) {
    if (x.length > 1) {
        return sumList(x.tail) + x.head;
    } else {
        return x.head;
    }
}

There are benefits to this approach (few side effects), but this also forces fragmentation on the code where all kinds of things were broken off into separate little functions. It was difficult to avoid doing things multiple times, and this led to all kinds of other bugs and slow performance that were worse than accidentally changing the value of a variable.

Back to type safety. Usually, if I have a function washFabric(Fabric f) and I pass it a Cat instead of a Fabric, this is a simple error on my part. When you have this hidden in layers of function calls, such a mistake is very easy to make and hard to test for. When my code compiles in a type-safe language, I know I didn’t make this kind of error. For this reason, I find type-safety a good trade-off between speed of slapping something together that works, and being sure it won’t break.

Type safety does slow you down. In Ruby or perl, you can create a wash(f) method and throw a cat in the wash and either the cat comes out clean, or dead, or still dirty. But in Java, you have to create a Washable interface and painstakingly define methods like soak(), addSoap(), agitate(), spin() and rinse() and think about what it means to be washable so that someone making a Cat class can study the Washable interface and decide whether a cat should be Washable or not. That takes a lot of time and effort.

If you want a one-time use report written in an hour, then type safety will just slow you down. But if you have a bunch of programmers working on a huge system that will last for years and has to be very fault tolerant, then you can pry type safety from my cold dead hands. 🙂

Need the programer in compiled, strictly-typed need to write less code since he/she doesn’t have to constantly check for correct types ( instance of operator ) since the compiler catches those things ( the same applying to misspelled variable names or uninitiated variables ) ?

I write almost exclusively in dynamically typed languages, and I almost never have to check for correct types. First, the program will throw a type or no method error if I use the wrong type somewhere, and second, I tend to use the types I intend to use where I intend to use them.

An edit on that first point based on a comment below: yes, the program will throw that error “at runtime”. But since I run portions of the program easily as often as I would compile in a statically typed language (possibly more often), this isn’t particularly relevant. “Runtime” doesn’t mean “production”, it means “when I run my unit tests”. When I run my unit tests, if I am calling a method that doesn’t exist on a type, I’ll get a no method error.

While it is true that people make mistakes and sometimes write code that divides a char by an array, this is less common than you would think. Most code is fairly type safe by design… if it weren’t mostly type consistent, it wouldn’t work and wouldn’t pass its unit tests.

Similarly, in my experience, unit testing doesn’t need to be any more thorough in say, Ruby than it does in Java… I use unit testing to test the behavior of methods and classes, not for type checking. The type checking is implicit… type mismatches throw errors that indicate errors in my code that should be solved by better code, not by adding type checks.

A further edit based on another comment — no, my unit testing does not have to be more extensive and I do not have to write more code to make sure I didn’t misspell a variable name inside a nested conditional.

If I needed a variable to change values based on some logic branch and it doesn’t because I accidentally declared a new variable, I’ll catch that while unit testing behavior, not unit testing variable names and type checking. I would write the same unit test in a static-explicit language, and while I might get a compile error instead of a failed test the end result is the same: I’ll see the mistake and fix the code when I run the unit test that is checking that I get the right behavior, not that I’m using the right types and variables.

If I am writing code where that kind of mistake could slip through my unit tests, my problem is not that I’m using a dynamic-implicit language, it’s that I’m writing bad code with untracked side-effects. Using a static-explicit language isn’t going to help me there, it’s just going to give me a false sense of security about my bad code.