Comme chaque année, les équipes Perl 5 et Perl 6 publient leurs calendriers respectifs de l'avent [1] [2] qui démontrent les fonctionnalités des langages et de leurs bibliothèques et donnent des conseils stylistiques. Beaucoup programment en Perl 5 comme en C et ignorent que Perl est inspiré des principes qui règlent les langages naturels. Comme on s'exprime de manière différente selon le média, la situation et l'interlocuteur, on n'écrit pas en Perl de la même manière un gros programme et un uniligne [3] [4].
Rakudo Star, un Perl 6 pour les adopteurs précoces
Quant à Perl 6, une nouvelle release de Rakudo Star est prévue au plus tard pour janvier 2012, le temps de corriger les régressions dues à l'intégration de nouveaux blocs architecturaux. Le nombre, l'importance, et l'interdépendance de ceux-ci expliquent l'absence de release depuis juillet. Une explication détaillée pour les anglophones.
Le résultat est impressionnant. Exemples parmi d'autres : on peut écrire un système de débogage de grammaire en 200 lignes, ou intégrer de manière transparente une bibliothèque d'entiers en longueur variable, accessible sous le nom de type BigInt.
Finalement l'architecture étant stable, les développeurs de rakudo peuvent commencer à optimiser le compilateur en écrivant du code Perl 6 améliorant ainsi à la fois les performances du compilateur et celles du code utilisateur. Merci au système de métaclasses avec polymorphisme de représentations.
Aller plus loin
- Nouvelles fonctionnalités de Perl 6 (219 clics)
- Site Perl6.org (105 clics)
- Les mongueurs (68 clics)
- Le livre "Perl Moderne" (103 clics)
- Ecrire des unilignes en Perl 5 (154 clics)
- Un historique des releases Perl (30 clics)
# Perl vs Ruby
Posté par gato . Évalué à 1.
Par pure curiosité, quels sont les avantages qui restent à Perl vis-à-vis du langage Ruby qui a pris la suite ?
[^] # Destructeurs
Posté par Arthur Accroc . Évalué à 2.
Des destructeurs ?
Enfin ça, c’est pour quasiment tous les langages orientés objets par rapport à Ruby...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Perl vs Ruby
Posté par barmic . Évalué à 6.
Son taux de pénétration sur les plateformes Unix ?
les perf ?
des structures du langage comme given/when ?
la manipulation en ligne de commande ?
les variables utilisée implicitement ?
son API très intuitive pour qui viens du C ?
un langage plus flexible dans le quel beaucoup de choses sont implémentés dans le langage lui même (les objets avec Moose, MooseX et autre) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Perl vs Ruby
Posté par Philippe F (site web personnel) . Évalué à 7.
Une panoplie de lib sur CPAN
Des one-liner de la mort qui tue...
[^] # Re: Perl vs Ruby
Posté par Phlogistique . Évalué à -1. Dernière modification le 07 décembre 2011 à 20:50.
Perl 6 n'a pas un très gros taux de pénétration, pour le coup
Ruby a aussi les options -p, -n, -e et -i.
Ruby reprend de Perl un certain nombre d'entre elles.
[^] # Re: Perl vs Ruby
Posté par jbbourgoin (site web personnel) . Évalué à 3.
Ruby a pris la suite ?
La formulation est un peu étrange, la suite de quoi ?
Ruby a du mal à se distinguer de Rails. Même si Ruby est un langage bien plus généraliste que PHP, au final il reste dans les faits bien plus un "concurrent" de PHP que de Perl.
Le "concurrent" de Perl c'est plutôt Python.
Alors que reste-t-il à Perl ?
C'est un langage vraiment multi-paradigmatique. Ruby s'en rapproche, Python est très loin derrière (mais c'est la volonté même de son concepteur !). Mieux, c'est quasiment un langage de recherche en plus d'être un langage extrêmement pratique.
C'est un langage qui a un nombre de bibliothèques de qualités très important (CPAN).
C'est un langage qui commence à avoir de la bouteille et ça signifie : les bonnes pratiques sont connues et documentées, et dans le cas de Perl richement documentées !
La communauté est excellente.
En gros pour moi la force de Perl c'est :
Principaux défauts :
[^] # Re: Perl vs Ruby
Posté par Phlogistique . Évalué à 0.
Je ne comprends pas du tout cet argument; en quoi l'existence et la popularité de Rails est un problème pour Ruby? Il y a plein de gens qui utilisent Ruby en dehors de Rails!
[^] # Re: Perl vs Ruby
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Je n'ai pas dit le contraire.
Ce que je voulais dire c'est que finalement Ruby est surtout un langage pour le web. Non qu'il soit incapable de faire autre chose, mais historiquement il s'est fait connaître par Rails, il a attiré les devs web et voilà.
Il suffit de voir un système unix. Quel est le langage qui mange un peu du pain réservé jusqu'alors à Perl ? Python, principalement Python, majoritairement Python.
Quitte à faire de l'ombre à Perl j'aurais également préféré que ce soit par Ruby !
Mais c'est ainsi.
De même pour Perl. Perl est théoriquement capable de tout faire. Mais grosso-modo ses meilleures bibliothèques tournent autout du web, de l'admin système, du traitement des données textuelles. Et c'est pas un hasard, c'est par là qu'il s'est fait connaître.
Ses bibliothèques pour les GUI ou le dev de jeux (SDL etc.) sont notoirement moins connues et moins peaufinées que celle de Python.
Ce qui n'empêche pas de faire des jeux et des GUI en Perl !
# Perl 6
Posté par Philippe F (site web personnel) . Évalué à 4.
Concernant Perl 6, vu le peu de point commun avec Perl 5 en terme de langage, je me demande pourquoi ça s'appelle encore Perl. J'ai l'impression qu'il y a à peu près autant de points communs entre Perl 5 et Perl 6 qu'entre le C et l'assembleur (en gardant en tête qu'on peut embarquer de l'assembleur dans du C très facilement).
[^] # Re: Perl 6
Posté par cognominal . Évalué à 2.
Je pense que Perl 6 sera la continuation d'une idée qui n'a été qu'ébauchée avec la lignée Perl jusque là. Il y a toujours des sigils par exemple.
Il y aura donc deux lignes concurrentes Perl 5 et Perl 6. Perl 5 évoluera encore longtemps, mais contraint par les règles de rétrocompatiblité avec bientôt 25 d'existence. Alors que Perl 6 est conçu dès le départ pour évoluer avec l'expérience acquise pendant tout ce temps.
L'existence d'un mécanisme de grammaire permet à chacun d'étendre le langage à son goût et les expériences les plus réussies entreront dans le langage standard. Peu de langage ont réussi une évolution aussi propre. Dans le monde des langages dynamiques, Perl est le premier et encore longtemps le seul car les autres langages ont sérieusement cassé la compatibilité avec leurs release majeures.
Cela n'enlève rien aux mérites propre des autres langages.
[^] # Re: Perl 6
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Malgré toute ma sympathie pour Perl, que j'aime beaucoup, je ne suis pas totalement d'accord avec cette opinion.
Certes, si l'on compare Perl à Ruby, Lua et Python, c'est vrai.
Mais c'est très vite oublier la vieille famille de langages Lisp, infiniment plus propre et d'autant moins soumis aux problèmes de rétrocompatibilité que Lisp est champion (tous langages confondus) en matière de "programmabilité" il est LE langage programmable et donc naturellement extensible.
[^] # Re: Perl 6
Posté par cognominal . Évalué à 1.
En effet.
Malheureusement, si Lisp est l'ancêtre des langages dynamiques, il n'est pas très populaire aujourd'hui.
Lisp est toujours une source d'inspiration pour les designers de langage et de VM.
Ainsi, Parrot a des véritables systèmes de continuation et de GC, et non un simple système de comptage de référence comme Perl 5; Perl 6 propose a la fois des variables lexicales et des variables dynamiques; il propose des aussi des macros hygiénique (en cours d'implémentation).
Mais côté grammaire, le choix de Perl 6 est opposé à celui de Lisp. Il a une syntaxe riche, et maintenant extensible, qui permet de mettre en valeur la structure des programmes et la nature des données (sigils et twigils). Cela ne s'oppose pas à l'extensibilité puisque le système de grammaire entièrement intégrés à l'objet est très expressif.
[^] # Re: Perl 6
Posté par barmic . Évalué à 2.
On se demande pourquoi. Il est intéressant de noter qu'il n'y a à peu près que C qui soit très vieux (créé avant Epoch) et qui soit toujours populaire. lisp arrive en second (grâce à des logiciels comme emacs), mais les langages comme Fortran et COBOL sont utilisé par héritage du passer sans être populaire.
Il y a tout de même des choses qu'on essaie de ne pas reproduire comme le contexte dynamique des fonctions (si je me trompe bien c'est ce que fait lisp).
Qu'est ce que c'est ?
Édition :
Je la laisse apparente car elle m'a fait rire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Perl 6
Posté par cognominal . Évalué à 1.
continuation.
D'après ce que je sais, les premiers Lisps avaient pour seul scopage, un scopage dynamique. Cela a été ensuite remplacé par un scopage lexical qui est généralement ce que le programmeur désire.
Si je me souviens bien Perl a commencé avec le seul scopage local (mécanisme similaire au scopage dynamique) pour y ajouter plus tard le scopage lexical.
Mais il y a des cas où le scope dynamique est préférable.
Le scopage dynamique est très utilisé pour passer du contexte sans passer par des paramètres explicites. Ainsi dans la grammaire Perl 6, les variables avec le twigil '*' sont des variables dynamiques.
[^] # Re: Perl 6
Posté par barmic . Évalué à 2.
C'est pas une forme d'effet de bord inversée ? Ça ne me semble pas souhaitable, car ça peut être compliqué à corriger en cas d'erreur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Perl 6
Posté par jyes . Évalué à 2.
Je ne connais pas du tout COBOL et il est bien possible que ses développements actuels ne servent plus qu’à maintenir la bas existante dans les logiciels bancaires. Par contre Fortran est encore très utilisé, y compris dans des nouveaux codes. Fortran me paraît surtout adapté pour remplacer le C, lorsque l’on manipule beaucoup de tableaux de données (qui sont une horreur à allouer/désallouer à la main en C) et est, de fait, très utilisé pour l’implémentation de méthodes numériques et d’outils de simulation où le plus important dans le programme est l’algorithme utilisé, et non la mise en place d’interfaces et de sous-systèmes en tout genre pour découper le code proprement (même si ça arrive avec les dernières versions du langage).
C’est un domaine parallèle à l’informatique et peut-être méconnu par les informaticiens de formation, mais je vois tous les jours des codes Fortran (essentiellement 95), y compris pour de nouveaux développements, et je dois avouer qu’avec le temps je me mets à apprécier ce langage et comprends sa popularité dans le secteur de la recherche ou du développement de logiciels de simulation et de bibliothèques d’outils numériques.
[^] # Re: Perl 6
Posté par barmic . Évalué à 1.
La seule fois où j'ai eu à en rencontrer c'était Cast3m pour de la simulation nucléaire et c'était considéré comme une charge car tout le reste des simulateurs était en C++ et qu'ils aimeraient bien unifier les langages (d'après ce que j'ai compris fortran commencent par allouer une mémoire qu'il manipule ensuite et l'un de leur projet était d'interfacer le C++ et le fortran via cette mémoire).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Perl 6
Posté par tildebis . Évalué à -1.
De mémoire dans Cast3M, c'est une extension du Fortran développée au CEA (appelée Esope)
qui est surtout hyper boulet ainsi que le langage de script pour coder les procédures
(pour lequel 2+3*4 == 5*4, pas de priorité dans les opérateurs par exemple).
Bref, je ne pense pas que ce soit le Fortran en tant que langage qui soit considéré
comme une charge (pour l'interface mémoire, elle existe avec du Python mais de ce que
j'ai compris elle est loin d'être stable).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.