Compiler Errors Are Your Friends
Compiler Errors Are Your FriendsIf you practise XP in a compiled, statically typed language, when you practise refactoring, you get used to seeing a lot of error messages. But you don't mind! It's extremely helpful. SmalltalkLanguage and DynamicTyping afficianados seem to find it depressing. I find it very useful to have a search mechanism that systematically locates type errors for me in a single pass.
An alternative, controversial, view: the PersonalSoftwareProcess thinks programmers rely on compiler errors too much. It encourages them to enter a dialogue with the compiler to come up with a correct program, rather than put their brain into gear and write the program right the first time. Result? Lower code quality because the programmer introduces bugs the compiler doesnt find, reduced 'flow', 'coders' never learn to be 'engineers', and time to delivery increases. The proposed alternative is not to remove compiler errors, but rather create a culture where the coder will have written code they believe to be correct before they hit that compile button.
The PSP book has a lot of statistics about the practice and results of this approach, worth reading to appreciate the argument.
Don't get too pally with the compiler, though. We just spent a couple of days dealing with around 150 Lint complaints in a body of native code we inherited that compiled cleanly on VC++6 and gcc.
Lint can complain about things like unused return values, which causes people to put (void) infront of calls like printf(). I find this annoying as it obscures the code. I do agree that CompilerErrorsAreYourFriends but you also have to KnowYourCompiler?. With VC++ I find that setting warnings to maximum level causes lots of errors in the standard header files, which reduces its usefulness somewhat.
Modern Lints are highly configurable. With the one we use, we can, and do, do things like turn off warnings we consider spurious for a particular symbol. It would be easy to turn off the kind of warning you mention for printf(), for example, if we compiled anything that called printf().
The name of this topic should be CompilerErrorMessagesAreYourFriends?. Buggy compilers are not friendly at all. [CompilerBug]
The compiler's type checker may be our friend, but what kind of friend is it really? Is it worth cultivating the relationship? What can we expect of the friendship when things get really complicated? I ask this because I suspect we regularly invest more effort into the type checker than it saves us in return.
This is because the type checker is really dumb. It's ok for computer systems to be dumb sometimes: that way we know what they do without thinking too hard ourselves. But when we rely on a dumb system too much we will find that we have to think really hard to get the dumb system to give us the right answer. That is, with dumb systems, we quickly experience diminishing returns.
We ask the type checker to reason about our programs so that we can reason less ourselves. We invest the time it takes to explain our programs to the type checker (by making type declarations) because it then repeats the reasoning every run and alert us whenever the reasoning doesn't wash. Sounds good so far, but ...
How much confidence do you want? Is there any way the type checker can give it all to you? How hard are you going to have to work to make it so? And, can you get that confidence cheaper somewhere else? I think so. -- WardCunningham
Along similar lines: DavidThomasOnTheBenefitsOfDynamicTyping
BondageAndDisciplineLanguages anyone?
Maybe a codependent relationship with the compiler... with S&M thrown in?
See StaticTypeSafety, DesignByContractAssertionsVsUnitTestsVsTypes, StrictTypingIsaTest, TheoryOfLanguageEnvironmentSuckage, WhenIsManifestTypingConsideredaGoodThing, BenefitsOfDynamicTyping, UseTheStaticTyping
EditText of this page
(last edited July 20, 2004)
or FindPage with title or text search