How To Pick A Programming Language
Tim Daneliuk (tundra@tundraware.com)(Originally posted on comp.lang.python, 1 May, 2002)
Copyright © 2002 TundraWare Inc. Permission to freely reproduce this material is hereby granted under the following conditions: 1) The material must be reproduced in its entirely without modification, editing, condensing, or any change. 2) No fee may be charged for the dissemination of this material. Commercial use such as publishing this material in a book or anthology is expressly forbidden. 3) Full attribution of the author and source of this material must be included in the reproduction.
This was written in response to one of the inevitable "Why programming
language is better, x or y?" questions that pops up with great regularity
on USENET. I thought I'd take a stab at answering it
for all time ...
Let L be the set of all programming languages ever conceived past, present, and future. The meta-question, M, thus becomes:
Among all members of L, which is the "best" and thus, which should I learn and use?
A variant of M, let's call it M', is:
Is L(x) "better" than L(y)?
Let P be the purpose for which you wish to learn a "best" language.
Let A be the answer to M or M' with condition
P as a constraint. A is thus the following set:
1) P = "I am interested in the design of languages and/or language theory."
Learn as many members of L as time permits. Do not pollute L with
your own ideas until you really understand what you are doing and what
has already been done. Then do so only if you are convinced
you can materially add to the state-of-the-art with original and useful
work. The world does not need another language just so you can prove
that you understand LR(1) grammars. Implement a subset of at least
one existing language yourself to see just how hard this is to do well.
2) P = "My current language is too slow/big in its appointed task."
Most of the time, these problems have a lot more to do with poor programming
and algorithm/data structure design than they do the language. Really
get under the covers of your programming style and design approach before
you abandon the language you currently know best. Read Bentley's
"Programming Pearls." Learn to use a profiler. Consider optimizations
which merely replace the slow/big portions of the code with something written
in a naturally faster/smaller language.
3) P = "I have a specialty problem domain which is not well addressed by a general purpose programming language."
Research what has already been done. You can often find close
enough matches to your problem within other problem domains to get something
useful done. If there really is nothing useful out there, strongly
consider using one of the extant scripting languages to build a "little
language" of your own which addresses your problem area. If all else
fails, ignore 1) above, and invent your own language, but
keep it as small and simple as possible, or you'll spend less time
on your chosen problem area and most of your time maintaining your new
language.
4) P = "I need to become/stay employable."
Survey common practice in your profession of choice and determine the
most common operating systems, GUIs, and languages already in use and the
probable evolution of these items in the next several ears.
Based on this information, you should select one procedural language, one
object language, one scripting language, and, possibly, one assembly language
which will comprise your core skill set. In
selecting these, also consider the availability of supporting tools
like standard libraries, debuggers, language-sensitive editors, profilers,
and so on. If you have some choice of languages, always prefer those
that share a common link format and have compatible inter-language calling
APIs. If it comes down to a tie, pick the older language because
it will almost always have fewer bugs.
5) P = "I want to write 'portable' code."
Warning: Computer Science Heresey follows. I've already been burned at the stake in this matter, so put your matches away.
Code 'portability' is overrated. Way more important is the portability of your programming skills. Languages come and go (well, they never really go, do they), but a good programmer expresses themselves well in pretty much any language. This comes with time, experience, reading other people's very good code and doing it wrong over and over again. The most portable language in the world can't help you if you don't understand algorithms, data structures, object decomposition, and how to trade off between them. Writing truly 'portable' code has as much to do with your understanding of the underlying operating environments (hardware, OS, network, I/O, and GUI) as it does with the language in question.
There are, of course, cases where portability is very important.
For example, if you are writing commercial software which must run on lots
of different platforms for your company to succeed. In that
case, first see if you can find cross-platform library support so you
don't have to do it all yourself.
6) P = "I want to make lots of money."
Quit programming. Become a rock star, actor, or corrupt politician.
The odds of getting rich in these fields, however slight, are probably
better than in programming.
7) P = "I've heard that OO is the way to do things, so I want the best OO language."
OO is one way to crack a problem. It is not the only way.
More importantly, it is often not a good way. A solid OO
language should be in your bag of tricks, but it's not the only thing you
will need.
8) P = "I've heard that AI is the way to do things, so I want the best AI language."
See 7) above.
9) P = "I want to produce code faster."
Type faster. It doesn't matter what you type because if speed
is your goal you'll just become expert at writing buggy code, so why bother
with syntax and semantics at all? Correct code is always produced
by people who are thoughtful and deliberate about what they are doing.
Oh, and in the long run, they're almost always faster getting things done
too.
10) P = "I want the <gender/species> of choice to like me and
be impressed enough to go out with me."
See 6) above.
11) P = "The system I must use prescribes a vendor-defined language
and tool set. I want other choices."
See if there are Open Source or alternative vendor choices for that
platform. If not, master the languages/tools on that platform then
broaden your horizons as a matter of professional pride and employability.
See 4) above.
12) P = "I'm very nerdy. All I like to do is code on as many
different platforms with as many different languages as I can. My
Resume' is 14 pages long. I have not been out of the house since 1982.
Please help."
Get a life. Read some poetry, or better still, write some (without
using curly braces or semicolons). Learn a musical instrument that
does not require electricity in any form. Get a low-tech hobby like
gardening or sewing. You are an Addict - I feel your pain.
As a recovery strategy, consider volunteering your skills to a cause that's
worth your time and effort and which requires you to interact with
people who have absolutely no clue how a computer works. Try
not to be a jerk when the local minister does not grasp the elegance of
your finely tuned LaTeX macro for generating the Sunday Bulletin.
Do something good for your body and your spirit. I strongly recommend
at least one high-activity sport (channel surfing does not qualify) and
shooting semi-automatic handguns (at paper targets in a legal manner) as
excellent mind-clearing tools. Collect something other than computer
manuals.
13) P = "I want to be famous."
Rob a bank and get caught. OR Write a ton of really useful
code and then give it away.
14) P = "I'm bored, I need a new challenge."
If you already know more than 5 languages, consider joining the Navy
SEALs - they are very busy at the moment and are always looking for an
Adventurer just like you. If you are over 19 and this is therefore
impractical, get married and raise children. You will never be bored.
Tim Daneliuk
"Bach, Sig-Sauer, Gibson Guitars, Python, & My Table Saw Made
Me What I Am Today."