Death and Taxes: Compilation, Type, and Test
Jeff Atwood has complained about the "compilation tax" that he must pay with C#, contrasting it with Visual Basic's background compilation. It's utterly absurd that when we program, the most sophisticated, well-studied, computational task that is common, we are essentially typing into a text buffer. (At least IntelliSense / method completion keeps the CPU warm.)
Similarly, fans of dynamic languages often complain about the "finger typing" of explicit type declarations, saying that the effort of capturing their type intention is enough to break them from the zone of high productivity.
And yet: unit testing.
Since it's been more than a decade since the \<a href="http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612"" target="_blank" rel="noopener noreferrer">Gang of Four, I have no hesitation in asserting that unit testing is the signal "best practice" of the past decade. One develops, side-by-side with progress-towards-user-value, a considerable body of code that exists to confirm / demonstrate / validate that progress. Writing unit-testing code takes significant time -- well spent, but significant. And the time needed to run a test suite absolutely dwarfs compile time. The question with taxes is what do you get in exchange? The "test tax" gives tremendous benefits and I don't hesitate to pay it, even though it is the heftiest of all. The "typing tax" is one that I find worthwhile in larger projects, although others disagree. The "compilation tax" though, provides very little.
People talk about background compilation and errors popping up before you're done with your thought and so forth, but that's a UI issue, not a technology issue. Don't show errors until you type "Ctrl-F5" but then show them instantly -- that's okay by me. And I don't see any reason why you can't achieve that UI. Compilation typically consists of three phases: parsing the text into an "abstract syntax tree," transforming that tree for efficiency, and emitting code representing the transformed tree. Obviously, that's a pretty big benefit and a hard computational task, but the thing is: you have to do at least the first phase for IntelliSense and while continuous transformation might consume memory, at least it keeps my other 2-, 4-, 8- cores busy.
I hate the compilation tax not because it's costly, but because it's inelegant.