Software, technology, sysadmin war stories, and more. Feed
Thursday, May 2, 2013

You don't have to use the whole buffalo

Imagine a multi-purpose tool (like the so-called "Swiss Army Knife") which has been expanded beyond any sense of good taste and reason. Maybe instead of having five or six functions, it has a thousand. This manages to last long enough to where pretty soon it is the definition of a proper tool.

Other people and companies come along and build their own tools. When they do this, they try to compete on function completeness. Since the original insane tool had 1000 functions, they try to approach it as well. It doesn't matter that some of these functions are silly, others are ugly, and some are just plain annoying. More than a couple of them are flat out dangerous in the wrong hands, and some of them have no sense existing in the modern world.

Still, they try to compete on those terms. Maybe one company gets up to 500 and calls it pretty good. Then another manages to hit 600. The one-upping continues every year, with everyone trying to climb closer to fitting all of these features into tools of their own design. The whole thing is ridiculous and pointless, because nobody really needs or wants all of that junk.

This is a lot like the world of programming languages today. Lots of things which are possible still aren't a good idea, and yet they persist. Everyone has a different rationalization for why some of this stuff still exists and is enabled by default. Sometimes I wonder if some of these people are incapable of thinking in such a way that lets them realize that sometimes, fewer features is the better way to go.

For example, if you're a C programmer, when was the last time you used gets() or any of the str* functions which don't take length arguments? If you've actually used them any time in the past 15 years, did you have a solid reason for it, or was it an accident? Were you perhaps a newcomer to the field and didn't know why some of these functions have been deemed dangerous in many situations?

Even if you have a bona fide use case for some of this tricky stuff, do you really need it enabled globally and by default? I bet you could actually live with it disabled unless explicitly switched on for a specific module. Then you could use your dangerous tools in the proper controlled environment without endangering the rest of your project.

There's a lot of crazy, silly, and dangerous stuff in programming languages. I use C++ a lot and so I wind up selecting those parts which are a bit more sensible and leave the weird stuff alone. Just because it's there doesn't mean I have to wrestle it into my code. There's no point in showing off.

Want to see how bad it can get? Okay. Check out some slides from a 2010 presentation called "The Dark Side of C++". Clearly, many dragons lurk in the depths of that spec, but so what? They should be located, called out, and walled off.

It's not like we're a bunch of hunter-gatherers who live off the land and have to respect Mother Nature by using everything we obtain. When it comes to programming languages, you don't have to use the whole buffalo.