The title really says it all, choosing is painful.
I’ve been reading ‘Coders at work’, and this line jumped out at me, from the ‘Joe Armstrong’ chapter.
When I learned how to code, the mid 70’s to early 80’s, on small machines, you had exactly one choice of language, it was ‘BASIC’. The only difference was which dialect (and those dialects had so much in common that if you were proficient in one you could switch to another one in a matter of days).
Languages also cost money, open source had not happened yet. This helped to limit your choices, whatever your machine came with (BASIC) is what you used.
If you had more money to burn your choices might expand a bit, an assembler, or maybe a forth, lisp or pascal compiler (for the lucky few).
Other languages existed, of course, but for the most part they ran on bigger machines. C, COBOL and a whole bunch of other languages didn’t get into widespread use on smaller machines until much later (and some, like COBOL never did (fortunately!)).
Getting a new language for your computer was a major operation, might involve upgrading the hardware (storage, memory) and would require you to spend many days and probably a good bit of money.
This situation persisted for a long time, even though C migrated from the big machines to the smaller ones and for the most part replaced the use of assembly except in very specialized cases, and it’s slightly larger, more ‘OO’ (and more messy) brother C++ joined it there.
Then somewhere in the mid 90’s the web happened and a veritable explosion of languages resulted, some of them written with the web expressly in mind, others changed their status from ‘closed source’ to open source and found a serious increase in the number of people adopting them. This was driven in part by the fact that open source made installing another language free and relatively painless, and in part by the increased performance of computers which led to ‘scripting’ languages being fast enough for actual work.
Now, 2009 we have the choice out of an enormous number of platforms, languages, frameworks and the new kid on the block, the ‘cloud’ architecture (which you can talk to in a variety of languages, not all of them equally suited to the task).
Choice is good, they say. But I’m not so sure about that. I don’t think that it helps to have 200 different kinds of bottled water, just as I don’t think it is helpful to have many languages that are trying to do the same thing in slightly different ways.
If you’re a developer nowadays, the choices are literally paralyzing. For your typical web based application you are going to have to balance the following requirements:
- ease of writing ('expressiveness')
- documentation
- suitability for the task at hand
- familiarity
- available libraries
- community (or, how hard is it to get help if you get stuck)
- scalability (if it gets to that stage)
- maintainability
- availability of programmers (if you won't do the coding yourself)
- frameworks
- template systems
- performance
- security
- single or multi vendor, open source
- stability, standardization
A typical case, you’d be evaluating these for (for instance), Python, Ruby, PHP, Java, Erlang, Clojure, Scala, C/C++, C# and Perl. I may have missed one or two, but these are the ones that pop to the surface when thinking ‘web application, language’.
Especially when mixing the libraries, frameworks and template systems in to the soup the number of choices grows very fast.
Typically there are probably upwards of 100 combinations that you could choose to implement a given problem. In some cases, your boss will tell you what to do, but in most cases, especially in the context of a new project that you do for yourself or a small business that you plan to launch you are going to be faced making these choices.
To help you to choose I would suggest to assign a score to each of the factors above, if you’re dead set on using some framework (say Drupal, Django or Rails) then that will limit your choice of language to exactly one. But the more freedom you allow yourself the more work will go in to making the choice. By assigning a score to each of the factors you can get a better grasp on which combination works best for you.
Familiarity is of course a big factor, if you don’t know how to program in a certain language then you have to take a penalty for that, but then again, it never hurts to learn more languages, so there is an upside as well (though it may take you a bit longer than just one project before you’ve really mastered a new language).
If you want to do a quick and dirty one-off, then clearly, expressiveness is more important than long term maintainability. But even then, you have to heed the warning that most software lives a lot longer than its original writer intended.
If it is at all possible try to make it a process of elimination that way you prune the choices that you can’t make anyway of the tree as early as possible, so that you can spend your time on evaluating those choices that actually make sense.
When researching this subject, I’d advise you to put a year (such as the current or the previous year) in to your searches, plenty of opinions out there about all kinds of stuff, but the reality is that programming languages and environments are in continuous flux, what was true two years ago is not necessarily true today.
Making the right choice can save you a lot of agony down the line, it is wise to spend some time on this so that you don’t end up regretting your choices later on. And being methodical in making your choice is going to go a long way to helping you make the right one.
And, if all else fails, you could always try to write it in ‘BASIC’ ;)