Starting with only a dozen or so in the early 1980s, programming languages have multiplied since then, now easily exceeding 100. There is abundant literature on the subject, which has earned its spot in large bookstores, alongside math, physics, economics, history, philosophy and the humanities.
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.
The second reason is that, in addition to the programming language used to develop the software, the vendor typically uses a scripting language that is often different from the first language to personalize or expand the supplied software package in order to adapt the application to its users’ needs. Intended for use by the integrator, and sometimes the users themselves, these languages are designed to be easy to use and relatively unrestricted. These criteria privilege interpreted languages (that do not dictate any stages for the compilation or publishing of links, and that might potentially be modifiable in production) which are weakly typed (that do not require prior variable declarations that make them more laborious to write). Conversely, over and above highly fact-based criteria, people often overestimate the difficulties specific to a language or the difficulties switching from one language to another, particularly in terms of syntax. Although working with more powerful concepts necessitates more in-depth language knowledge, the most common programming structures (if then else, for loop, etc.) are very similar across all existing languages (from Basic to C# by way of Pascal, C++, Java and JavaScript), and the time needed to assimilate the syntax of a new language is often just a day or two. Better still, for the most common programming structures, the languages C, C++, C#, Java and JavaScript have all adopted exactly the same syntax!
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
For its development and its extensions, COOX relies on two highly complementary languages, Java and JavaScript. The very meticulous Java – a reference among object-oriented languages – endows the COOX Platform with solid software architecture devised for the intranet and for no-install customer rollouts. The COOX Platform provides all of the capabilities of a Java platform, and even allows for the use of other languages, like JRuby (Java implementation of the Ruby programming language) and JPython (Java implementation of Python, used by our client Soleil Synchrotron). As for JavaScript, it is a faithful companion to all HTML web pages, as well as a very flexible language that is easy to learn and less strict on the developer. Additionally, it enables modifications “on the fly,” without the need for recompilation and so without the need to shut down the applications. Sensing those two languages’ potential, Ordinal Software chose them back in 2000, when it launched its COOX developments and platform. That choice has proven to be the right one, in view of the expansion of those programming languages in recent years, providing extra security and longevity to our client manufacturers.
