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:
- Is the language suited for the task at hand?
- Does your team have experience with the language? If not, how are
you going to handle training and learning issues?
- 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?
- 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?
- Is there a user community for the language? Can you turn to newsgroups,
user groups, and books for help?
- Will you need to port your code to another platform or another language
in the future? How easy or hard will that be?
- 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?
- Will the language tools run on your existing hardware?
- 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?
- 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 http://www.catseye.mb.ca/esoteric/index.html).
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
(http://www.pragmaticprogrammer.com/loty/index.html)
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.