Dossier RPG : Modern RPG (1/2)

Aujourd’hui, nous sommes dans un monde totalement différent. Toute critique adressé au langage RPG devrait viser le RPG du siècle dernier – qui inclut RPG/400, et aussi RPG IV écrit dans le même style que RPG/400. Si le code que vous écrivez aujourd’hui ressemble de près à celui que vous avez écrit voilà dix ans, il est temps de repenser la question. Le langage RPG IV a bénéficié d’améliorations significatives dans chaque release d’i5/OS, et IBM l’a parfaitement tenu à jour. Avec le RPG actuel, vous pouvez écrire un code modulaire, cohérent, bien encapsulé. Le langage n’est pas démodé … contrairement à beaucoup des développeurs qui l’utilisent. RPG n’est pas le problème : ce sont plutôt les développeurs complaisants.

Une application orientée gestion vaut non par le langage dans lequel elle est écrite mais par les objectifs de gestion qu’elle permet aux utilisateurs d’atteindre. Après avoir écrit des applications dans plus de vingt langages de programmation différents (y compris Java, PHP et divers langages Microsoft), j’ai appris que, à un haut niveau, tous ces langages se ressemblent beaucoup. Certes la syntaxe peut être différente, mais les concepts de développement d’un programme sont les mêmes et donc le choix entre tel ou tel langage ou tel langage se fonde surtout sur des points techniques. Cela dit, je m’empresse d’ajouter que le considère RPG comme le meilleur langage pour écrire des règles de gestion. Passons donc en revue les principaux ingrédients d’un langage de gestion :

• accès aux bases de données • calculs basés sur des nombres décimaux (quantités, poids, valeurs monétaires)
• calculs basés sur des dates (d’échéance, de livraison, de paiement, etc.)
• manipulation de chaînes de caractères
• agilité (c’est-à-dire l’aptitude à évoluer en même temps que l’activité)

RPG a toujours excellé en accès bases de données. Son I/O d’enregistrement natif est sans égal dans l’industrie. Il prend très bien en charge SQL, de manière simple et puissante.

Pour ce qui est des nombres décimaux, rappelons la différence entre le décimal et la virgule flottante. Les nombres à virgule flottante peuvent stocker des valeurs fractionnaires, mais très différemment d’un vrai nombre décimal. Les nombres à virgule flottante sont stockés sous la forme d’une fraction binaire et d’un exposant binaire. Chaque fois que vous réduisez un nombre à une fraction et un exposant, vous risquez une erreur d’arrondi, particulièrement quand les nombres deviennent de plus en plus élevés. La virgule flottante est intéressante dans des applications scientifiques, mais en gestion la précision de vrais nombres décimaux est importante. RPG a toujours pris en compte l’arithmétique décimale via les types de données décimales, condensées (packed) et zonées. En V3R1, leur utilisation est devenue beaucoup moins scabreuse grâce à l’introduction des expressions. Si vous utilisez encore les anciens opcodes ADD, SUB, MULT et DIV, vous êtes à côté de la plaque !

La même release (V3R1) a introduit les dates, les heures, les horodateurs, et de meilleures opérations sur les chaînes. Les opérations sur les chaînes de RPG/400 étaient calamiteuses, mais RPG IV a changé cela. Les opérations sur les chaînes, ainsi que les dates et expressions, se sont même améliorées avec l’introduction de la syntaxe en format libre en V5R1. Le dernier élément qui nous cause des ennuis est le dernier ; et c’est là que trébuchent tous ceux qui n’actualisent pas leurs compétences. Si vous ne savez pas comment utiliser les concepts ILE pour créer des routines bien encapsulées divisées en programmes de service cohérents, il est probable que le code que vous créez aura du mal à suivre les changements de l’activité. Une bonne encapsulation n’a pas pour seul effet de réduire la quantité de code à changer quand l’activité change. Elle réduit également la quantité d’analyse nécessaire pour déterminer ce qui doit changer ! D’ailleurs, apprendre à utiliser les sous-procédures pour encapsuler votre code est peut-être la priorité pour écrire un code RPG moderne.