Inevitably, in any discussion on new application development, the subject of using the correct programming language comes up. Usually this comes in the form of "Use the correct language for the situation. Shortly following the consideration of this sage advice, comes a respectable statement along the lines of "it doesn't really matter what language we use, so lets use the one we are most familiar with". But is that really the best advice? Let's explore that a little.
In my discussions of the development of my personal project I am working on, I was simply not considering the language. For me the choice of Delphi was obvious but I was rightly challenged in that decision. Considering a language is not to be taken lightly, however there are usually good logical thoughts behind using a language the team is familiar with. Usually, the main programming language used by a team can do most things required, and the effort involved in learning a new language and coming to terms with its eccentricities would effect the project timeline and could threaten the delivery. For example, if a development team is to move to a new language there is not just the training involved, but the times when a developer spends a week or more trying to get something working as it should, only to find that those experienced in the language know to do that particular process another way due to some limitation or bug in the tools they are using. We've all been there. Add to that the current development still needing support in the old language.
However, the language used is a big decision. What of the market you are looking towards? Would the market require, for example, a Microsoft approach - i.e., best approach be damned, unless it's all written in Microsoft Visual Basic, we're not interested (shudder). Other thoughts may include any of the following:
Pure marketing heavyweight - Oracle (yes even Oracle Forms, still supported by Oracle, but no further development), and PL/SQL. Selling to large corporates, this approach ticks all the boxes and gets you past the elimination process.
Mature large development environment - J2EE. While I concede that every J2EE development project I have been involved in has been fraught with troubles and ultimately has not produced (although these issues can often be attributed to other factors), this does not limit the effectiveness of Java when managed correctly. Invariably developing a large corporate application in J2EE means dealing with numerous technologies and more than one programming language. I'm certain that others can cite many excellent large scale development projects using J2EE. J2EE however is the "expected" development environment these days and often companies will look for that environment as a mark of maturity in the supplier.
Medium scale development - C# perhaps? This environment is the favourite of those moving from Delphi or Visual Basic and has come to be a relatively well accepted development language well suited to Agile development teams.
Web development - While J2EE arguably dominates this area, Ruby for Rails is increasingly being considered for this environment. It is surprising how Ruby for Rails is still an unknown for many executives involved in technology decisions - aren't they the ones who's job it is to know these things? However the conversion rate to Ruby on Rails shows that it's general acceptance is just a matter of increasingly shortening time.
Small scale, Win32 development - Delphi, Visual Basic, C#, etc. Although it can be effectively argued that the likes of Delphi can easily be used (and I can cite many successful projects) in much larger corporate development projects, the acceptance for this is simply no longer there (shame on Borland).
While I am quite sure that you have your own list, and that you hold strong considerations that may differ from some of my comments, as a Development Manager in charge of a development team that creates corporate applications, the above is the way that I look at the world of languages. I'd love to hear of your experiences and thoughts.