Envisageriez-vous de développer avec Perl ?
L a communauté informatique a découvert Linux il y a six mois, puis s'est rendu compte de l'importance d'Apache (le serveur HTTP le plus utilise sur l'Internet) il y a deux mois quand IBM a décidé de l'intégrer à son offre Web Sphere (*)... Il ne lui reste plus qu'a réaliser que le langage de scripting Perl (Practical Extraction and Report Language) est l'élément qui complète le mieux le couple vedette Linux/Apache et qu'il deviendra, en outre, le principal langage de développement du Web.
Ce qui me permet d'affirmer cela avant tant d'assurance, c'est que Perl remplit déjà ce rôle avec succès depuis quatre ans Des 1994, ce langage a gagné les faveurs des premiers bâtisseurs de sites Web importants. Plus a l'aise que le C lors de manipulations de chaînes de caractères, Perl s'est impose comme le langage de prédilection pour les traitements Web côte serveur qui produisent essentiellement des pages HTML par manipulation de texte Ascii Perl est par ailleurs un logiciel libre, dont le développement est le fruit d'un effort communautaire. C'est un langage interprété et son interpréteur est disponible sur un vaste éventail de plates-formes serveurs.
Bien que rapide, Perl traîne une réputation de performances médiocres. Cette image dégradante vient de l'interface CGI, qui permet de déclencher des traitements extérieurs au serveur Web a proprement parler, mais qui se révèle peu économe en ressources. Mais c'était à l'époque la seule passerelle disponible, cc qui explique son utilisation systématique pour lancer des traitements Perl.
Désormais, il est injuste de continuer à associer les deux technologies, d'abord parce qu'on a toujours pu écrire des programmes CGI dans une grande variété de langages, ensuite parce que les scripts Perl destinés au Web peuvent être directement exécutés par certains serveurs Web eux-mêmes... En l'occurrence, cela est possible si l'on a recours à Apache, qui offre cette particularité de fonctionnement fort utile et performante ! Voilà au passage démontrée la complémentarité entre Apache et Perl.
Fruit du travail acharne de Lary Wall (comme Linus Torvald le fit pour Linux), Perl a pris maintenant une dimension qui va bien au-delà des possibilités de son créateur. Les nombreux développements tiers autour du langage, tels que les bibliothèques de fonctions spécialisées pour l'accès à des serveurs SQL, en attestent. Et son caractère "libre" ne l'exclut pas pour autant de la sphère commerciale...
Au contraire, depuis quelques mois, les offres complémentaires fleurissent autour de ce langage qui gagne en popularité. Les studios de développement graphique spécialisés dans Perl n'ont rien a envier à leurs homologues propriétaires comme Haht Site ou a ceux spécialisés dans la production de code Java. On trouve même des environnements d'exécution qui proposent des fonctionnements distribués pour dépasser les limites de l'interpréteur d'origine !
Face aux solutions concurrentes, ASP de Microsoft ou Java de Sun, quels avantages présente-t-il ? Par rapport aux ASP de Microsoft, il présente justement l'intérêt de ne pas provenir de l'éditeur de Redmond et d'être donné capable de tourner sur la plupart des systèmes serveurs qui comptent. Il ne s'agit pas d'une vague promesse façon Java, c'est en fait prouve depuis des années. Et face a Java, qui semble enfin décoller côte serveur grâce aux EJB (Enterprise Java Beans). Ecrire du Perl est bien plus simple que d'écrire du Java et le premier est encore bien plus rapide que le second a plate-forme égale...
Bref on 1'aura compris, Perl ne prétend pas changer le monde du développement. Mais si vous prévoyez de développer pour le Web, a ors ce langage est à considérer sérieusement (y compris et surtout du côte de son offre commerciale qui se développe rapidement), particulièrement si vous comptez utiliser ses " cousins " Apache et Linux...
(*) Il est intéressant de revenir sur les circonstances qui ont conduit IBM à choisir le serveur HTTP Apache, alors qu'il était en discussion avec Netscape. Ce dernier se serait montre trop gourmand, incitant Big Blue à se tourner vers Apache... Le plus difficile pour IBM aurait été de convaincre ses propres juristes d'accepter de finaliser un accord avec une entité (le groupe Apache) qui n'a pas d'autre preuve tangible de son existence que son site Web !
Alain Lefebvre - SQL INGENIERIE
|