Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

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 ?

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 ) ?

NOTE: by strictly typed language I mean languages that force you to declare variables and assign a type to them in order to be able to use them, and once a variable is declared, you cannot change its type or assign incompatible type values.

int myInt = 0;
String myString = "";
myInt = myString; // this will not fly in a strictly typed language
myInte = 10;   // neither will this ( myInte variable doesn't exist )
share|improve this question
8  
This question doesn't make sense. There is no such thing as a compiled language or an interpreted language. Compilation or interpretation are traits of, well, the compiler or the interpreter, not the language. A language is a set of abstract mathematical rules. Languages aren't compiled or interpreted, they just are. Every language can be implemented with a compiler, and every language can be implemented with an interpreter. The vast majority of languages have both compiled and interpreted implementations, for example there are interpreters for C and C++ and all currently existing … –  Jörg W Mittag Aug 22 '12 at 1:29
1  
… PHP, Perl, Python and ECMAScript implementations as well as most Ruby implementations have compilers. Also, the terms "strictly-typed" and "loosely-typed" are not defined. It's impossible to answer your question without you giving a precise and unambiguous definition of those two terms, otherwise this is just going to devolve into yet another meaningless typing flamewar. –  Jörg W Mittag Aug 22 '12 at 1:31
17  
You guys are being pedantic. It's a perfectly answerable question if you don't read too much into it. –  Karl Bielefeldt Aug 22 '12 at 1:46
4  
@Izkata: again, there is no definition of loosely-typed or strictly-typed. If you want to know whether C is strictly-typed, then you have to first tell me what strictly-typed means. There are about 20 different definitions of those terms floating around, most of them contradict each other, some are even opposites of each other. In serious literature written by people who actually understand something about type systems, those terms aren't used at all because they are completely and utterly worthless, since they don't have a agreed-upon definition. Just in this very discussion thread … –  Jörg W Mittag Aug 22 '12 at 3:01
2  
… I count at least three different incompatible definitions. –  Jörg W Mittag Aug 22 '12 at 3:02
show 9 more comments

closed as not constructive by gnat, ChrisF Aug 22 '12 at 21:08

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

up vote 9 down vote accepted

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.

share|improve this answer
add comment

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. :-)

share|improve this answer
    
Using recursion instead of loops is absolutely normal in functional programming languages and the inability to change variables something their proponents consider a great advantage. The funny thing is that the same people would probably rather chew off their own arms than use XSLT. –  Michael Borgwardt Aug 22 '12 at 19:21
    
Hmm... chew off my own arm or use XSLT... Tough choice... –  GlenPeterson Aug 23 '12 at 12:15
    
I had to use XSLT as a general purpose language for several years. I enjoyed the challenge, but it was totally impractical. Functional programming and immutability are great things. But a local "variable" is a wonderful thing too. Scala gives you both, and I need to spend more time learning it. –  GlenPeterson Aug 23 '12 at 12:23
add comment

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.

share|improve this answer
2  
First, the program will throw a type or no method error if I use the wrong type somewhere. At runtime. I tend to use the types I intend to use where I intend to use them. Most teamworks have several programmers, and people make errors –  user61852 Aug 22 '12 at 10:15
3  
With at runtime I didn't mean production, it's just that you have to run the code to ( hopefuly ) find the error. Maybe type mismatches are not common, but misspelled variable names really are. A weak language will assume it is a new variable. This can hide for long time inside a nested condition, and bugs arising for this are usually silent and difficult to debug. Strict languages would shout it aloud upfront. –  user61852 Aug 22 '12 at 14:36
1  
@user1598390, you are conflating weak and dynamic typing. Languages like Python which are dynamic and strong will not create new variables if you misspell them, they will raise an error. –  Winston Ewert Aug 22 '12 at 17:24
2  
Having to compile the code and having to run the code are essentially equivalent from my point of view. A compiler checks every nook and crany of the code, whithout it you have to run the code with different values in order to ensure you have full coverage. –  user61852 Aug 22 '12 at 17:59
1  
@user1598390 A compiler checks every nook and crany of the code yeah except for these non-trivial things called run time errors. –  pllee Aug 22 '12 at 18:20
show 8 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.