How to Choose the Right Programming Language Version for Your Needs

[This article was written by John Paul Mueller]

A common issue developers face is choosing which version of a language to use for a particular project. Some developers think the latest version of a language is always best, but that’s not really true—newer is not always better. In fact, choosing the wrong version of a language could doom a project to almost certain failure, or at least make success much more difficult.

To keep that from happening to you, it’s helpful to avoid dangerous assumptions, understand the benefits and costs of language updates, examine your own personal preferences, and ask yourself some key questions.

3 deadly assumptions

Development environments are often fraught with unforeseen challenges that can scuttle even the best-laid plans. To help make sure that doesn’t happen, here are three deadly assumptions to avoid:

1. When working with an existing application, many developers assume they should use the same version of the language used in the original. But older versions of a language may not include the latest security features or may lack other features, requiring developers to invest more time in implementing further solutions.
2. When creating a new application, a commonly preferred choice is to rely on the latest version of the language. However, new versions of a language may not yet have widespread library support or fully tested functionality.
3. When combining application environments, organizations often force developers to use their favored language version regardless of whether it’s the best choice for the particular application at hand. Standardizing on a particular language version across the organization makes it easier to reuse tooling and libraries, and can help developers avoid being tripped up by version differences when they move from one project to another. However, it can also result in lost flexibility, an inability to use existing code, and wasted developer time rewriting code in the preferred language version.

All three scenarios reflect an application status. The problem is that project status is far from the only factor to consider. In order to choose the correct version of a language for your project, I recommend weighing a number of factors, including functionality, ease of use, reliability, and security.

The benefits of updates

Language updates are typically intended to increase functionality in some way, and they usually deliver. A classic example is Microsoft’s Entity Framework. Each new version of Visual Studio comes with an updated version of the Entity Framework (along with an updated version of the language and associated libraries). Each update has delivered major improvements in functionality. The same can be said about the latest version of C++: the latest available version offers substantial new functionality.

Updates can also make a language easier to understand and more consistent. For example, Python 2.7 supports print as both a command and a function, which can lead to confusing code. Python 3.4 consistently views print() as a function, so any code you create with it is more consistent and likely more reliable as well.

Language updates can vastly improve application reliability and speed. For example, HTML5 and JavaScript have become so reliable and fast, according to SitePoint, thatthe combination is quickly becoming a preferred language for mobile applications. Of course, you still need to worry about security, but the point is that the updates have made it possible to create an application that works on just about any device both quickly and reliably.

Security is another key reason to use a new language version. When dealing with Java security issues, for example, the latest version is by far the safest choice for development, says security expert Brian Krebs.

The hidden costs of updates

Updates clearly have value, but they also carry costs. The most significant cost of an update is backward compatibility. Perhaps the worst offenders are IDEs. For example, before you can load an old project in a newer version of Visual Studio, a non-reversible update must be performed. The update process checks for all sorts of things including project features that the IDE no longer supports. You might find that a language feature you really liked has been removed with no replacement. Worse,you might even end up with an unusable project after an update fails.

Sometimes, update costs may be hidden in the level of support the language offers. For example, many data scientists continue to use Python 2.7 because it provides library support that the 3.4 version hasn’t adopted yet. In addition, version 3.4 hasbreaking changes that cost data scientists dearly when it comes to performing any update. For a simple example, print "Hello" is perfectly valid in 2.7, but you must use print("Hello") in 3.4 instead.

Missing features are another common problem with updates. The missing feature may not be well documented or it could spawn a less-than-helpful error message. Any time you see the word “deprecated” as part of the update list for a new version, you need to pay particular attention because the change could render your application non-functional (or at least hard to fix).

Personal preferences

After considering the aspects of a language version decision, you may find that differing versions have a lot to offer, but you may nevertheless prefer one over another. In many situations, personal preference comes down to familiarity. When you know a particular version well and another version contains enough changes to impose a learning curve, it can make sense to choose familiar ground, especially when an application change is particularly complex or time critical.

Dual-version support

One interesting quirk of version decisions is that some languages actually offer dual version support, meaning that the language may officially support multiple versions at the same time. For example, as reported by InfoWorld, the update history for Python 2.7 and 3.4 shows that the developer backported many of the features found in version 3.4 to version 2.7! In addition, version 2.7.9 is actually a newer version than version 3.4.2. Don’t get too comfortable, though. The Python 2.7 release will eventually go away, so it won’t be available forever.

Making a decision

Optimizing application development may depend on choosing the right language for the job, and then choosing the correct version of that language. In many cases, you can boil the choice of version down to these six questions:

1. Does the version provide the library support needed to create a robust application?
2. Is the version both secure and reliable?
3. Are breaking changes between an old and new version small enough to keep developer burden to a minimum?
4. Does the version provide the appropriate level of functionality?
5. Can the version address unforeseen issues flexibly?
6. Does the language offer dual paths of support for both the old and new versions?

These are not trivial issues. Choosing the right version of a programming language can go a long way toward ensuring successful application releases that meet user needs and require minimal maintenance—with the least initial development effort.