Sortie de Perl 5.12, tandis que le développement de Perl 6 se poursuit

J'ai dû me mettre aux joie du langage PERL au cours de ma formation, et je n'ai eu que quelques heures pour connaitre les bases du langage, et c'est vrai que dans un premier temps la syntaxe du langage est assez repoussante à mes yeux,

en effet je trouve que les lignes sont très chargées avec des $ et autres joyeusetés à tout bout de champ, je ferais la même critique pour le PHP qui pour moi n'est pas agréable à écrire (et d'autant plus en PHP5, mais là n'est pas le sujet)

Bref, je n'ai pas exploité toute la puissance de PERL mais je ne sais pas si j'aurai le courage de m'y mettre plus que ça à moins d'y être contraint (ce qui est le cas), tandis que la syntaxe d'un python ou java me paraisse beaucoup plus lisible et sans être surchargée.

Pour finir, d'après le peu que j'ai vu en perl, ce langage est très performant pour un super bash, mais c'est bien là sa seule utilité à mes yeux.


Bien sûr je ne parle qu'en la qualité de novice PERL .

Citation:

---

Envoyé par viking1404

C'est moi ou php non plus n'a pas de méthode Split sur l'objet String ?

Il est dit dans plusieurs articles que j'ai lu ici et là que perl est très efficace pour tout ce qui est expression régulières et traitement des textes etc.
Si on en crois ce que disent ces articles, on peut penser que ne pas avoir de méthodes Split sur les string est plutôt un gage de performance.

---

Je ne fais plus de à gogo perl depuis 2 ans mais il est toujours installé sur ma bécane, je l'utilise beaucoup pour mettre au point des expressions régulières. De plus perl m'a appris pas mal de choses comme le fameux "\015\012" quand le gugus qui fait du java n'arrive utilise des lignes vides pour sauter une ligne à la console... ouais les histories de table OEM etc...

Pour le reste en ce moment je bosse sur un gros projo en dotnet mais une très grande partie du code pour le traitement de texte sera écris en perl pour sa puissance inégalé à ce niveau :).

Mais sinon ou en est perl6 ? Franchement pour que je revienne sur perl il faudrait un modèle OO potable et aussi le multithreading ainsi qu'une moyen d'écrire des extensions en C++ via une API potable :)

Citation:

---

Envoyé par ThomasR

Pour en revenir au sujet et à l'exemple de feber, Perl semble être devenu un langage obsolète. C'est le seul dans l'exemple qui ne possède pas de méthode Split sur l'objet String (encore faudrait-il qu'une chaine soit un objet dans ce langage).

---

clairement cette remarque n'a pas forcement un grand sens, car le monde informatique ne se limite pas à la POO :roll:
après, on peut regretter que les aficionados de la POO n'aient pas accès à une encapsulation OO de chaînes de caractères, listant les principales méthodes utilisée dans 95% des cas

mais il faudrait pour cela que le modèle objet de Perl soit mieux normalisé, ou passer par quelque chose de couramment utilisé

plus d'infos sur la POO en Perl :arrow: http://djibril.developpez.com/tutoriels/perl/poo/

Citation:

---

Envoyé par ferber

C'est une question que je me pause de temps en temps, mieux vaut 100000 occurrence d'un objet de type "A" ayant une chaine et une méthode( non static ) "b" ou
100000 occurrence d'un objet de type "A" n'ayant une chaine et une methode externe a la classe "A" utilisée pour manipuler les objects de type "A". Selon mes testes (en c# ) il vaut mieux que la méthode soit externe.

---

pour le coup de la "lourdeur" d'un langage OO avec une "méthode" par objet, ce n'est partiellement vrai que dans les langages OO totalement dynamiques, ou avec un modèle par prototype peu optimisé... l'immense majorité des langages OO sont sur un modèle par classe, et l'utilisation d'une table de méthodes virtuelles évitent d'avoir "une méthode par objet", et associé au JIT ce code sera optimisé, ce qui évitera la double indirection systématique (chose non possible avec les méthodes virtuelles dans un langage natif comme C++, même si on peut faire des choses plus sioux pour arriver à un résultat similaire)

Citation:

---

Envoyé par ferber

Mais si on sort tout les membres de toute les classes on se retrouve plus vraiment dans de l'orienté objet. Quoi que ça mérite réfléction.

---

tu reviens à des types enregistrements et des modules de fonctions associés... un autre paradigme, qui a aussi des avantages (mais qui demande une conception différente ;))

Citation:

---

Envoyé par ferber

C'est sur. :ccool:
Mais il permet déjà d'apprécier ou pas le style de syntaxe.
Et me conforte dans l'idée que je n'apprécie pas la syntaxe de perl.:mrgreen:

---

Bonjour,

Tu as juste oublié un exemplaire en Ruby :

Code:

---

1 2 3 4 5 6

# Ruby i=0 informations="a:b:c:d" tempchars=informations.split ':' puts tempchars[i]

---

Cela dit, la version Python est ici également parfaitement interprétée en Ruby. Ce code n'est pas l'idéal pour différentier les deux langages.

Côme

Citation:

---

Envoyé par gorgonite

pour le coup de la "lourdeur" d'un langage OO avec une "méthode" par objet, ce n'est partiellement vrai que dans les langages OO totalement dynamiques, ou avec un modèle par prototype peu optimisé... l'immense majorité des langages OO sont sur un modèle par classe, et l'utilisation d'une table de méthodes virtuelles évitent d'avoir "une méthode par objet", et associé au JIT ce code sera optimisé, ce qui évitera la double indirection systématique (chose non possible avec les méthodes virtuelles dans un langage natif comme C++, même si on peut faire des choses plus sioux pour arriver à un résultat similaire)




tu reviens à des types enregistrements et des modules de fonctions associés... un autre paradigme, qui a aussi des avantages (mais qui demande une conception différente ;))

---

Hum, merci, c'est super intéressant !
Donc j'en conclue que ce genre de gain n'est plus vraiment pertinent sur les langages récent ( style c# )?
Existe il une documentation généraliste sur ce sujet ?? Cette façons de faire porte telle un nom particulier ??

Moi je pense que Perl c'est uniquement pour les vieux, mais comme l'age de la retraite est repoussé chaque année, on va encore en entendre parler un moment.
:?

Citation:

---

Envoyé par OWickerman

Moi je pense que Perl c'est uniquement pour les vieux, mais comme l'age de la retraite est repoussé chaque année, on va encore en entendre parler un moment.
:?

---

Hen j'ai fais du perl pendant 7ans et je n'ai que 24ans ...

Ce qu'il manque à perl c'est une API C++ pour pourvoir écrire des extensions :), d'utiliser BOOST pour apporter un multithreading potable, des déclarations de fonctions correct donc pas :

Code:

---

sub truc () { my $self = shift; }

---

mais

Code:

---

1 2	sub () { $this->mavariable;}

---

Citation:

---

Envoyé par teddyalbina

Hen j'ai fais du perl pendant 7ans et je n'ai que 24ans ...

Ce qu'il manque à perl c'est une API C++ pour pourvoir écrire des extensions :), d'utiliser BOOST pour apporter un multithreading potable, des déclarations de fonctions correct donc pas :

Code:

---

sub truc () { my $self = shift; }

---

mais

Code:

---

1 2	sub () { $this->mavariable;}

---

---

Ouai enfin là c'est pas un manque, c'est plus une question de synthaxe (et surtout de gout).

De plus, dans ton second code, tu ne nommes pas ta procédure.

A l'époque ou j'ai fait un peu du Perl, je me suis toujours planté sur les tableaux, entre mettre un @ ou un #, je voyais pas trop l'interêt d'avoir un symbole différent pour les tableau référencés ou non. Et je préfère largement la syntaxe du PHP, plus aisé à appréhender.

Citation:

---

Envoyé par gorgonite

pour le coup de la "lourdeur" d'un langage OO avec une "méthode" par objet, ce n'est partiellement vrai que dans les langages OO totalement dynamiques, ou avec un modèle par prototype peu optimisé... l'immense majorité des langages OO sont sur un modèle par classe, et l'utilisation d'une table de méthodes virtuelles évitent d'avoir "une méthode par objet", et associé au JIT ce code sera optimisé, ce qui évitera la double indirection systématique (chose non possible avec les méthodes virtuelles dans un langage natif comme C++, même si on peut faire des choses plus sioux pour arriver à un résultat similaire)

---

Certains compilos C++ savent optimiser les appels virtuels via des optimisations guidées par profil (instrumentation de code). Je ne sais pas si certains compilos savent optimiser directement lors de la compilation (pas VC++ 2008 en tous cas).

Concernant les capacités du JIT en .Net, concrètement, c'est ce qui se passe, ou est-ce que c'est ce qui *pourrait* se passer ? Parce que ce genre de micro-optimisation représente un surcout qui ne doit pas être négligeable, et je me demande quel est le gain réel au final avec les processeurs actuels.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Certains compilos C++ savent optimiser les appels virtuels via des optimisations guidées par profil (instrumentation de code). Je ne sais pas si certains compilos savent optimiser directement lors de la compilation (pas VC++ 2008 en tous cas).

---

g++ et vc++ ne sont pas des "références" en terme de performances, ni même d'introduction de nouvelles fonctionnalités en cours de normalisation (attention, je n'ai pas dit qu'ils ne faisaient rien non plus :roll:)

après, il existe un pattern sur les templates :
http://en.wikipedia.org/wiki/Curious...mplate_pattern

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Concernant les capacités du JIT en .Net, concrètement, c'est ce qui se passe, ou est-ce que c'est ce qui *pourrait* se passer ? Parce que ce genre de micro-optimisation représente un surcout qui ne doit pas être négligeable, et je me demande quel est le gain réel au final avec les processeurs actuels.

---

il faut savoir que pour un cas général, seules quelques grandes optimisations apportent à coup sûr un gain justifiant leur usage... ce genre de micro-optimisation est d'un coût ridicule à côté d'un passage en forme SSA qui est fait même dans les JIT ;)

En tout cas,

Je trouve juste un peu dommage de critiquer des langages de programmation sans en avoir des notions correctes. Et je dit cela pour tous les langages.

;)

Citation:

---

Envoyé par djibril

Je trouve juste un peu dommage de critiquer des langages de programmation sans en avoir des notions correctes. Et je dit cela pour tous les langages.

---

On peut dire ça... Les 4/5ème des critiques sur ce fil semble faites par des gens qui ne connaissent pratiquement pas Perl ou se focalisent sur des points de détails. Il y a de vrais critiques importantes qu'on peut faire à Perl, mais jusqu'ici on a surtout entendu de la méconnaissance ou des jugements à l'emporte pièce.

Citation:

---

Envoyé par Gordon Fowler

la distribution Linux Fedora 12 embarque Rakudo Perl 6.

Fedora 13 sera livrée avec Python 3.

Vraiment rien qu'une anecdote ?

---

Tu as conscience que Python 3 est déjà livré avec Fedora, et que la nouveauté dans Fedora 13 sera simplement qu'elle utilisera Python3 plutôt que Python2 par défaut. Sachant cela et sachant que Python 3 est présenté depuis quelques années déjà comme près pour la mise en production alors que Rakudo en est encore à un statut expérimental, je ne vois vraiment pas ce que tu veux insinuer avec cette comparaison. Par ailleurs Python 3 n'est qu'une évolution de Python 2 sans différences fondamentales alors que Perl 6 est une réécriture complète et un langage fort différent de Perl 5.

Citation:

---

Envoyé par ThomasR

Pour en revenir au sujet et à l'exemple de feber, Perl semble être devenu un langage obsolète. C'est le seul dans l'exemple qui ne possède pas de méthode Split sur l'objet String (encore faudrait-il qu'une chaine soit un objet dans ce langage).

---

C'est peut-être parce que Perl n'est pas un langage tout objet et qu'en particulier les chaînes de caractères ne sont pas des objets... En quoi une fonction split() est-elle intrinsèquement moins bien qu'une méthode Split() ? Tu avais l'intention de la surcharger dans une classe héritant de String ?
Par ailleurs split() en Perl est particulièrement puissante et flexible par rapport à la plupart des autres langages, dans le genre exemple de l'inadéquation de ce langage, c'est osé !

Citation:

---

Envoyé par ferber

C'est sur. :ccool:
Mais il permet déjà d'apprécier ou pas le style de syntaxe.
Et me conforte dans l'idée que je n'apprécie pas la syntaxe de perl.:mrgreen:

---

Ouais... Ben faudra donner un autre exemple, il y a des aspects contestables dans la syntaxe de Perl (pas mal de recoins obscurs) mais tes exemples ne les font pas ressortir, j'irais même jusqu'à dire qu'à mes yeux habitués à de nombreux langages, tes exemples sont strictement similaires et aussi faciles à lire et "esthétiques" les uns que les autres.

Citation:

---

Envoyé par OWickerman

Moi je pense que Perl c'est uniquement pour les vieux, mais comme l'age de la retraite est repoussé chaque année, on va encore en entendre parler un moment.

---

Bien sûr ! Tu en as beaucoup des perles de sagesse comme ça ? Pour ta gouverne j'ai 24 ans et je ne me considère pas encore comme "vieux".
Et sinon, un argument objectif sur le déclin du Perl ?

Citation:

---

Envoyé par dlusignan

Je pense que la vocation de Perl n'est — de toute façon — pas très orientée web. Pour faire des scripts Shell sur un serveur Linux, il est vraiment fort. Il a été pensé, à la base, beaucoup plus comme un langage d'administration de serveur. Je crois que la raison pour laquelle, il a été mis de l'avant, du point de vue du web à l'époque, c'est tout simplement qu'il n'y avait pas vraiment d'alternative.

---

Perl se débrouille pas mal du tout sur le Web si tu utilises les bons framework (Catalyst...), à l'époque il avait été choisi pour l'aisance avec laquelle il permettait d'écrire des scripts CGI. Il a été remplacé par PHP sur ce segment de marché (à l'origine un simple langage de template implémenté par du Perl, pour l'anecdote) mais pas à mon avis pour de bonnes raisons techniques, plus parce que PHP était encore plus laxiste et encourageait encore plus le style cargo-cult que Perl, et surtout il était bien plus compatible avec les hébergements mutualisés avec son modèle "tout-intégré" pourtant déjà l'anathème d'un développement propre bien modulaire.

Citation:

---

Envoyé par teddyalbina

Franchement pour que je revienne sur perl il faudrait un modèle OO potable et aussi le multithreading ainsi qu'une moyen d'écrire des extensions en C++ via une API potable

---

Enfin un commentaire qui mets un peu le doigt là où ça fait mal... Il est certain que le modèle OO (ou plutôt son absence) en Perl laisse à désirer, le multithreading bien qu'intégré n'a jamais décollé et souffre toujours d'instabilité et de limitations. Inline::CPP est pas trop mal pour l'intégration facile de C++ par contre et Perl a toujours facilement intégré des API C.

Citation:

---

Envoyé par teddyalbina

des déclarations de fonctions correct donc pas :

Code:

---

sub truc () { my $self = shift; }

---

Code:

---

sub () { $this->mavariable;}

---

---

Je te rejoins sur les déclarations de fonctions mais pas sur l'exemple en particulier : ce que tu montres là c'est plutôt un symptôme de la non-intégration de l'OO dans le langage et l'absence d'une syntaxe particulière aux méthodes.
Ce qui manque vraiment ce sont des prototypes de fonctions corrects, permettant de spécifier des noms de paramètres et un certain nombre de contraintes sur eux.

Citation:

---

Envoyé par teddyalbina

Mais sinon ou en est perl6 ?

---

Perl 6 répond en fait à pratiquement toutes tes critiques (bien qu'on puisse sans doute en trouver d'autres), la POO est bien intégrée et standardisée, les prototypes de fonctions sont excellents et le multithreading sera bien supporté. Il apporte également pleins d'autres innovations pratiques.
Rakudo, l'implémentation sur la VM Parrot est maintenant bien avancée et on peut déjà l'utiliser pour tester ce nouveau langage (elle est même disponible sur les dépôts officiels de Fedora 12), d'ici un an ou deux, si la dynamique actuelle se maintient, Rakudo devrait être à la hauteur pour de véritables applications en production.

--
Jedaï

Citation:

---

Envoyé par Jedai

On peut dire ça... Les 4/5ème des critiques sur ce fil semble faites par des gens qui ne connaissent pratiquement pas Perl ou se focalisent sur des points de détails. Il y a de vrais critiques importantes qu'on peut faire à Perl, mais jusqu'ici on a surtout entendu de la méconnaissance ou des jugements à l'emporte pièce.



Tu as conscience que Python 3 est déjà livré avec Fedora, et que la nouveauté dans Fedora 13 sera simplement qu'elle utilisera Python3 plutôt que Python2 par défaut. Sachant cela et sachant que Python 3 est présenté depuis quelques années déjà comme près pour la mise en production alors que Rakudo en est encore à un statut expérimental, je ne vois vraiment pas ce que tu veux insinuer avec cette comparaison. Par ailleurs Python 3 n'est qu'une évolution de Python 2 sans différences fondamentales alors que Perl 6 est une réécriture complète et un langage fort différent de Perl 5.



C'est peut-être parce que Perl n'est pas un langage tout objet et qu'en particulier les chaînes de caractères ne sont pas des objets... En quoi une fonction split() est-elle intrinsèquement moins bien qu'une méthode Split() ? Tu avais l'intention de la surcharger dans une classe héritant de String ?
Par ailleurs split() en Perl est particulièrement puissante et flexible par rapport à la plupart des autres langages, dans le genre exemple de l'inadéquation de ce langage, c'est osé !



Ouais... Ben faudra donner un autre exemple, il y a des aspects contestables dans la syntaxe de Perl (pas mal de recoins obscurs) mais tes exemples ne les font pas ressortir, j'irais même jusqu'à dire qu'à mes yeux habitués à de nombreux langages, tes exemples sont strictement similaires et aussi faciles à lire et "esthétiques" les uns que les autres.



Bien sûr ! Tu en as beaucoup des perles de sagesse comme ça ? Pour ta gouverne j'ai 24 ans et je ne me considère pas encore comme "vieux".
Et sinon, un argument objectif sur le déclin du Perl ?



Perl se débrouille pas mal du tout sur le Web si tu utilises les bons framework (Catalyst...), à l'époque il avait été choisi pour l'aisance avec laquelle il permettait d'écrire des scripts CGI. Il a été remplacé par PHP sur ce segment de marché (à l'origine un simple langage de template implémenté par du Perl, pour l'anecdote) mais pas à mon avis pour de bonnes raisons techniques, plus parce que PHP était encore plus laxiste et encourageait encore plus le style cargo-cult que Perl, et surtout il était bien plus compatible avec les hébergements mutualisés avec son modèle "tout-intégré" pourtant déjà l'anathème d'un développement propre bien modulaire.



Enfin un commentaire qui mets un peu le doigt là où ça fait mal... Il est certain que le modèle OO (ou plutôt son absence) en Perl laisse à désirer, le multithreading bien qu'intégré n'a jamais décollé et souffre toujours d'instabilité et de limitations. Inline::CPP est pas trop mal pour l'intégration facile de C++ par contre et Perl a toujours facilement intégré des API C.



Je te rejoins sur les déclarations de fonctions mais pas sur l'exemple en particulier : ce que tu montres là c'est plutôt un symptôme de la non-intégration de l'OO dans le langage et l'absence d'une syntaxe particulière aux méthodes.
Ce qui manque vraiment ce sont des prototypes de fonctions corrects, permettant de spécifier des noms de paramètres et un certain nombre de contraintes sur eux.



Perl 6 répond en fait à pratiquement toutes tes critiques (bien qu'on puisse sans doute en trouver d'autres), la POO est bien intégrée et standardisée, les prototypes de fonctions sont excellents et le multithreading sera bien supporté. Il apporte également pleins d'autres innovations pratiques.
Rakudo, l'implémentation sur la VM Parrot est maintenant bien avancée et on peut déjà l'utiliser pour tester ce nouveau langage (elle est même disponible sur les dépôts officiels de Fedora 12), d'ici un an ou deux, si la dynamique actuelle se maintient, Rakudo devrait être à la hauteur pour de véritables applications en production.

--
Jedaï

---

Merci JEDAI pour ces précisions concernant Inline::CPP je vais aller voir ça ce wk :).

Pour le multithreading j'avais à une époque regardé comment perl implémentait cela en fait il passe par pthread et d'autres mécanisme un peu archaique, n'ayant pas suffisament le niveau en C/C++ à ce moment là je n'ai pas tenté la modif d'utiliser BOOST à la place mais je pense qu'il faudrait tenter quelque chose à ce niveau pour perl 5.

Pour ce qui est de la bioinformatique Perl a encore du succès :ccool:

Citation:

---

Envoyé par Gordon Fowler

Pour eux, ce n'est ni la communication de Larry Wall, ni le langage lui-même qui sont en cause. C'est la communauté. Le réseau IRC de Perl serait devenu le royaume de l'incivilité, du mépris et du manque de savoir-vivre.

---

Ça c'est bien vrai, je m'y suis connectée une seule fois. N'ayant pas l'habitude j'ai engagé au hasard une conversation en privé et on m'a remballé en me disant de parler dans la fenêtre commune et la personne m'a traitée de newbie et en a appelé un autre et ils se sont mis à deux à se moquer ... ça ne m'a pas vraiment donné envie de faire un nouvel essai.

Ayant pas mal fréquenté Java/C++, j'ai du il y a quelques temps déjà opter pour un langage de programmation dynamique qui puisse servir de "couteau suisse".

L'idée dernière étant avec quoi développer rapidement des prototypes qui puissent être utilisables rapidement tout en permettant d'utiliser plus tard ce travail comme base à des développements plus "standards".

Pour cela il fallait opter pour un langage qui soit:

• Disponible sur la plupart des environnements
• Orienté Objet
• Possibilités d'optimisation locales,
• Packaging, gestion de version
• Write once deploy everywhere à la Java
• Possibilité d'accéder à différents outils/bibliothèques écrits dans d'autres langages
• Facilité pour encapsuler des codes existants,
• Possibilités de modularisation des développements pour pouvoir construire des codes conséquents sans que ce soit trop compliqué à gérer.

La plupart des langages scriptés ou dynamiques ont ce type d'attributs.

Ruby et Python sont assez généralistes et à peu près équivalents côté "possibilités". Python a l'avantage de la durée et de la disponibilité d'un nombre de bibliothèques en tout genre très important.
Note: Ce qui est intéressant est que la bibliothèque reste dans son langage 'natif', vous n'avez qu'une API qui permet de l'utiliser à partir de.

PHP et PERL sont un peu trop spécialisé sur le Web pour l'un et dans la gestion système UNIX pour l'autre.

De fait, j'ai longtemps hésité entre Python et Ruby.

Dans la pratique, mon passé Java/C++ fait que je me sens beaucoup plus à l'aise avec Python. De plus, j'ai l'impression que l'orientation objet est beaucoup plus complète, naturelle en Python qu'en Ruby.
Enfin, lorsqu'on passe de Java/C++/Python, il y a pas mal de similitudes dans les appels de fonctions/méthodes, passages des paramètres qui permettent de s'y retrouver lorsqu'on est un peu perdu.

Cela ne m'empêche pas de faire du PERL, du PHP ou du BASH de temps en temps: impossible et inutile de tout ré-écrire dans le langage de votre choix.

Notez que je ne dis rien contre PERL. Juste que je ne le trouve pas assez adapté à mes attentes. Et je conçois et respecte tout à fait que d'autres puissent avoir des attentes qui aboutissent à des choix autres et tout à fait pertinents.
-W

Perl n'est pas sur le déclin je viens d'avoir une proposition d'embauche à 2000e pour en faire à gogo et je viens juste d'obtenir ma licence pro de dév :).

En plus, le couple Dotnet/PERL interesse pas mal parce que ce n'est pas vraiment courant. ça intrigue jusqu'au moment ou j'ajoute que dotnet utilise PRCE qui est un moteur de regexp C++ qui tente d'être à niveau par rapport à PERL qui est la référence.

En plus de ça je fais de la pub pour mon premier amour PERL JE T'AIME :aie:

J'aime perl pour ce qui repousse certains: sa faculté d'écrire des choses différemment selon le sens qu'on veut y donner. Pouvoir écrire
"si cond alors exec" ou " exec si cond1 " par exemple. Contrairement à d'autre, je trouve que ça facilite la lecture du code, pour peu bien sur que l'on respecte des règles non-psychopathiques minimales.

Mais hélas, perl a perdu beaucoup de temps. Le virage de la OO a été complètement raté. Quand on voit perl6, il y a de quoi pleurer. C'est un langage complètement différent. Les différences entre perl5 et perl6 n'ont rien à voir avec celles entre ptython2 et python3. C'est d'un tout autre ordre de grandeur. Du coup, nombre de développeur perl5 n'ont pas grand chose à gagner à aller vers perl6 plutôt qu'à python. Au contraire même, puisque la vrai richesse de perl, qui est constituée par sa formidable librairie ne sera pas utilisable, alors que la librairie python s'améliore peu à peu (reste pour python à inventer un cpan efficace, crévindiou!)

Il y aurait eu moyen pourtant de faire du bel objet avec perl5. Les modules Moose, ou plus simplement le pragma classes le montre. Cela aurait pu être intégré rapidement et relativement simplement. On serait resté compatible. On aurait bien sur eu des puristes pour dire "oui mais ton objet, il est pas vraiment encapsulé !". Masi on s'en fiche. Comme en python ! Quelques petites additions en plus, comme le try except, et hop.

Pour ma part, je trouve que c'est une pitié. Mais cela n'a rien d'étonnant, a posteriori. Quand on lit les documents qui ont présidé à la naissance de perl6 (les apocalypse et autres gnoses), on se dit que c'est parti un peu trop dans le délire. 10 ans pour commencer à sortir, c'est quand même pas rien. Dommage qu'entre temps, l'action pragmatique à entreprendre sur perl5 n'ait pas été entreprise.

Maintenant, nous verrons bien. Espérons que ça donne quelque chose malgré tout. Le retard me parait quand même bien grand. A cause de ce manque en objet, perl5 n'a pas, comme python avec qt, une librairie graphique qui inclue un designer. Malgré ses qualités, le plugin pour eclipse de perl n'est pas à la hauteur de celui de python; et ce n'est qu'un exemple: il n'existe d'IDE perl qui soit au niveau des meilleurs IDE pour python.
Et malheureusement, je ne vois pas ce qui dans perl6 pourrait amener un enthousiasme propre à inverser le mouvement. Seule l'immense base existante peut sauver la situation, pour peu que les passerelles soient suffisantes.

Dans mon boulot, les devs ont abandonné Perl progressivement pour passer à DEX, une solution plus facile à implémenter pour des programmes dialoguant avec notre base de données (il n'existe pas de module en Perl à son sujet, sauf erreur ou évolution récente) mais nettement plus délicate, niveau programmation, que Perl.

Bref, on n'est plus beaucoup à bosser en Perl, je suis blazé carrément. :calim2:

Mise à jour du 14.04.2010 par Katleen
Sortie de Perl 5.12, tandis que le développement de Perl 6 se poursuit

Le langage open source Perl fait un pas en avant cette semaine avec les débuts de Perl 5.12.

De nouvelles fonctionnalité sont au rendez-vous pour faciliter la tâche des développeurs. Par exemple, les mots clés pluggables sont désormais pris en charge. Ce méchanisme s'attache directement au parseur et permet l'implémentation d'un mot clé pour définir la syntaxe du reste du texte.

Perl, langage dynamique, existe depuis 1987 (une éternité dans l'histoire de l'informatique !). Perl 5.0 est apparu en 1994, quelle longévité !

Perl 5.12 se veut également correctif, il fixe la faille Unix qui ne permettait l'affichage des dates que jusqu'en 2038 (après quoi, on revenait en 1970)...

Cette nouvelle sortie arrive alors que l'augmentation du nombre d'utilisateurs du langage se réduit.

Ce qui n'empêche pas la poursuite du développement de Perl 6. En effet, tandis que la plate-forme Perl 5 progresse, on travaille aussi sur Perl 6 depuis 2004.

Mais certaines personnes se lassent d'attendre... Et préfèrent miser sur le développement de Perl 5.

Pourtant, le travail en cours sur Perl 6 est prometteur et bien engagé. Mais Perl 6 Rakudo ne deviendrait une alternative sérieuse à son grand frère que dans quelques années, selon certains experts.

De toutes les façons, une autre mise à jour est prévue bien avant cette date, puisque 2011 devrait voir l'arrivée de Perl 5.14.

Source : Le site officiel de Perl

Lire aussi :
Humour : Les programmeurs en Perl seraient les plus malpolis

:fleche: Pensez-vous que Perl 6 verra le jour ?