Background compilation and automatic transmissions.

A major feature that VB.NET has that C# is still currently lacking is background compilation.  Background compilation is much like having an automatic transmission, instead of a manual.  The background compilation does the menial task for you.

Traditionally, most folk thing of automatic transmissions as being expensive and less fuel efficient.   The up-front cost in the case of VB has already been paid back in version 2002, now each version comes with the auto as standard with no extra cost.
Fuel efficiency has also improved, as background compilation gets smarter about selecting what parts need to be re-compiled.  Still, in congested traffic, where you have many changing projects in your solution, there will be some processor overhead with background compilation.  

But this is very much like city driving.  It’s that start/stop driving where one really appreciates an auto, allowing you to focus on driving, not stopping to change gear.  And when projects are changing rapidly, you really do need to compile regularly, making the manual compile tedious, and often interfering with your enjoyment of a coffee while you drive J

Out on the highway, the new background compiler in 2005 is finely tuned to the editor, allow greater matching and efficiencies.  This too is very much like the auto industry where the new automatic transmissions can be precisely matched to the engine.  My new car (due at the end of the month) is actually more efficient on the highway than the manual transmission.  This too is much like VB compared to C# in terms of compilation.  C#’s lack of a background compiler means you have to actually stop to change gears!  Stop and save your code.  This requirement that you must physically safe files to see changes, means changes desirable or not, have to be written to hard disk before you can see their full impact.  Here, VB gains in efficiency by re-using the in memory model, adjusting it to changes as you drive.

Of course, there will be some folk who’d rather drive a manual.  Some people prefer to do jobs machines are better suited to do for them.  Me, I’d rather have an auto any day J

10 Comments so far

  1.   Daniel Moth on November 20th, 2004          

    Hmmm… Although I love background compilation in VB and this is probably the only feature I’d love C# to get…I must admit I’d never trade my manual transmission…in other words I don’t find the analogy works that well. For another analogy of manual/automatic check this post out:

  2.   Bill McCarthy on November 20th, 2004          

    Hey Daniel,

    At first I thought it must be an age thing 😉 Over the years I’ve had many cars, auto and manual, and I can tell you quite seriously that it will be autos for me from now on. 🙂

    The newer automatics are much much better these days. As I pointed out, fuel efficiency is just one example. They can also provide faster and more appropriate/fail safe gear changes than a human can. Such as when corning, if a gear change is needed, the destabilizing effects are much less in an auto. New autos also have grade logic control, overdrive, etc.

    In fact, some of the hotest autos now allow semi manual change as well, which is much like having a formula one’s automatic clutch.

  3.   Ian Griffiths on November 24th, 2004          

    But when changing gear in corner, the destablising effects of an auto changing gear when no sane human being would ever have considered a gear change are the worst of all!

    It’s true that the new breed of autos that are essentially manual gearboxes with a conventional clutch, but with everything operated automatically under hyrdaulic control, the transmission losses are no worse than with a manual.

    Claims that the auto is *more* efficient than the manual are a little suspect. If that is the case, then it’s almost certainly simply because the two boxes have different sets of gear ratios – the top gear and final drive ratio have an impact on fuel efficiency, so if you’re getting better mileage out of an auto, that’s likely to be the reason. (Either that, or you’re really bad at selecting the right gear in a manual. 😉 Bear in mind that mileage *does* vary massively according to driving style.)

    But to get back to the point, it always amazes me when VB people make this point – I just don’t understand it. Do you really think that it’s obtrusive? You describe the process as being very cumbersome:

    "you have to actually stop to change gears! Stop and save your code. This requirement that you must physically safe files to see changes,"

    but that’s just because you’ve chosen a cumbersome way to describe it.

    The reality is that I just have to hit Ctrl-Shift-B. I can do that without lifting my hands off the keyboard. It saves all the files for me and compiles them. This is not a slow process. It’s not even remotely disruptive.

  4.   Sahil Malik on November 29th, 2004          

    Why auto when you can manual?

  5.   Dan McKinley on November 30th, 2004          

    Having worked on a very large VB.NET application, I can say it’s definitely not always a good thing. Even on an extremely beefy workstation, big solutions take FOREVER to open and assemblies with a lot of dependencies are basically un-editable. For small solutions, yeah, it’s nice to have.

    If C# were to get it, I’d want it to have a more comprehensive set of options for it than VB currently has.

    If you covered that somewhere in the car analogy, sorry. You lost me in the middle of that.

  6.   Sahil Malik on December 3rd, 2004          

    You can always split up your huge solution into smaller manageable chunks and make VB work.

    The only situation where this essentially doesn’t work is visual inheritance in windows forms – and well – even C# sucks there.

  7.   Dan McKinley on December 4th, 2004          

    Yes, I’m with you on splitting things up. But, we are where we are, unfortunately.

  8.   Bill McCarthy on December 4th, 2004          

    Hi Dan,

    In VB.NET 2002, the "transmission" was a very early design, much like the old tri-matics. That is it was terrible in certain conditions, but fine under normal conditions. For example, if you had a huge single file the IDE would grind to a halt; you could literally count seconds between keystrokes ! Not a normal condition, but when you did encounter it, things got very nasty quickly

    Then in VB.NET 2003, many of those issues were addressed. A huge single file no longer is such a system draw down. Still there are some issues with multiple project solutions. So the transmission is improved, but it is still not quite there…

    Now in VB.NET 2005, the transmission is finely matched to the IDE, and can handle those different driving conditions where it previously wasn’t the best. It is now very much like the latest state fo art automatic transmissions.

  9.   Bill McCarthy on December 4th, 2004          

    Hi Ian,

    In VS.NET 2005, there’s some new highlighting features, where green markers indicate code that has changed since you opened the solution, and yellow indicates code that has changed since the last save. So in C#, to check your code compiles correctly, you have to save the files, hence loose the yellow markings. This makes it impossible to have both compiler checked code and any indication of current changes. So yes, being *forced* to save the files in C# is a big deal


  10.   Dan McKinley on December 5th, 2004          

    Hopefully we’ll be going down the road of splitting things up by the time 2005 is out. If for no other reason, I’m sick of VB and I need to be using C# on new stuff for my sanity’s sake.

    It’s good to hear that the issues are being addressed. I actually got curious one day and opened up our solution in the 2005 beta, and was astounded at how much slower it was. But, I guess the "beta" thing is key here, and the slowness could also have been due to the "unused local variable" warnings numbering in the tens of thousands.