First, my background: I am seeking my Master's degree in Computer Science after procuring a Bachelor's in the same field. I have worked in the IT industry as a "consultant" (glorified sysadmin) and also as a student aid (grader) and researcher (kernel hacker) while pursuing my education--that is, I tend to work more than I attend school and am entering my eighth year of higher education. That is all to say I have never worked in "industry" as a programmer, only in acadamia as a programmer, but I have done some light programming in conjunction with administration.
This means that I have had it hammered into my head by professors for the last 6 years or so that I've been taking classes in my subject that static checking (often referred to has "type checking") is the most important aspect (or one of the most important aspects) of a computer language. However, I've always been a bit skeptical of this view since static checking only buys a couple minor things while robbing you blind of many things.
I even took a class on static checking which was wrapped tightly around Pierce's text Types and Programming Languages. One of the major bits of this text is it's creation of a mini-Java language (FJ), which is provably type-safe. However, the proof uses a hack to make sure that downcasts (e.g., casting from Object to anything else) is actually "safe". Therefore, I've begun to reach the opinion that "there is no free lunch" when it comes to static checking. Static checking only guarantees that our programs are sort-of-kind-of safe so long as we're careful and the exception handling system is leveraged properly. In Java, in particular, you can throw type safety completely away by introducing any code using reflection, but it is a necessity in some areas--try writing a J2EE container without reflection!
Simply guaranteeing that a function returns an int when it claims to does not come anywhere close to guaranteeing that it is the right value (woo-hoo, I've limited the number of results to 4-billion!). Don't misunderstand me as saying static checking is utterly worthless, but simply contemplating it's real value as opposed to what I percieve as the inflated value given to it by some in the language community.
My question to the monks is, how much does static checking buy us and is it really worth the bother at all? Is static checking worth the limitations imposed upon expressiveness? If so, where and why? How useful is static checking in industry (various industries)? I know it's useful for catching typos (so that something like When -w and use strict aren't enough... doesn't happen), but isn't proper testing a much better road to proving the correctness of code? So often, it seems like programmers--especially ones who are susceptible "false laziness"--gain a false sense of security in static checking. (How many of us GTAs have run into early undergrads who say at a low grade on a homework, "But it works, it compiles doesn't it?" Or heck, we're in a hurry to turn something in ourselves, made a small change we know will work, compile it and find out later was totally broken because we skipped actual testing.)
Anyway, since Perl's static checking is limited by it's expressiveness and is turned off by default, I was looking for a Perlish answer (along with any other perspective of this diverse community)..
In reply to Static checking by hanenkamp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |