En particulier, l'équipe principale de développement (connue sous le nom 'Perl Porters') est une bande hétéroclite d'individus des plus altruistes engagés à faire un logiciel gratuit meilleur que tout ce que vous pourriez trouver dans le commerce. Vous pouvez glaner des informations sur les développements en cours sur news://news.perl.com/perl.porters-gw/ et l'archive Deja sur http://www.deja.com/ en utilisant le groupe perl.porters-gw, ou vous pouvez vous inscrire à la liste de diffusion en envoyant une demande d'inscription à perl5-porters-request@perl.org .
Bien que le projet GNU inclue Perl dans ses distributions, il n'y a pas à proprement parler de ``GNU Perl''. Perl n'est pas produit ni entretenu par la Free Software Foundation. Les termes de la licence de Perl sont aussi moins restrictifs que ceux de la licence GNU.
Vous pouvez obtenir une assistance commerciale pour Perl si vous le souhaitez, mais pour la plupart des utilisateurs, une assistance informelle devrait être largement suffisante. Regardez la réponse à question ``Où acheter une version commerciale de perl'' pour de plus amples informations.
La version 5.0 est essentiellement une réécriture complète à partir de la base du code source original de perl de la version 1 à la version 4. Il a été modularisé, orienté objet, ajusté, élagué, et optimisé jusqu'à ce qu'il ne ressemble plus à l'ancien code. Cela dit, l'interface est quasiment la même, et la compatibilité avec les versions précédentes est très grande. Voir ``Les Pièges entre Perl4 et Perl5'' in perltrap.
Pour éviter la confusion "quel est le langage perl5 ?``, certains préfèrent parler simplement de ''perl`` pour se référer à la dernière version de perl, plutôt que d'employer le terme ''perl5" en entier. C'est sans grande importance de toute manière.
Voir perlhist pour un historique des révisions de Perl.
Si vous êtes un expert de C++ travaillant dur maîtrisant parfaitement les entrailles de Perl, et que vous aimeriez travailler sur le projet, envoyez une demande à perl6-porters-request@perl.org pour vous inscrire à la liste de diffusion Topaz.
Topaz n'a pas de délai à respecter. On s'attend à ce que plusieurs années s'écoulent avant qu'il n'atteigne une robustesse, une compatibilité, une portabilité et des performances suffisantes pour remplacer perl5 dans un usage ordinaire de simples mortels.
Larry et l'équipe de développement Perl font occasionnellement des changements dans le noyau interne du langage, mais tous les efforts possibles sont déployés pour assurer la compatibilité descendante. Bien que quelques scripts perl4 ne tournent pas impeccablement sous perl5, une mise à jour de perl ne devrait presque jamais invalider un programme écrit pour une version plus ancienne. (exception faite des corrections de bugs accidentels et des rares nouveaux mots réservés).
La plupart des tâches ne requiert qu'un petit sous-ensemble du langage Perl. Une des idées phares en matière de développement Perl est : ``Il y a plus d'une façon de procéder''. La courbe d'apprentissage de Perl est étroite (facile à apprendre) et longue (il y a beaucoup de choses faisables si vous le voulez réellement).
Enfin, puisque Perl est souvent (mais pas toujours, et certainement pas par définition) un langage interprété, vous pouvez écrire vos programmes et les tester sans phase intermédiaire de compilation, vous permettant ainsi d'expérimenter et de déboguer/tester rapidement et facilement. Cette facilité d'expérimentation aplatit encore plus sa courbe d'apprentissage.
Les choses qui facilitent l'apprentissage de Perl sont : l'expérience d'Unix, quasiment n'importe quelle expérience de la programmation, une compréhension des expressions rationnelles, et la capacité de comprendre le code des autres. S'il y a quelque chose que vous avez besoin de faire, elle a probablement été déjà faite, et un exemple fonctionnant est généralement disponible gratuitement. N'oubliez pas non plus les modules perl. Ils sont abordés dans la partie 3 de cette FAQ, et avec le CPAN dans la partie 2.
La meilleure chose à faire est certainement d'essayer d'écrire le code équivalent dans plusieurs langages pour accomplir un ensemble de tâches. Ces langages ont leurs propres newgroups dans lesquels vous pouvez en apprendre plus (et non, espérons le, vous disputer) sur eux.
Des comparatifs se trouvent sur http://language.perl.com/versus/ si vous ne pouvez vraiment pas vous en passer.
Si vous avez une bibliothèque fournissant une API, vous pouvez en rendre n'importe quel composant disponible comme une fonction ou une variable Perl supplémentaire en utilisant une extension Perl écrite en C ou C++, et dynamiquement liée dans votre interprêteur perl principal. À l'opposé, vous pouvez également écrire votre programme principal en C/C++, et ensuite lier du code Perl au vol pour créer une puissante application. Voir perlembed.
Ceci dit, il y aura toujours des langages dédiés à une classe de problèmes qui sont tout simplement plus pratiques. Perl essaye d'être tout à la fois pour tout le monde, mais rien de précis pour personne. Les exemples de langages spécialisés qui viennent à l'esprit comptent prolog et matlab.
En fait, une bonne raison pour ne pas utiliser Perl est d'avoir une application déjà existante écrite dans un autre langage qui est toute faite (et bien faite), ou si vous avez une application conçue pour une tâche spécifique dans un langage particulier (i.e. prolog, make)
Pour des raisons variées, Perl n'est probablement pas bien adapté pour des systèmes embarqués temps-réel, des développements systèmes de bas niveau, des travaux comme des pilotes de périphérique ou du code à commutation de contexte, des applications parallèles complexes en mémoire partagée, ou des applications très grandes. Vous remarquerez que perl n'est pas lui-même écrit en Perl.
Le nouveau compilateur Perl de code natif peut éventuellement réduire ces limitations jusqu'à un certain degré, mais comprenez que Perl reste fondamentalement un langage à typage dynamique, et non à typage statique. On ne vous en voudra pas si vous ne lui faites pas confiance pour un code de centrale nucléaire ou de contrôle de chirurgie cérébrale. Larry en dormira d'autant mieux - en ne tenant pas compte des programmes de Wall Street. :-)
Originellement, un script était une séquence en boîte de commandes interactives normales, c'est-à-dire un script de chat. Une chose telle qu'un script de chat UUCP ou PPP ou un script expect est plutôt conforme à cette description, tout comme les scripts de configuration exécutés par un programme lors de son lancement, comme .cshrc ou .ircrc, par exemple. Les scripts de chat étaient juste des pilotes pour des programmes existants, et non pas des programmes indépendants.
Un scientifique de l'informatique expliquera convenablement que tous les programmes sont interprétés, et que la seule question qui se pose est à quel niveau. Mais si vous posez cette question à quelqu'un d'autre, il pourra vous dire qu'un programme a été compilé une seule fois pour devenir du code machine physique, et peut alors être exécuté plusieurs fois, tandis qu'un script doit être traduit par un programme à chaque fois qu'il est utilisé.
Les programmes Perl ne sont (habituellement) ni strictement compilés, ni strictement interprétés. Ils peuvent être compilés sous la forme d'un pseudo-code (pour une sorte de machine virtuelle Perl) ou dans un tout autre langage, comme du C ou de l'assembleur. Vous ne pouvez pas dire juste en le regardant si la source est destinée à un interpreteur pur, un interpréteur d'arbre syntaxique, un interpréteur de pseudo-code, ou un compilateur générant du code machine, donc il est délicat ici de donner une réponse définitive.
Maintenant que ``script'' et ``scripting'' sont des termes ayant été abusés par des marketeux sans scrupules ou ignorants pour leur propre bénéfice infâme, ils ont commencé à avoir des significations étranges et souvent péjoratives, comme ``pas sérieux'', ou ``pas de la vraie programmation''. Par conséquent, certains programmeurs Perl préfèrent totalement les éviter.
Des exemples plus récents peuvent être trouvés en fouillant dans les messages de Larry postés sur l'Usenet :
http://x1.dejanews.com/dnquery.xp?QRY=*&DBS=2&ST=PS&defaultOp=AND&LNG=ALL&format=terse&showsort=date&maxhits=100&subjects=&groups=&authors=larry@*wall.org&fromdate=&todate=
Si vous avez un projet avec des impératifs, notamment en termes de portabilité ou de tests, Perl devrait certainement apporter une solution rapide et viable. En plus de tout effort de persuasion, vous ne devriez pas manquer de montrer que Perl est utilisé, assez intensivement et avec des résultats solides et fiables, dans de nombreuses grandes entreprises informatiques (logiciel ou matériel) à travers le monde. En fait, de nombreux vendeurs d'Unix livrent maintenant Perl en standard, et les newgroups apportent l'assistance nécessaire si vous ne trouvez pas la réponse dans la documentation détaillée, y compris cette FAQ.
Voir http://www.perl.org/advocacy/ pour plus d'informations.
Si vous êtes confronté à des réticences pour mettre à jour une version antérieure de perl, insistez sur le fait que la version 4 n'est plus entretenue ni suivie par l'équipe de développement Perl. Un autre argument de taille en faveur de Perl5 est le grand nombre de modules et d'extensions qui réduisent considérablement le temps de développement pour tout type de tâche. Mentionnez également que la différence entre la version 4 et la version 5 de Perl est similaire à celle entre awk et C++. (Bon d'accord, ce n'est peut-être pas si différent, mais l'idée est là.) Si vous voulez [support] et des garanties raisonnables que ce que vous développez fonctionnera encore dans le futur, alors vous devriez utiliser la version [supported] ; c'est-à-dire la version 5.005, ou la version 5.004 qui n'est pas si mauvaise. Plusieurs bugs importants ont été corrigés depuis la version 5.000 jusque la version 5.003, donc essayez de les mettre à jour si possible.
À noter en particulier la chasse de grande envergure aux erreurs de dépassement de tampon survenues dans la version 5.004. Toute version antérieure à celle-là, y compris perl4, est considérée comme non sure et devrait être mise à jour aussitôt que possible.
Lorsqu'il est inclus comme une partie intégrante de la Distribution Standard de Perl ou de sa documentation (imprimée ou autre), ce document est couvert par la Licence Artistique de Perl. Pour toute distribution indépendante de tout ou partie de cette FAQ, se référer à perlfaq.
Indépendamment de sa distribution, le code de tous les exemples est ici du domaine public. Vous êtes autorisé et même encouragé à utiliser ou modifier ce code pour vos propres programmes, que ce soit pour le plaisir ou à but lucratif. Un simple commentaire dans le code remerciant la FAQ serait courtois, quoique non exigé.