They regularly appear at the heart of debates that can be virulent on the supremacy of such and such a language, which will supposedly relegate all the rest to prehistory. Let’s be clear: most of the time, those debates are only of interest to computer programmers, and even then, only a small proportion of them. But the debate can occasionally take center stage, because a language’s concepts could have a profound impact on how programming is done and how efficient it is, or because of a sudden realization that a language is now being use on millions – or even billions – of devices.
Industrial computing is a unique domain, with its own constraints and requirements. Like what happened with automation that used the languages contact (ladder) and grafcet, you might have expected that, with the explosion of programming languages, a business-specific language might have appeared, dedicated to this type of application, but such was not the case. As a result, the development of industrial applications relies on “general” programming languages, and manufacturers and integrators alike might rightly question the importance of the development language used and the criteria for assessing it.
Custom development of an industrial application
As software vendors, we can only strongly advise that you do not custom-develop your application. We are persuaded that our portfolio (or those of our peers) can provide you with a large number of generic, turnkey features that have already been tested and approved, which can save you precious time in developing your application. For our COOX range, our portfolio also makes use of an open-source software platform and data model that comply with standard ISA-95 and make it possible to easily extend the turnkey functionalities and adapt them to your specific needs. Of course, because this is a general article, we need to consider the eventuality that you might find that the application you want to create differs too much from an MES approach or standard supervision (or that the decision to program a custom development was made before you learned about our solutions!).
Because the entire industrial application is custom-developed, it is a new IT development in its own right, and the number one criterion in your choice should certainly be making sure you have a solid environment capable of supporting and maintaining it. The availability of a large selection of libraries associated with the environment (HMI design, database access, functional processing, reports, etc.) is also an important aspect. The selected development environment will often point at a “preferred” language. The main development environments encountered today are Microsoft’s Visual Studio (C#, C++ or Basic), Eclipse (Java, C++, Ruby, Python, etc.) and NetBeans (Java). Alongside those major leaders are a large number of single- and multi-language environments, some of which are RAD (rapid application development)-oriented. Although they are generally effective and appealing, the latter tend to have difficulties offering solutions that are able to withstand the test of time. Because the RAD environment causes a large percentage of the underlying code to disappear, it can be difficult – or even impossible – to migrate to a different development environment. This is a general problem for all computer applications, but it is particularly true for industrial applications, which are expected to be usable for a very long time. One of the strongest representatives of the RAD environment has undoubtedly been the Delphi environment. Long driven by Borland, its initiator dropped it when Microsoft launched the .NET environment. It now belongs to Embarcadero, which has since released newer versions. The choice of a robust, widely-distributed development environment affects not only the simplicity of development work, but also the associated risk factors: ease/difficulty of recruiting trained developers, long-term application maintenance, etc.
Use of a vendor software package
In the case of use of a vendor software package, you might be tempted to avoid the question completely, thinking “that’s the vendor’s problem.” That’s not quite true. In fact, it’s not at all true, for two different reasons.
The first is that, in order to have a lasting software portfolio that evolves over time, vendors must not only continue to exist, but they must also be technologically capable of upgrading their portfolio. The first point is the one most often examined by buyers but, if you really think about it, it’s not actually all that important (a valuable software portfolio will generally find buyers who will ensure its perpetuation in the case of any challenges experienced by the initial vendor). Conversely, there are countless well-known companies, in perfect financial health, who simply abandon one software solution to launch another that is functionally equivalent but provides no continuity with the first one. This is more of a mercenary attitude that aims to force clients to replace their inventory, yielding new sales that are more lucrative than mere software updates, or that centers around profitability criteria. This may be partially true, but the inability or great difficulty in handling new technologies (64 bits, Internet, mobile rollout, etc.) with the chosen development language is often the root cause of these questions.
In MES projects, and sometimes even in supervision projects, the sections developed in that second language are often substantial and, here again, it is essential to have a large pool from which to recruit resources (both today and going forward) to program and perpetuate the proposed language. Obviously, the worst-case scenario is one in which the vendor’s proprietary language is used, requiring special training and that cannot be perpetuated and enriched by a single player, which greatly limits its upgradability (a programming language’s maintenance and evolution is a sizable task, requiring a large team of developers unto itself).
What are the best languages for an industrial software package ?
For the package’s fulfillment language, a robust, highly durable language is, of course, necessary. Although historical languages like C can be used, today it would be difficult to ignore the gains in productivity and upgradability afforded by object-oriented languages like C++, Java and C#. The longevity and dissemination of the chosen language are important elements for the vendor, which will need to maintain and upgrade its portfolio over time.
For the choice of language used to extend applications via programming, the choice of a language that has historically been used in installs may appear to be a reasonable solution, on condition of avoiding proprietary languages that would require special integrator training. However, the choice of an older language could pose the same problem of integrator resources, once its distribution starts to decline. In addition, more recent languages like Java have not been launched without a compelling reason. They are responses to needs in terms of security, install rollouts, and easy access via web mechanisms, which can be very difficult to meet with older-generation languages. When used in combination with modern development environments, they also provides significant gains in development productivity.
What are the most commonly-used langages ?
As we saw earlier, the languages used to develop and extend MES and SCADA software packages are essential to ensuring the applications’ longevity and upgradability. Because considering a new language for your computer applications is an unwieldy process, the most widespread languages, especially for infrastructure applications, are those whose developer communities make the most constant efforts in the interest of their perpetuation and their evolution. However, it is not always easy to get a grasp of the actual use of each language in the applications. There is no centralized registry where developers report their use of a given language to build an application. Because the most common languages are not typically subject to a licensing fee, we can’t use sales figures to estimate their use.
TIOBE Software had an original measurement idea, based not directly on the distribution of a language in different applications, but rather on its online distribution, assessed as a function of the number of mentions of that language across all web pages. Many of those pages were job search pages or job listings, while another large segment comprised press articles and technical discussions of a given language. In total, the resulting distribution can be considered as representative of the activities surrounding each language, and therefore of their use in applications. The widely-renowned TIOBE index has been in place since 2002. The table above lists the top 10 languages according to TIOBE’s rankings from July 2015, with a comparison against their positions the year before.
ORDINAL Software's choices for its COOX range