Le prochain langage

Voir la version originale en ligne





Afin de limiter les retours de flamme qui ne manqueront pas de se produire, je voudrais préfacer ce document en annonçant que j'ai commencé à programmer en Java en 1995, et je l'ai pratiqué par périodes depuis presque 9 ans. J'ai participé à deux startups Java (j.rad et NetDynamics), et j'ai travaillé chez Sun Microsystems, pendant 5 ans, sur des projets tels que Sun ONE et Liberty. Par conséquent, je connais bien le sujet Java. Ce document s'appuie sur les hypothèses suivantes :


    

  • Le serveur d'application futur est une grosse pompe à textes.
    • 

  • La technologie des « Web Services » qui va dominer la communication inter-applications.
    • 




Evolution des systèmes et des langages d'entreprise




Java entre dans la catégorie des « langages d'entreprise », ce terme recouvrant les langages et les sytèmes utilisés par les entreprises pour gérer leur activité. Pour comprendre comment les langages d'entreprise évoluent, il est important de considérer parallèlement l'évolution des plateformes matérielles. Ces plateformes sont passées des architectures centralisées (mainframes) aux mini-ordinateurs, dans le cadre d'applications clients-serveurs, à l'Internet, et actuellement, aux architectures « grille » (grid-computing), en mettant en parallèle des « boites blanches » Linux.




A chaque étape de cette évolution, un acteur dominant a émergé, ainsi que le montre le diagramme suivant :




Au fur et à mesure de cette évolution, les langages d'entreprise avaient, eux-aussi, tendance à évoluer.




Les heures de gloire eurent lieu pendant la période client-serveur, qui a vu naitre nombre de langages très populaires tels que le Visual-Basic, Delphi (un dérivé de Pascal), PowerScript de PowerSoft, et bien d'autres. Ces langages étaient pour la plupart peu typés et étaient essentiellement pseudo-interprétés (Ndt : ce n'est pas le cas de Delphi).




Ils ont tous été remplacés par Java, un langage fortement typé, pseudo-interprété, et .Net, qui est faiblement typé, et, lui aussi, pseudo-interprété.




Pendant l'ère Internet, les entreprises ont utilisé des systèmes d'exploitation de puissance moyenne tels que Solaris, AIX, HP-UX, Irix, et Windows-NT. Un enjeu important était celui de la portabilité de leurs applications sur tous ces systèmes, afin d'éviter d'être dépendant d'un seul éditeur. Dès lors qu'une entreprise se limitait à une seule de ces plate-formes, l'éditeur la grugeait à la prochaine mise-à-niveau, car elle était devenue captive.




Le langage Java, ainsi que ses bibliothèques d'exécution étaient totalement portables, et ainsi Java a été conçu pour fonctionner, d'abord sur des plate-formes de haute performance, et ensuite sur des PC. Il a relevé ce défi de portabilité.




Certaines sociétés commençèrent alors à utiliser Java en mode serveur avec NetDynamics, ou Kiva. En supplément, Java proposait des caractéristiques qui avaient fait les beaux jours des langages de la génération client-serveur, tels que la récupération automatique d'espace mémoire (ramasse-miettes), ainsi que des interfaces de programmation de haut niveau avec les systèmes d'exploitation qui en cachaient la complexité.




Java a également bénéficié d'une masse critique d'éditeurs le supportant : tout ce qui existe sous le soleil possède tôt ou tard une interface programmatique en Java, y compris chez oracle, SAP, Tibco, CICS, MQSeries, etc… Tous ceux là furent rapidement accessibles au moyen d'interfaces normalisées, ces interfaces devinrent J2EE, et J2EE domina l'informatique d'entrerprise.




Ce que Java n'a pas réalisé, ce sont des outils de type L4G, mais, à l'époque, personne n'avait proposé d'environnement L4G pour réaliser des applications Web. On en a fait fi, tout en espérant leur arrivée. Les années passèrent, et la majorité des applications J2EE étaient toujours faites à la main.




Il y a là une leçon que Microsoft a bien retenue : pour que des interfaces de programmation (API) puissent être associées avec des outils de développement, ces interfaces doivent être développées simultanément avec ces outils (Ndt : voyez l'exemple de Delphi, c'est le premier langage qui proposait des pointeurs sur des méthodes d'objet et des propriétés visuelles, qui interagissaient avec l'environnement de développement et remarquez que c'est Anders Hejlsberg l'architecte de Delphi qui a par la suite conçu .Net) , outil et API se référant l'un et l'autre à un seul méta-modèle facilement externalisable.




Les API de Java ont toujours été déterminées pour elles-mêmes, et les outils qui en ont découlé - principalement des générateurs de code - ont été soigneusement évités par les programmeurs. Elles devinrent un ensemble confus contradictoire et incompréhensible, et les choses les plus simples se sont avérées complexes.




L'essentiel (80% selon Gartner) des développements serveur en Java se réduisit à des applications servlet-jsp-jdbc, c'est-à-dire des façades HTML à des bases des données. Ironiquement, ce sont les nombreuses extensions qui ont été ajoutées à Java pour le rendre plus simple d'utilisation, les extensions JSP notamment, qui ont complexifié le langage.




Malgré tout cela, c'est encore Java qui reste en tête dans le domaine de l'informatique d'entreprise.




La Grille : Linux et les « Web Services »




L'industrie est actuellement dans une phase de transition, où elle passe de systèmes Unix propriétaires s'exécutant sur des plate-formes multi-processeurs, à de grandes « grilles » de machines à un ou deux processeurs sous Linux. Ce type de machines dominait déjà le marché du serveur Web frontal, et maintenant, il s'apprête à occuper la place de serveur d'infrastructure, avec des produits tels que Oracle RAC, la version grid d'Oracle. Ce phénomène gagne le maillon intermédiaire, en étant toutefois freiné par le fait que les applications J2EE sont conçues pour fonctionner sur des petits ensembles de serveurs multi-processeurs, plutôt que sur de grands ensembles de machines uni-processeurs.




De plus, la question de la portabilité n'est plus la question du jour, les entreprises ne se sentent plus prisonnières, maintenant qu'elles installent leurs applications dans une « boite blanche » Linux équipée avec un preocesseur x86. Cependant, dans beaucoup d'entreprises, la contrainte de compatibilité avec Windows existe, et se résume souvent à la possibilité de développer sous Windows, mais de déployer sous Linux.




Les applications d'entreprise actuelles produisent essentiellement du texte, que ce soit du texte HTML destiné à un navigateur, ou du texte XML des tiné à une application tierce.




Par conséquent, quelles peuvent êtres les contraintes soumises aux applications d'entreprise actuelles :



    

  • Prise en charge d'XML (données et typages dynamiques)
    • 

  • Transformation rapide d'objets vers du texte, et réciproquement
    • 

  • La plupart des applications ont une logique métier pauvre, se résumant souvent à un contrôle de flux.
    • 

  • Pas de nécessité de portabilité, hormis Linux et Windows.
    • 

  • Pas de couche sytème abstraite importante, qui pénaliserait les performances.
    • 

  • Optimisation pour des machines à un ou deux processeurs x86
    • 




Java n'est pas excellent à cet égard…



    

  • Xml est foncièrement non structuré et difficilement introduit ou extirpé de Java, langage fortement typé, qui n'aime pas que de nouveaux types d'objets lui « sautent dedans ».
    • 



    

  • Java ne traite les données textuelles qu'avec horreur, car il ne peut manipuler directement les chaînes de caractère.
    • 



    

  • Alors que Java est excellent pour les applications complexes, il n'est pas taillé pour le contrôle de flux.
    • 



    

  • Java est une plateforme portable magique, mais il n'y a plus de nécessité de portage hors Linux et Windows.
    • 



    

  • Puisqu'il n'y a plus de contrainte de portabilité, les développeurs veulent s'en tenir à une mince pellicule entre l'application et le système, telle que les sockets, alors que Java propose une énorme machine virtuelle.
    • 



    

  • La plupart des implémentations J2EE sont optimisées pour des machines équipées de 4 à 16 processeurs.
    • 




Si Java ne satisfait pas à ces contraintes, que faire ? Ce qui est nécessaire, apparemment, c'est langage, un environnement faiblement typé qui soit en mesure d'encapsuler facilement XML et de traiter facilement le texte. Il doit aussi être excellent pour spécifier le contrôle de flux. Et il ne doit présenter qu'une légère couche d'interface avec le système d'exploitation.




La plupart des distributions Linux sont, en fait, livrées avec trois langages qui correspondent à ces critères : PHP, Python, et Perl.




PHP est en fait le plus populaire, Python est considéré comme le plus élégant (sinon difficile), et Perl comme un bon cheval de trait qu'on essaie et qu'on adopte immédiatement.




Tous ces langages sont libres et open-source. Ainsi que le montrent les graphiques ci-dessous, l'utilisation de PHP a explosé ces dernières années.




PHP est actuellement trois fois plus populaire que JSP en termes de statistiques d'URL :




PHP, Perl, et Python sont encore peu matures en termes de bibliothèques logicielles d'entreprise, et leurs capacités en termes de « Web Services » ne sont que naissantes. Cependant, ils ont tous les ingrédients nécessaires pour répondre aux besoins de la génération de « pompes à texte » qui est à venir.




PHP, Perl et Python sont :



    

  • Bien adaptés pour des données peu structurées telles qu'XML.
    • 

  • Incroyablement optimisés pour le traitement des textes.
    • 

  • Très bien adaptés au contrôle de flux.
    • 

  • Très bien adaptés adaptés aux systèmes Linux/x86 et Windows/x86
    • 

  • Près du « métal », étant données leurs origines en tant que langage de script Unix
    • 

  • Adaptés pour des machines à 1 ou 2 processeurs x86.
    • 




En plus d'être gratuits et open-source, ces langages sont faciles à apprendre et à utiliser. Les « P » sont promis à emboîter le pas à Linux et Apache, et à faire de larges intrusions dans le marché des entreprises. La dernière version de PHP est virtuellement identique à Java, y compris les mots-clés et la syntaxe.




Une remarque à propos de .NET : Microsoft a créé X#, un langage natif XML pour l'environnement d'exécution CLR (Common Language Runtime). Visual Basic est le langage de script le plus populaire au monde. Et, comme nous le savons, Windows est bien adapté aux machines à 1 ou 2 processeurs. Ainsi, Microsoft sera de la partie, et il y aura probablement une troika composée de .NET, Java, et PHP/Python/Perl.