Helping The Compiler

Some feel that HelpingTheCompilerIsEvil (this page is intended as a ReFactoring/expansion of that one). Examples are given of different ways one helps the compiler, and it is claimed therein that languages which require lots of help from users are thereby poorly-designed.

'Note that, at most, this page is about language design. Nowhere is it argued that one should refrain from "helping the compiler" if the language doesn't do the same work itself.

But what is helping the compiler? Here is a proposed definition:

That definition doesn't hold up. Consider practices such as comments or good variables names. They aren't necessary to solve any problem, but they make the code easier to read and maintain. I'd consider them to be HelpingTheCoder?, not HelpingTheCompiler.

[Note that "compiler" here also includes interpreters, VirtualMachines, and other tools.]

In many cases, it's things that could be removed from the program without changing its correctness. For example, the "const" keyword. If you take a correct C++ program and AvoidConstCompletely (stripping out practically every reference to "const"), you'll still have a valid C++ program that does the same thing (I'm sure I will now be provided with a counter-example - I'll head off one set of counter-examples at the pass by excluding anything that contains functions overloaded based on const-ness). OTOH, type annotations are also examples of HelpingTheCompiler, and C++ won't let you remove those.

Using the terminology of FredBrooks; HelpingTheCompiler is the specification of "accidents" rather than the specification of "essence". An ideal language would require no accidents to be specified, as accidents add complexity and increase the possibility of error.

Are you saying that all programs in this ideal language would not specify any accidents? Or are you saying that an ideal language, such specification would always be optional?

Some programming languages require help in order to compile; others may make it optional; still others may ignore or reject any help you provide. Java won't compile if you don't provide type annotations. Languages such as CommonLisp and MlLanguage don't require them (the former uses DynamicTyping, the latter TypeInference); but you can specify type annotations if you want, and the language will often check them for you. SmalltalkLanguage has no way to specify the types of terms - you could write type assertions, I suppose, and scatter them around a Smalltalk program; but the language will not accord these any special treatment.

Examples of HelpingTheCompiler include:

Reasons that HelpingTheCompilerIsEvil, according to various WikiZens:

Reasons that HelpingTheCompilerIsGood?:

Very bad definition. For example, many good programmers in Haskell and Ml write the type specification even if TypeInference is good enough in those languages to allow them not to. The reason is that types are not really intended to help the compiler; when they do that, they do it merely as a side effect.

Agreed somewhat; information that has benefit to the compiler frequently has benefit to programmers as well. 'Tis discussed above. On the other hand, it can often get in the way - many languages with StaticTyping are crippled by rather weak type systems. Java is the most notorious example, though 1.5 ought to fix much of that. Type systems that force CutAndPastePolymorphism? are a key aspect of BondageAndDiscipline.

The main things types were intended for is to help the programmer and the reader think clearly rather than fuzzy. That's the whole point that ranters against static typing keep missing, therefore all this handwaving and dismissive rhetoric about HelpingTheCompiler has precious little value or insight.

In any OO language, types play a much greater role than "helping the programmer think clearly rather than fuzzy". DynamicDispatch simply wouldn't work without some notion of "type", though you could use PrototypeBasedProgramming and have it such that every object is of a type unto itself. Useful in some circumstances, though certainly not all the time. I'm not an advocate of DynamicTyping everywhere. On the other hand, the maintenance of types is frequently little more than bookkeeping; the sort of task that is better left to computers rather than humans. I know that there is an old school of thought (spanning many disciplines, well beyond computer science) that bookkeeping and dabbling-in-details is good for you. I don't subscribe to that school of thought universally (though in circumstances I'm inclined to agree). But when the goal is to produce software on a schedule and a budget, I'm for letting the computer worry about the details.

I'm all for FlexibleTyping?, or SoftTyping, myself. If you want to specify types, go ahead. If you want the computer to figure it out for you, it will happily do so.

As JFK said, or rather the opposite thereof: ask not what you can do for your compiler, ask what your compiler can do for you! I don't care as much about my compiler (javac, hence) optimizing my code, as much as I like the fact that it helps me write better code, by typechecking it. I want typechecks! - WouterLievens?


View edit of December 19, 2013 or FindPage with title or text search