Everyone is diligently working away in the office as usual. Suddenly, a meeting notice shows up in your mailbox, its title reading "Our Next Application." You have gathered an initial set of requirements for your newest project, and now it has come down to the ultimate question of which programming language to write the application in and which tools to use. Unfortunately, this isn't always an easy question to answer. In fact, it's one that has been known to cause heavy debate within the industry. We all wish there was some simple function, f(x), where we could input our set of requirements, x, and get output—PHP; Java; or in many real-world cases, something to the effect of "Unreasonable, GOTO :REQUIREMENTS." While there is no such magical function (at least not yet), there are some fundamental dimensions, both of the project and its environment, we can look at in an effort to minimize our set of options and ultimately make a successful selection.

Understanding the Dimensions

There are many facets to selecting a programming language. But before we continue any further, I would like to take this opportunity to define a programming language. In his book titled Principles of Programming Languages, Bruce J. MacLennan states, "A programming language is a language that is intended for the expression of computer programs and that is capable of expressing any computer program." He goes on to say that while there are a wide variety of programming languages available in which we can write computer programs, it's not equally easy to do so. Also bear in mind that there is no such thing as an ideal programming language; each one has its strengths and weaknesses, and it's important that you weigh both sides before making your decision. All of this illustrates the need for some heuristic approaches to selecting a programming language so that it will best meet the needs of your project.

Let's move on and take a look at some of the language selection considerations.

Application Type

Without a doubt, the type of application that you're developing is one of the most important aspects in determining which programming language will be your best fit. Most computer programs created within development shops can commonly be grouped into one of two categories, those that are important and those that are not important.

For example, the program that Mary creates to parse her database log files every morning isn't really all that important, so it doesn't really matter which language she writes this utility in. In fact, she probably selected an interpreted language like Perl that has excellent text processing capabilities and rapid development speeds but doesn't always promote the most readable code. While she certainly could have, Mary probably did not spend the time designing and implementing an entire C++ class hierarchy to perform this task. Programs like this do not warrant the time and effort of researching programming languages and tools to make a selection. Because this program isn't mission-critical and isn't likely to be transferred to anyone else for maintenance, the best use of time would be to let Mary use a language in which she can quickly and effectively get the job done in the shortest amount of time. However, this does not mean that no software engineering respects should be paid to "unimportant" applications, just perhaps not to the degree one must pay to "important" applications.

Then there are those applications that are considered important. This is where the decision-making can become tricky. The language and tools that you choose will often depend on the answers to a number of questions:

1. Is the application Web-based?
   If the application is Web-based, there are some specific constraints on language selection: the ability to handle a variety of protocols and formats (e.g., graphics) and programming tasks; performance (both speed and size); safety and security; platform independence; and the ability to converse with other languages and tools (e.g., through a Web services-based service-oriented architecture). These issues are not necessarily independent of one another, as one choice that's optimal in one area might be worse in another. It is critical to evaluate your options based on the above criteria and select the option yielding the most pros and the fewest cons.
2. Does this application need to run on several platforms?
   Platform-independence is a wonderful attribute for any program to have. It means that a diverse set of clients can reach your product. However, platform-independent applications present additional challenges: Compared to platform-dependent applications, they can be difficult to implement, depending on the programming language selected; they require additional time to build and execute test plans; and they can be difficult to support. However, certain programming languages lend themselves easily to creating platform-independent applications. Java is a perfect example. Nearly every major operating system supports its own Java Virtual Machine (JVM), which separates the Java programming APIs from the underlying platform. This promotes the "write once, run anywhere" concept. Other languages like C or C++ require the code to become cluttered with environmental conditional statements to call the appropriate system calls (these can greatly differ from platform to platform).
3. How critical is performance?
   Is it a necessity for your application to squeeze every possible microsecond out of the processor, or can you make some performance sacrifices for other language benefits (e.g., platform-independence)? If you're hard up for speed, then you definitely want to shy away from interpreted languages (which are slower by definition than compiled languages) and languages that run in a virtual machine of sorts (e.g., Java). Rather, you should be looking at languages that run closer to the machine interface (i.e., those that efficiently compile into the hardware's assembler instructions), like C.
4. Does this application need to interact with other applications?
   Many of today's business applications don't live in a vacuum—that is, they're not so monolithically natured anymore. They need to interact with other applications. One of the hottest IT buzzwords today is service-oriented architecture (SOA). The fact that SOA, especially Web-services-based SOA, is becoming so popular makes conversations between disparate applications much easier. Almost all commonly used programming languages in some form or another have SOA frameworks available. Even legacy COBOL and RPG applications can be modernized to talk to modern applications using this architecture.

Language History

Probably ranking second in importance, behind application type, is the history of the programming language. A look at a language's maturity is an excellent way to determine if it should be used for your next "important" application. The last thing you want to do is select a language or technology that's still in its infancy stage and wind up rewriting much of your code. Because it's so new, many of the APIs may become deprecated with each release because a newer and better way of doing something was discovered. Java and PHP are perfect examples. Many of the original JVM quirks have been worked out, APIs have been solidified, and now finally with the latest features in J2SE 5.0, Java is all grown up. PHP is a language originally intended for rapid deployment of dynamic Web-based content. Now on its fifth version, PHP has rich object-oriented support, a wide variety of functionality at its fingertips, and a very solid user base. Contrast these languages with a fairly new Web-based framework such as Ruby on Rails. While Rails certainly does have its novelty, I would be a little cautious before jumping on such bleeding-edge technology and using it to create production content since it hasn't had its time to mature. The important message here is do your homework first!

Development Tools

Development tools that fit nicely with a programming language are a necessity. The two major tools involved in software development are modeling and architecture tools and integrated development environments (IDEs). How should these bound the language you select for your next project? Well, that depends on your project. For a lot of projects, excellent open-source IDEs are available, such as Eclipse. Eclipse is a platform-independent IDE that originally targeted Java projects, enterprise or individual, and it has integrated support for common source control management (SCM) tools like CVS. Eclipse has matured over time, and it now has several plug-ins available that add support for J2EE applications, PHP, C++, and several database management systems (DBMS), just to name a few.

IBM's Rational Application Developer (RAD) product is based on Eclipse technology. RAD offers additional features to support a product from its design stage through its maintenance stages. RAD also supports advanced features of IBM's WebSphere Application Server, which provides an enterprise-level J2EE environment and much more.

If you went down Microsoft's Active Server Page (ASP) route, MS Visual Studio .NET is an excellent IDE that supports that environment. If you're using a company's specific technology and the company has development tools specifically created for that technology, it's probably worth the investment for those tools (but be sure to do your homework first).

For other languages and technologies, I would highly recommend that Eclipse is mentioned at your next development personnel meeting. It's an established and feature-rich IDE. That said, while development tools are definitely a factor in language selection, they shouldn't be considered of significant weight.

System Platform

System platform can always be a touchy dimension. In a perfect world, software architects could design applications with the best of technologies and correspondingly the best hardware. And then we wake up and remember that there is a considerable investment in the company's current infrastructure. That does not mean that obtaining a new platform to fit the technologies you're targeting isn't impossible, but just remember to pick your financial battles wisely. The truth is that most platforms support a wide variety of technologies and programming languages. For example, did you know that IBM recently announced the availability of PHP on its i5/OS operating system? Certainly, some languages perform better on certain platforms than others, but usually if a language is supported, it will have reasonable performance. There's nothing worse than pushing for a new platform and then realizing it would have worked just fine on what you've got at your fingertips. That said, don't let the platform completely bound your decisions, but try to make the best use of what's available. Effectively utilizing existing capital enough times will only strengthen your credentials for when you do push management for new hardware.

Developers' Comfort Zones

So your IT shop consists of some RPG programmers and some younger talent. What do you do now that you have to build a new application? While these programmers may have many differences in taste, we often forget one very important commonality; both sets are software engineers at heart and enjoy learning (at least they should!) new ways of problem solving. Don't let your team's current skill set completely bound your application design. As mentioned in the future "Keeping Up with the Technology Trends" section of this article, periodically bring back new technologies and trends to your development staff. Provide a wealth of books and articles on the latest programming languages. Schedule a crash-course class that introduces a new language. Any good computer science curriculum doesn't teach just a single programming language; rather, you learn about the abstract concepts, and learning the programming language is the easy part. I'm not suggesting that one can become a C guru in a few weeks, as there are many "features" of C that take much practice and patience to master. However, some people would argue that some of those "features" are things that don't promote the best software engineering practices anyway. The point here is that you shouldn't let your team's current set of skills fool you into thinking that new trends can't be picked up and learned relatively quickly—because they certainly can by applying some of the strategies mentioned above.

Applying Knowledge of the Dimensions

So now that we've discussed a few of the important dimensions of language selection, what's the next step involved in selecting a language? Simple: Carefully evaluate the points mentioned above along with any other remaining constraints (such as budget), narrowing down your choices until a clear choice becomes evident. As mentioned earlier, there is no set algorithm that one can follow here. As long as you've done your homework and given thought to what's outlined above (and of course any remaining factors specific to your project), your engineering instincts should prevail.

Keeping Up with the Technology Trends

To anyone who has been involved in IT for any length of time, it should come as no surprise that technology changes at an alarmingly rapid rate. New hardware, new software, and new programming languages—everything is subject to change. Whether you're a large or small IT shop, it's definitely to your shop's advantage to have in one or more of staff members' (especially your software architects) job descriptions something to the effect of "Periodically explores new trends and technologies." I simply can't stress enough how very important this is. Even if you're not going to change the language in which you develop your products, you might stumble upon some new development patterns and frameworks that have already laid the groundwork for your next major development effort. You might stumble upon someone else's success or failure story in a similar area that completely changes your thoughts on design and implementation. And on top of just researching new trends, have these people bring information back to your development group! It doesn't need to be anything fancy; even an informal presentation highlighting some of the latest finds would suffice. These are perfect opportunities to stir up an interest in these new trends, whether they're programming languages or not. Even some newfound curiosities might arise from the "legacy developers," and they could become interested in languages and tools that might save them a lot of time and effort reinventing the wheel. After the material is presented, archive it somewhere so that it's easily accessible by your development group for future reference.

Time to Make Your Selection

Know the requirements and goals of your project intimately. Know your development staff's skills, keep them thirsting for knowledge, and provide training when necessary. By doing so, you'll feel less restricted and on the edge when selecting new application technologies, especially a programming language. It is a broad scope of language knowledge, new technology insights, and past experiences that will ultimately lead you to successful programming language selections—and more importantly, successful projects.

Joe Cropper is a Software Engineer at IBM in Rochester, Minnesota. Joe works as part of the IBM Customer Test team, and his areas of expertise include DB2/UDB 400, multi-tiered client-server technologies, and a variety of object-oriented programming languages. Joe can be reached via email at This email address is being protected from spambots. You need JavaScript enabled to view it..