Some clarifications regarding last week's anti-VC6 rant

This post started out as a comment to Len Holgate's post referencing my anti-VC6 rant. The comment got a little out of hand size wise so I've decided to turn it into a separate blog post. I think I mixed a couple of issues together that should been separated better but weren't - after all, my blog post was more of a rant.

First, if your client or employer is maintaining an existing system and the system is in maintenance mode only, we're talking about a bug fix or a small enhancement then it doesn't make sense to upgrade the compiler. That's what I was referring to as a system that is "on life support". Yes, it goes against the grain for me personally as a software engineer who likes to improve software but the effort spent on making the transition does not make sense from a business perspective.

What I do take issue with is when you are developing a new system or are working on a large refactor of an existing system that is in "embrace and extend mode", and for whatever reason the client or employer decrees that it shall be written using VC6. That's where the penalties come in and that is where the technical debt builds up at the start of a new project or at the exact point in time when you should be addressing the debt instead of adding to it.

The understanding of C++ and the use of its multi-paradigm nature has changed since VC6 was released, we have both new programming techniques and new libraries that (should) improve the quality of the code, its expressiveness and programmer productivity. The prime example of these libraries and the one I was thinking of when writing the rant of course is Boost. The earliest MS compiler they test against in 1.40 is VC7.1 aka VS2003 which is certainly a big improvement over VC6.

Yes, VC6 is likely to create smaller executables and build them faster. C++ compilers certainly are not getting any faster and long compile/link times have been a problem on projects I worked on. Shorter build times and especially smaller executables can be a benefit depending on your particular use case. A lot of the projects I worked on in the recent past are maths heavy and the calculations are performance critical. For these projects, an compiler that has an optimizer which can squeeze a 5% performance improvement out of the existing code one a modern CPU at the expense of 20% larger code is a no brainer. In at least one case it was cheaper to buy the Intel compiler to get better performance instead of putting more engineering time into performance improvements.

Yes, developers like shiny new tools and yes, I've worked with developers who considered GCC's CVS HEAD the only compiler that was recent enough to complement their awesomeness. This is not something I generally agree with although I did update my own copy of Visual Studio from 2003 to 2008 (yes, I did skip 2005) when that version came out simply because it was so much better than its predecessors.

I still think that by insisting on the usage of tools that are positively ancient, programmers get needlessly hobbled and it is part of our job as programmers who care about what they do to educate the people who make these decisions as to why they aren't necessarily good from an engineering point of view. I don't think any of the Java programmers I work with would put up with having to work using Java 1.2 and forego the improvements both in the language and in the available libraries, yet C++ programmers are regularly asked to do exactly that.