Language Wars

Java or C#? VB or Delphi? A noncombatant comes clean about his programming language of choice.

It is computed, that eleven thousand Persons have, at several times, suffered Death, rather than submit to break their Eggs at the smaller End. Many hundred large Volumes have been published upon this Controversy:
— Jonathan Swift, Gulliver's Travels

Put a few software developers in the same room and, after they finish establishing their familiarity with obsolete systems ("Tin-can teletypes? We would have killed for teletypes! We had to submit all of our jobs on punched paper tape."), they will generally start fighting the language wars. It doesn't take much poking around on Internet discussion boards to find comments like "This language provides a useful alternative to the haphazard, non-OO approach you see in many Delphi/VB applications" or "C++ is an overdesigned disaster" or "C# is just Microsoft's attempt to kill Java" or "You're not a real developer, or you'd be using a real language."

All too often, these discussions take on a sloganeering quality: "Linux Good, Microsoft Bad." "Scripting Good, IDEs Bad." "Java good, .NET Bad." Of course the more such things get shouted, the more people on the other side of the particular language war in question shout back. Eventually tempers fray and the people who were actually trying to have a discussion remember more pressing and fun engagements, such as root canal appointments.

As for me, when the language wars start, I start looking for the exit. It's not that I think the choice of language for a particular project isn't important. It's that I think there are better ways to go about making that choice than to try to find the "best" language.

Choosing the Right Tool
Over the course of my career, I've used at least fifty different computer languages, from the obscure to the common. Not too surprisingly, I was able to write programs in every single one. Of course, from one standpoint, that's a trivial result: all computer languages that I know of are Turing-complete, which means that they can be used to solve any computable problem. But that doesn't help much if it might take millennia to solve a particular problem with a particular language.

Where the language warriors make their mistake, I think, is in believing that just because languages are different one of them must be the best. That's just plain silly. Asking what language is best is like asking what type of wrench is best. The 6 mm socket and the giant pipe wrench that could brain an elephant are both best for particular tasks. In fact, the interesting question about computer languages is not which one is best, but which one is best for a particular task under particular circumstances.

The task portion of the equation is easy to see (that is, unless you're one of those "my language right or wrong" types). Visual Basic excels at creating Windows user interfaces quickly (it's not the only language that excels in this regard, of course), but it's not very useful for embedded systems development where every byte counts. On the other hand, even hardcore proponents of Forth probably wouldn't suggest their own language for banging out a quick Windows data-entry application. C++, Perl, Lisp, assembler…each has its own problem domains where it excels in producing solutions.

But don't forget the "circumstances" portion of the equation, either. If you're faced with implementing that data-entry application, you might find that both Visual Basic and Delphi can build it quickly. In that case, you need to look to other factors beyond simply addressing the immediate requirements to make your language choice. Is single-file deployment important? Does your team already know VB inside and out? How do you feel about vendor diversity as opposed to having a single source of support? Softer questions like these can help you to choose the appropriate language when the hard facts of requirements aren't enough to dictate a choice.

No Language is an Island
When you're trying to select a computer language for your next task, you need to think about all of the factors involved, not just suitability to task. Here's a ten-point checklist that should help you cover the bases:

  1. Is the language suited for the task at hand?
  2. Does your team have experience with the language? If not, how are you going to handle training and learning issues?
  3. Does the language integrate well into your existing tools for the rest of the development lifecycle? Think about requirements gathering, architecture and modeling, source-code-control, automated build processes, and test issues. Are you going to have to spend money on new tools?
  4. Is the language available from multiple vendors? If so, how are you going to select a vendor? If not, are you comfortable that the vendor will stay in business?
  5. Is there a user community for the language? Can you turn to newsgroups, user groups, and books for help?
  6. Will you need to port your code to another platform or another language in the future? How easy or hard will that be?
  7. What integration hooks are built into the language? Can you use it to interoperate with a database, call libraries, create a Web service, or otherwise connect to the rest of your solution?
  8. Will the language tools run on your existing hardware?
  9. Does the language have a proven track record on projects similar to yours? Can it handle the requirements? Can it handle the projected size of your application?
  10. Perhaps most important, why are you considering this language for this project? Is it just the language you're most comfortable with? Did your boss just have lunch with the vendor? Or are there solid technical reasons to go with this language?

Remember, your job is to create computer software that fits a set of requirements. Your customer doesn't care what language that software is written in (except for cases where there is a language requirement - for example, some contracts may require software written in ADA). You don't get extra points for switching languages, nor do you get them for staying with the same language beyond the point where it's useful.

New Ways of Thinking
Whatever your stand in the language wars, I urge you to not be too doctrinaire about it. Computer languages come in a wide variety of flavors, from Lisp to Visual Basic to C++ to Python and beyond (see To keep your skill set growing, you should make an effort to improve your knowledge of the languages that you're not using yet. The Pragmatic Programmers ( even suggest institutionalizing this idea by learning one new language a year, which I think is a fine idea. As they point out, different languages solve the same problem in different ways, so by learning more languages you can avoid getting stuck in a rut. You can also give yourself more perspective the next time it comes to choose a language for a new project, and avoid the mindless arguments of the language wars. Another side benefit of becoming a better programmer!

Got any language war stories of your own? Or do you already learn a new language every year, whether you need it or not? Write and let me know.

About the Author

Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.


comments powered by Disqus

Subscribe on YouTube