Datatex Magazine | Programming languages. Technical choices and trends
When we talk about programming languages, we have to deal with two sides: those who deem it suitable to use only Java languages today and those who defend the “solidity” of old languages and consider the current trends a sort of “fashion trends” with no particular technical justifications.
technology, textile, apparel, erp solutions, programming, technical languages
4215
post-template-default,single,single-post,postid-4215,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,qode_popup_menu_push_text_top,vss_responsive_adv,qode-child-theme-ver-1.0.0,qode-theme-ver-10.1.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive

Programming languages. Technical choices and trends

Article by Roberto Mazzola – Datatex IT Chief Technology Officer

Edited by Luigi Torriani and Milena Guzzinati

When we talk about programming languages, we have to deal with two sides: those who deem it suitable to use only Java languages today and those who defend the “solidity” of old languages and consider the current trends a sort of “fashion trends” with no particular technical justifications.

It is true that the quality of a programming language does not depend on how recent this language is, but on the other hand, it is doubtless that the most recent languages are rightly oriented towards new worlds (web, artificial intelligence, machine learning, etc) and are more apt to face new problems and issues. But this does not mean to consider them as superior for each contest to the previous languages.

The main point is that the choice of a programming language is linked to the context and to our main goals. Which is the best language now? I think it does not exist. If I have to face a Machine Learning project, for instance, the old COBOL or RPG are not the most suitable tools. But if we think about our daily activities, whenever we withdraw at the ATM or pay with our credit card, we find out that this path leads to the IT systems of the bank that are often processed by COBOL, a system that in this context makes perfect sense.

On the other hand, also in Datatex we are still using with several satisfied customers some applications developed 30 years ago with RPG (I am talking about our historical ERP system TIM). In these cases, the core of the application is still the same, sometimes it is sided by a more modern browser interface (even if, to be honest, some users miss the old green screens!).

However, at a certain point Datatex made a very clear choice, that is to develop with Java J2EE, and today our top product is NOW ERP, which is a 100% web-based software, installed in 46 countries and one of the world best-selling vertical ERP for the textile and apparel industry.

Why did we choose to develop using Java and why is the market rewarding this choice? Fans  of  the older languages may consider a successful choice of new languages, a matter of marketing trends rather than concreteness.

Actually, this is not true, but rather the contrary: the choice of Java by Datatex is linked above all to the need – in future prospective and looking forward in the long term – to give maximum longevity to our solutions, beyond fashions and passing trends.

Moreover, since Datatex’ decision to develop a web-based ERP dates back to the early 2000s and at the time it was a decision with an uncertain outcome, Datatex made a winning choice by anticipating the evolution of the ERP world.

We need to consider that Datatex does not develop small ad-hoc solutions with limited time use, but creates a complete ERP that requires significant investments by customers and that has to guarantee the full reliability and complete support for decades. How is it possible to assure this hold on the long term?

There is only one way: programming in a web multiplatform language, fully independent from the platform and from the used machinery (that is “java” for the core, along with other suitable languages, such as JavaScript for the front end, etc.)

The IT Managers who are still connected to the old languages often underrate what may happen if they were forced to change the platform, a situation that can occur for several reasons (new company owners and new choices, or new market evaluations by the corporate who manages the platform, etc…). If something like that happens, cases based on old languages have to face a complex and expensive transition, while those who work with a multiplatform solution, 100% web-based product as NOW ERP by Datatex, will never have to deal with this type  of problem.

The portability of the solutions on any platform (following the slogan “write once, run anywhere/everywhere”) has been the final goal of Java since the beginning. It was also the goal of IBM, that in the second half of the Nineties tried – then decided to put the project on hold – to promote a new “java based” solution (the so-called IBM San Francisco framework).

Planning a multiplatform web-based language today does not mean to follow a “fashion”, but – on the contrary – it means to us the ability to create something that can be elegant ad usable over the years, just like a Giorgio Armani garment.

The choice of Java (JakartaEE), moreover, assures continuity for the future (Microsoft is also investing in Java today). Gartner in 2016 created a report where he forecasted that the JavaEE platform wouldn’t have been able to keep up with the evolution of the IT world, but it was a wrong forecast. In fact, after a period of reorganization, the specifics of JakartaEE9 and 9.1 have been released and they are working on version 10, which attributes a very significant role to the Cloud.

In addition, the simple “Java” is not enough, it is only a very good base. Then, in order to implement some “languages” or tools, to ease the applicative development, it is important to have a series of services that the programmer to focus on the applicative solution rather than deal with numerous technical aspects.

Hence, a  distinction has to be recognized between the programming language and other frameworks built on that language to further simplify the development phases. To make an example: JavaScript is a language, but there are many frameworks on top as Node.js, Angular and React.js. datatex decided to exploit ExtJs for the front end of (on which we invetsed further tailor it to our needs), but we also use Node.js and React Native for the development of cross-platform Apps.

Our final goal is to make the life of a programmer easier: faster in the development but also faster in adapting the software to the client’s needs, in a simple and reliable way. In order to fully satisfy the final user, and consider the need for a user-centric solution, to make the user-friendliness feeling of the product really high, Java is not enough. For example, for all the front-end parts, the ideal solution is a combination HTML/CSS/JavaScript with multitude frameworks on top (in our case ExtJS of Sencha but also others context-based).

That was not sufficient! We were not satisfied with all this: we also decided to create another level of abstraction to further help our programmers to focus on the business and not on the technology. Surely there is always something new to learn, and maybe this is the best part of our job, the continuous improvement so we never get bored, updating our solutions  with the new technologies .This process is costly and requires a great amount of continuous training,in order to minimize these costs, we developed our own language – ABSolution by Datatex (the 9000 existing program languages were not enough, we wanted the 9001!). To be precise ours is a metalanguage, which is a language that allows defining other languages and, in our case, generating Java code (currently following the specifics Java EE/Jakarta EE8. This helps Datatex to keep up with the evolution of architectures: going through migrations from the very first versions of J2EE to Jakarta EE only by redefining the generation rules of our metalanguage to Jakarta EE! To us, this also means not only a guarantee of the quality of the software and the uniformity of the standards, but keeping the strengths of Java (and its enterprise version) for the whole backend. While for the front-end we are mainly based on visual patterns (that are constantly evolving, with the implementation of new patterns) always in the view of masking the technological complexity to the programmer and delegating it all to our engine developed with JavaScript and the related frameworks. Always with an eye toward the possibility of integrating with the surrounding world.