Dossier System i : Au-delà  de RPG : Réfléchissez bien aux différentes options (2/3)

Pour comparer RPG à des langages plus récents – particulièrement en matière de ASCII I/O, manipulation XML, courriel, services Web et traitement TCP/IP – il faut considérer l’API C RPG. Et, pour bien utiliser l’API C, mieux vaut être programmeur C.

Je considère qu’utiliser les API C avec RPG est plus difficile que d’intégrer RPG à Java ou à des langages alternatifs. En effet, il faut être programmeur système pour écrire des routines RPG comparables à Java/PHP/Groovy/.NET. Avezvous cette perle dans vos murs ?

Souvent, les programmeurs système travaillent en interface avec d’autres langages, plutôt que de franchir l’obstacle de l’API C RPG. N’était-ce la poignée d’assistants RPG fournissant des utilitaires RPG, comme l’API RPG HTTP de Scott Klement, voilà déjà plusieurs années que beaucoup de sites auraient été obligés de passer par-delà RPG. J’ai personnellement perdu plusieurs piges de consultation Java (j’espère que mon boss ne lit pas ceci), pour avoir fait part aux clients des alternatives RPG de Klement.

Mais ce n’est pas parce qu’on peut faire quelque chose qu’il faut forcément le faire. Le code Java/PHP/Groovy/.NET équivalent pour I/O ASCII, manipulation XML, courriel, services Web, traitement TCP/IP, c’est beaucoup moins de code et un code beaucoup facile à maintenir. WDSc (WebSphere Development Studio client) – à présent RDI – a fait beaucoup de chemin, mais il n’en demeure pas moins que le processus de développement RPG est moins bon qu’avec d’autres langages. Mais vous ne souscrirez à cette affirmation qu’après être devenus productifs avec d’autres langages. WDSc améliore le processus de développement, mais il n’est pas encore à la hauteur. En raison de l’emplacement du source sur le serveur, WDSc est encore lent à ouvrir des fichiers et le processus de compilation d’édition est lent lui aussi. Quand je code des F- et D-specs, j’ai encore présente à l’esprit mon antique machine à cartes perforées.