> Tech > Les problèmes d’EGL

Les problèmes d’EGL

Tech - Par Renaud ROSSET - Publié le 30 novembre 2010
email

Mais, pour moi, EGL pose deux problèmes : premièrement, il est propre à un fournisseur : c’est un produit IBM commercial. Or je n’aime pas me lier à un langage spécifique à un fournisseur. Si vous vous intéressez à EGL, considérez aussi d’autres produits de développement tiers, comme ceux

Les problèmes d’EGL

de Lansa et BCD. (En revanche, PHP est un langage open-source.)

L’autre problème d’EGL concerne la documentation et la formation. Il existe toutes sortes d’outils de formation pour Java/.NET/Groovy/PHP : livres, articles, etc. Mais très peu de tout cela pour EGL. Vous ne trouverez pas sur Google la solution à un problème EGL. Alors qu’il est très facile d’interroger Google à propos de Java/.NET/Groovy/PHP et trouver une solution sans recourir aux multiples livres et talents disponibles sur Java/.NET/Groovy/PHP.

Le second problème est qu’EGL est étroitement couplé à JSF (Java Server Faces) ; EGL utilise JSF comme couche de présentation. J’ai déjà dit que la syntaxe d’EGL était facile à apprendre. Je n’en dirai pas de même de JSF, trop sophistiqué pour le développement HTML.

Cela dit, j’avoue un certain penchant pour JSF (voir « Introduction to Java Server Faces », février 2008, article ID 21164). Il fonctionne vraiment bien dans 95 % des cas, mais si vous voulez changer son comportement ou si vous obtenez des erreurs énigmatiques, il faudra beaucoup de temps pour trouver la solution. Mais vous pouvez trouver une solution JSF sur Google. Et JSF, contrairement à EGL, est un standard et jouit donc d’une riche documentation. Groovy et Ruby sont dits langages déclaratifs, tandis que Java, C et RPG sont des exemples de langages impératifs.

Selon Wikipedia, « Les programmes impératifs spécifient explicitement un algorithme pour atteindre un but, tandis que les langages déclaratifs spécifient explicitement le but et laissent au logiciel de support le soin d’appliquer l’algorithme ». Des langages déclaratifs, tels que Prolog et Python, existent depuis un certain temps, mais Ruby est le premier à s’être imposé sur le marché. Au point d’être au onzième rang sur l’index TIOBE.

Il est beaucoup plus rapide de développer une application dans un langage déclaratif et expressif tel que Ruby, que dans des langages comme RPG ou Java. Et nous ne saurions parler de Ruby sans mentionner RoR (Ruby on Rails). RoR est un framework Web qui réduit considérablement le temps de développement, mais n’est pas encore prêt pour le prime time sur le System i. Mais comme le dit Tim Massaro dans « What Gems Does Ruby on Rails Offer ? » (Quels joyaux Ruby on Rails offre-t-il?) (www.itpro.fr Club abonnés), pour les développeurs System i, Ruby on Rails natif pointe à l’horizon. Groovy et le framework de développement Web Grails (GoG) sont prêts pour le System i. Groovy se compile en code byte Java, et donc tournera sur n’importe quelle JVM. Par ailleurs, contrairement à RoR, GoG est compatible avec les anciennes bases de données, et les applications GoG tourneront sur votre System i actuel. GoG est prêt à prendre la vedette sur le System i parce qu’il se sert des frameworks Java standard tel que Spring et Hibernate. Groovy possède la plupart des fonctions de Ruby, ainsi que d’autres inspirées par des langages déclaratifs comme Python et Smalltalk. Bien que l’arrivée de Groovy 1.0 ne remonte qu’à janvier 2007, il a déjà grimpé à la 31ème place de l’index TIOBE. J’ai constaté des gains de productivité de 200 à 500 % avec GoG par rapport à Java et à des frameworks Java.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental

Tech - Par Renaud ROSSET - Publié le 30 novembre 2010