If you’ve never heard the expression, it refers to the practice of carrying programming habits to a new context, even when they are inappropriate. Some programmers who began with FORTRAN continued to write programs that strongly resembled FORTRAN after they had moved to other languages. They remained too set in their ways and didn’t adapt their programming approach to a new way.

(I should point out that I always liked FORTRAN. Many of the failings people ascribe to FORTRAN-77 are related more to bad programming than the language itself. Also, Fortran-90 later addressed most of the actual weaknesses of FORTRAN-77.)

Jeff Atwood at Coding Horror wrote an interesting post called XML: The Angle Bracket Tax concerning his dislike for the way XML is being used (or abused) by many programmers. He says:

I realize that we have to use something to represent reasonably human readable data stored in a text file, but XML sometimes feels an awful lot like using an enormous sledgehammer to drive common household nails.

I have found that when many people successfully solve a problem once, then they feel they must standardize on this solution and apply it to all future problems they encounter. Sometimes this makes sense, but much of the time it doesn’t. Each new problem should receive an appropriate solution, not the one that worked for different problems in the past.

I think that this describes the current problems with XML. If XML worked for you once, that doesn’t necessarily mean that you have to use it for everything you do in the future. Many times, programmers struggle against the complexities of XML when they would have had an easier time with a simpler format. They are only using a tiny subset of the features of XML, so why not just simplify their tasks by using a simpler format?

This isn’t to say that XML is useless. On the contrary, I think that it is incredibly important and will remain a dominant file format for years to come. I think that future-proofing your data is one of the best arguments for XML and one that is rarely mentioned. It is unlikely that XML will be forgotten anytime soon, which is something you can’t say for many other formats. Parsers will be available for all platforms for years to come. This is very important for data that must be archived and accessed in the future. But is future-proofing really that important for a simple initialization file?

Quite some time ago, I needed to examine a program that had been written in C++. This was not long after object-orientated programming had become a hot topic, and the author of that program had apparently decided to embrace everything object-oriented. In that code everything, and I mean everything, was an object. Not just things you would expect, such as lists, queues, or even strings (this predated the standard library). But absolutely everything, including simple operators, small portions of algorithms, even variables and constants! The sad part is, rather than promoting code reuse, the style actually meant that I doubt any part could have been used again.

I could have been convinced by that one bad example that C++ and all object-oriented languages were worthless and just a fad. But that program was not a good example of how to use C++, and did not reflect on the merits of C++ in the slightest way. The strange thing is that I don’t believe the author was a bad programmer, just overzealous in embracing C++  (It might also have been intended to make a point, but that’s a whole other story).

No matter the programming tool or feature, there will always be a way to abuse it and you can be certain that someone will. You can write truly awful code in any language, and I can guarantee you that someone already has. But bad examples shouldn’t reflect on a tool or language, no matter how bad they are.