Bonjour,
Perl 5.14.0 vient de sortir, au programme (entre autre) :
Gestion d'Unicode 6.0 avec plein d'améliorations concernant les fonctionnalités basées sur Unicode.
Gestion améliorée d'IPv6
L'autoconfiguration du client CPAN s'est simplifiée
Un nouveau drapeau /r qui fait des substitutions s/// non destructives
Un nouveau drapeau pour les expressions rationnelles pour indiquer si une chaîne marquée doit-être traitée comme du ASCII ou de l'Unicode.
Nouvelle syntaxe package Foo { }
Utilisation de la mémoire et du CPU réduite
Télécharger :
http://search.cpan.org/dist/perl-5.14.0/
Consulter la liste complètes des nouveautés :
http://search.cpan.org/~jesse/perl-5.14.0/pod/perldelta.pod
# Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Et qu'en est-il de Perl 6 ? Cela fait des années qu'on en parle et j'ai l'impression de ne voir toujours rien venir. Entre temps, le projet Python 3000 a été lancé et achevé, tout de même.
[^] # Re: Perl 6 ?
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Ca avance en parallèle. En fait, pas mal de bonnes idées proviennent de Perl6 et sont implémentés dans Perl5.
Il ne faut pas comparer Python3000 et Perl6, ce ne sont pas du tout des projets de la même ampleur. Il y a un paquetage rakudo dans debian experimental. Parrot commence a être déjà dans plusieurs versions de debian, Il est même dans squeeze.
Un des bénéfices de Perl6 ces dernières années, c'est que le langage Perl5 est reparti de plus belle et que cela bouge bien dans le bon sens !
[^] # Re: Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -10.
Ça bouge ? Eh bien, qu'est-ce qu'il ne faut pas entendre… Un projet de refonte du langage qui traîne depuis 10 ans sans qu'on en voie le bout…
Enfin, je m'en fiche, moi je code en Python, et moins je vois de Perl mieux je me porte.
[^] # Re: Perl 6 ?
Posté par B16F4RV4RD1N . Évalué à 10.
en python 2 ou en python 3 ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
En Python 3.
[^] # Re: Perl 6 ?
Posté par zebra3 . Évalué à 3.
Les deux : man 2to3
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Perl 6 ?
Posté par Krunch (site web personnel) . Évalué à 8.
Le projet Perl 6 avance à son rythme. C'est déjà utilisable mais considéré comme pas fini et, bien que d'un point de vue externe ça peut avoir l'air de stagner, on peut clairement voir une activité régulière aussi bien dans le repo de la spécification que de celui de Rakudo (sans doute l'implémentation principale pour le moment). De plus il s'agit plus d'un nouveau langage que d'une refonte. C'est plus comparable à C vs C++ (tiens C++0x est toujours pas fini mais il y a des gens qui l'utilisent déjà ?) que Python 2 vs Python 3.
https://github.com/perl6/std/
https://github.com/rakudo/rakudo
http://perl6.org/
Le début de cette vidéo qui date de novembre 2010 explique assez bien l'état de Perl 6 et sa relation avec Perl 5 je pense : http://osdc.blip.tv/file/4442577?filename=Osdc-Perl6Update962.ogv
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Perl 6 ?
Posté par Maclag . Évalué à 4.
C'est d'ailleurs ce qui porte à confusion.
Est-il toujours pertinent d'appeler Perl6 "Perl"?
Ce serait plus simple de lui donner un nouveau nom et de dire que Perl5 avance de son côté, parce qu'on ne sait plus si les deux sont censés co-exister par la suite (Perl5 avance tellement bien), ou s'il faut retenir son souffle parce que Perl5 va ensuite être lentement abandonné au profit de Perl6.
En attendant je proteste, c'est OCaml qu'est plus mieux que les autres.
Débrouillez-vous pour savoir si j'ai 3 jours de retard ou 4 d'avance!
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . Évalué à 1.
Si tu penses qu'OCaml est mieux que la concurrence, c'est plutôt en années de retard qu'il faudrait compter :)
/me est déjà dehors.
[^] # Re: Perl 6 ?
Posté par Michaël (site web personnel) . Évalué à 2.
Quel est ton reproche envers OCaml? Le langage offre des caractéristiques très intéressantes et peu répandues (voir uniques si on compare aux langages les plus populaires). Un accés au shell simple et de qualité remarquable (OCaml net/shell) permet de tirer parti au maximal de la flexibilité d'UNIX.
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . Évalué à 10.
[^] # Re: Perl 6 ?
Posté par claudex . Évalué à 7.
Alors que ça fait un baille de 95 est sortie.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Perl 6 ?
Posté par Maclag . Évalué à 2.
Ben alors je lance un troll tout velu un lundi, et y'a encore des gens pour sortir des arguments pertinents.
...
Je sais plus quoi dire!
Si: la 3.12, c'est plus qu'une release mineure, y'a des choses dedans! Et si elle ne sort pas officiellement sous Win, quid des suivantes?
J'ajouterais:
Joyeux bordel aussi, le support sous Windows:
- Cygwin, mais faut se taper cygwin.dll pour que ça marche
- Mingw, mais "y-a-pas-tout-qui-marche" (j'ai tenté une fois Godi avec le port Mingw, il y a toujours une lib dont t'as vraiment besoin qui passe pas).
C'est d'autant plus dommage qu'avec tous les gens qui ont des cours sur OCaml en prépas, il y a un vivier de développeurs potentiels pour conquérir le monde!
Y'a des dévs OCaml de l'INRIA qui traînent dans le coin?
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . Évalué à 2.
Quand je parlais de release mineure je voulais parler de 3.11.1, qui n'a pas été release sous Windows non plus.
En vrai le support d'OCaml sous Windows a commencé à mourir avec l'introduction de Dynlink en mode natif, qui a obligé à tout compiler avec flexdll sous Windows pour avoir un comportement du dynamic linker identique à celui traditionnel sous UNIX. C'était genre vers 3.09 ou 3.10 il me semble. Avant tout passait assez correctement avec mingw et msys, maintenant il faut hacker... Tout ça pour une feature dont personne ne se sert au final.
C'est bête, OCaml ça a été ma première introduction à la programmation fonctionnelle, mais ça a vraiment vieilli vite dans ma tête depuis que je me suis mis un peu à Haskell. Je sais pas ce que je ferais sans typeclasses de nos jours :)
En même temps c'était voué à l'échec depuis un moment. J'ai l'impression qu'il y a de moins en moins de gens de l'INRIA qui bossent sur OCaml, et historiquement le projet a toujours été très fermé à toutes les contributions externes. C'était clair qu'à un moment ça allait casser.
[^] # Re: Perl 6 ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je crois que c'est un des soucis de l'INRIA. Ils ont mis des années à libérer le code de scilab... Il y a plein de projet intéressant mais qui en pratique les utilisent réellement ? Bref, ils n'arrivent pas à créer une communauté ouverte sur leur projet. C'est vrai que c'est décevant.
[^] # Re: Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Les prépas. Pour ce qui est de Caml en tout cas.
[^] # Re: Perl 6 ?
Posté par Sarcastic . Évalué à 1.
Oui, enfin, c'est plus pour faire de l'algo qu'autre chose. On n'a pas besoin d'Ocaml, d'ailleurs : Camllight nous suffit pour ce qu'on fait.
Donc, c'est pas vraiment une « utilisation pratique ».
[^] # Re: Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Oui, mais bon, Camllight c'est chouette mais c'est un peu abandonné comme projet non ?
[^] # Re: Perl 6 ?
Posté par Sarcastic . Évalué à 1.
D'un autre côté, c'est l'éducation nationale, les choses n'évoluent donc pas vite.
Enfin, après, faut dire, pour ce qu'on fait, on est loin d'avoir besoin de beaucoup plus qu'un vieux projet abandonné : on s'en sert surtout pour faire de l'algo de base sur des arbres et des automates, et on n'a besoin d'aucune bibliothèque externe.
Heureusement, cela dit. Le système de typage de Camllight est vraiment trop pénible à mon goût.
[^] # Re: Perl 6 ?
Posté par Michaël (site web personnel) . Évalué à 3.
Un peu comme en C et tout un tas d'autres langages.
Tu aurais du garder ton programme :)
Tu as un exemple où la sortie de ocamldep n'est pas bien triée? Cela fait depuis suffisamment longtemps que je programme en caml pour m'étonner.
C'est ça, si tu veux profiter des multiples processeurs il faut forker ton processus.
C'est sûr que quand on code en OCaml, on est plutôt en famille :) Il y a une liste plus complète des sociétés s'intéressant à OCaml: http://caml.inria.fr/consortium/
De ces inconvénients je retiens surtout la petite dimension de la communauté d'utilisateur, qui implique un nombre assez restreint de contributions de bibliothèques.
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . Évalué à 4.
Tu penses que c'est un bon point pour OCaml d'être comparé au C ? :-)
C'était dans des contextes différents en fait. Et c'est pas que la sortie d'ocamldep n'est pas bien triée, c'est plutôt qu'il ne fait pas ce dont j'avais besoin ici.
En gros, le cas d'utilisation, c'est que j'ai une liste de .ml dans un ordre quelconque, et je dois les compiler en .o pour les linker avec du C++ derrière. ocamldep est incapable de me sortir les trucs dans le bon format (il ne sait générer que des foo.cmo: foo.cmi et foo.cmx: foo.cmo, ou alors la forme « brute » qui est « a: b c ». Dans tous les cas, avoir besoin d'ocamldep pour linker son binaire c'est honteux : pourquoi est-ce que le linker d'OCaml ne sait pas faire ce travail tout seul ?
Et induire une plus grosse utilisation de mémoire et des IPC. Cool.
Il y a aussi un autre problème que je vais illustrer par deux exemples. Je cherche une lib OCaml qui binde OpenGL. J'ai le choix entre LablGL, glcaml, glmlite et un autre dont j'ai plus le nom en tête. Pareil pour SDL : sdlcaml et ocamlsdl. Sans compter que la plupart des ces libs sont buggées et non maintenues (il y a des bouts de l'interface SDLmixer d'OCamlSDL qui segfaultaient systématiquement à cause d'une typo dans le code C il y a environ un an, c'est peut-être encore le cas, j'en sais rien).
[^] # Re: Perl 6 ?
Posté par Dr BG (site web personnel) . Évalué à 3.
Euh le 4 n'est pas un numéro de version, c'est pour les quatre P de « Pre-Processor-Pretty-Printer ». Camlp5 est un autre projet avec quelques idées différentes. Comme RPM et RPM5 !
[^] # Re: Perl 6 ?
Posté par gasche . Évalué à 6.
Ton évaluation du langage est intéressante mais inutilement aigrie. Tous les langages ont leurs défauts, et il est important de bien en être conscient. Mais ce n'est pas une raison pour être inutilement négatif : si tu arrives à convaincre des gens par des arguments non rationnels, tu ne leur rends pas service (puisqu'ils vont faire un autre choix de langage en croyant éviter les problèmes, pour découvrir ensuite qu'ils ont les mêmes problèmes ou d'autres).
La bibliothèque standard est minimaliste. Pas "vide", mais pas suffisante. Comme tu le dis, il existe d'autres bibliothèques de base, dont je ne sais pas si elles "règlent le problème" (elles restent moins étendues par exemple que la bibliothèque standard Python).
Sauf que c'est essentiellement un faux problème : le problème n'est pas la taille de la bibliothèque standard (qui a la plus grosse ?) mais la relative difficulté d'adoption des bibliothèques tierces. Ce qui fait la force de Perl ce n'est pas en soit la bibliothèque standard (qui dans mon souvenir n'a rien d'extraordinaire), mais le CPAN qui permet d'accéder à un énorme écosystème facilement.
Alors oui ça manque pour OCaml (par rapport à Perl, Haskell (cabal), Python etc.) mais c'est un problème de communauté plutôt que de langage. C'est en travail : GODI n'a pas su convaincre, maintenant on parie sur Oasis-DB.
Par ailleurs pour le détail, "@@" et "@$" ne sont sérieusement utilisés que par asmanur à ma connaissance (donc "tout le monde" on repassera), et ta façon de compter est un peu discutable puisque Batteries est une extension conservatrice par dessus Extlib. Tu ne comptes pas "Core" et "Core Extra" comme deux bibliothèques. Enfin je ne comprends pas "ce n'est pas une excuse", peux-tu développer ?
Qu'est-ce que ça veut dire ? De nos jour tout le monde utilise findlib. On juge les langages sur leur "distribution de base" maintenant ? Je pense que tu as mieux à critiquer que les choix de packaging des distributions.
Forcément, quand on part d'un script qui envoie
*.mlà la chaîne de compilation, c'est chiant. Par contre si on fait des choses un poil propres (oui, il faut respecter l'ordre de dépendance), il n'y a pas de problème selon mon expérience personnelle (et encore moins de problèmes depuis ocamlbuild qui, si si, possède une documentation). En particulier j'ai jamais eu à coder un tri topologique (buggué ou non :-) pour ça, et je trouve un peu douteux de projeter vos propres erreurs de conception sur le langage lui-même.http://brion.inria.fr/gallium/index.php/Ocamlbuild
Je ne comprends pas. OCamlbuild n'utilise pas à ma connaissance d'extensions syntaxiques particulières. Tu parles de la difficulté à compiler un projet qui utilise ses propres extensions syntaxiques ? Selon mon expérience (Macaque par exemple) ce n'est encore une fois pas un problème (car contre attention à la combinaison camlp4 + ocamldoc, qui font mauvais ménage ensemble; en règle générale j'évite de préprocesser les .mli pour éviter tout soucis de ce genre).
Ben non, tu peux très bien compiler 3.12 sous windows (la raison pour laquelle personne ne se plaint c'est que la plupart des windows-users font ça; après je comprends que tu trouves ça pas cool pour les débutants). Si tu as envie de proposer un binaire un peu portable en téléchargement, fais-toi plaisir. (Bah oui c'est facile de se plaindre du manque de communauté et de tout faire dans son coin derrière)
Bof. Depuis la 3.12 tu peux te faire tes smooth operators si ça t'amuse, et en vrai (+/) n'est pas spécialement moche (un peu lourd syntaxiquement, mais pas moins par exemple que l'émulation du pattern matching dans un langage qui ne le propose pas).
Bien vu, il y a des problèmes politiques autour de camlp4/5. Je doute que ça ait une grande importance sur le langage OCaml dans son ensemble, et en tout cas ce n'est pas la question du nom du logiciel qui importe.
Marrant de mentionner ça dans une news sur Perl, à ma connaissance ni Perl ni Python ni Ruby n'ont mieux à proposer dans ce domaine. Et dans tous ces langages, comme pour OCaml, on répond en cœur aux gens d'utiliser le multi-processing, et curieusement le net n'est pas noirci de blog "c'est un scandale, les programmes python sont monothreaded". John Harrop est bon pour répandre du FUD quand ça l'arrange, mais je trouve dommage qu'ensuite les gens se focalisent là-dessus.
Il y a effectivement un choix qui a été fait de ne pas favoriser la concurrence par mémoire partagée au sein d'un même processus. Les développeurs OCaml ont évalué que le coût de développement d'un runtime concurrent était bien trop élevé par rapport aux bénéfices que ça représente, en particulier parce que (a l'époque du choix et toujours aujourd'hui) on n'a pas de bons outils de programmation de la mémoire concurrente.
Je ne vais pas écrire un pavé sur le sujet mais je pense honnêtement qu'ils ont fait le bon choix.
En pratique ça handicape certains programmes qui tiennent sur du multi-core (et n'ont pas besoin de passer à l'échelle sur un cluster par exemple) et utilisent beaucoup de partage de donnée (donc ne sont pas trop efficaces en passage de messages à la Erlang).
Ça n'est pas le cas de l'ensemble des programmes concurrents (par exemple le cas classiques des problèmes naturellement parallèles passent très bien avec du multi-processing); en réalité, seule une minorité d'usages est concernée. C'est dommage pour les gens qui veulent programmer précisément ça (et dans ce cas je leur conseille de changer de langage), mais ça n'est pas une raison pour fuir le langage pour tous les usages.
Par ailleurs, si tu veux faire de la programmation concurrente "salement" comme en C, je pense qu'un bon choix aujourd'hui pour OCaml est Netmulticore (de OCamlnet). Il manque clairement pour l'instant des bibliothèques haut niveau pour utiliser ça facilement, mais ça vient (et ça vient d'autant plus que des gens participent).
Je me permets donc de finir cette remarque par une question concrète : as-tu un exemple réel de situation où les différents outils disponibles en OCaml pour le parallélisme ne permettaient pas de résoudre un problème, alors que c'était le cas par exemple des outils Haskell ou .NET ? Je suis intéressé par un exemple que tu as réellement vécu, et pas par un lien vers John Harrop. Je ne dis pas ça pour prouver que ces exemples n'existent pas, je suis persuadé qu'il y en a, mais je pense qu'ils sont en fait assez rares (c'est à dire que certains besoins les rencontrent, mais la plupart non) et qu'il serait donc étrange de changer globalement de langage pour cette seule raison.
C'est vrai que la communauté Haskell est plus active, et surtout que le développement est (un peu) plus communautaire. À mon avis la relative fermeture du développement est le plus gros défaut de OCaml aujourd'hui, plus sérieux que tout le reste que tu as cité.
Ce n'est pas non plus une raison pour dire n'importe quoi. De nombreuses entreprises ou institutions utilisent très sérieusement OCaml, et à ma connaissance plus que pour Haskell. Je pense par exemple au CEA, à Dassault, à la Société Générale, Jane Street que tu as cité et Lexifi, XenSource, Airbus, Microsoft (qui a utilisé OCaml pour faire de la vérification statique de drivers avant de développer F#; je crois qu'une partie de leur code est toujours en OCaml, mais je n'en sais rien)...
Toutes ces informations sont assez facilement trouvables sur le net. Je me demande comment tu as fait pour croire qu'il n'y a qu'une seule entreprise soutenant OCaml.
Par ailleurs, je ne veux pas faire une course, mais quelle entreprise visible "soutient" Haskell, à part les excellents gens de chez Galois ?
Enfin je pense qu'il y a un aspect du langage que tu as oublié de citer: le compilateur produit du code performant de base mais optimise assez peu. Par rapport à Haskell, ça a l'avantage qu'il est assez facile de prévoir les performances du programme (pas de mauvaises surprises en général), mais l'inconvénient que certaines abstractions ont un coût important qui ne disparaît pas, ce qui pousse les utilisateurs à éviter certaines choses pourtant agréables comme les bibliothèques de combinateurs.
.
Je pense que pour apprécier, aussi bien que pour critiquer, un langage, il faut avoir une idée de ce qu'on en attend et de notre besoin dans l'utilisation du langage. Tous les langages ont leurs défauts et OCaml (ou Haskell ou Python ou Perl ou...) n'est pas épargné. L'important c'est de savoir quand ces défauts seront gênants pour l'utilisation qu'on en fait (problème), et quand ça ne l'est pas. Selon mon expérience, la plupart des défauts que tu as cités ne sont un problème que pour un petit nombre d'utilisateurs.
J'ai déjà vu des gens critiquer OCaml pour ses problèmes de parallélisme par exemple, alors qu'ils ne comprenaient même pas quels cas posaient problème, et n'avaient de toute façon pas besoin d'écrire ce genre d'applications. Je crois que quand on est face à ce genre de défauts il faut savoir rester objectif au lieu de choisir le "camp" du langage qui a le moins de détracteurs bruyants.
J'apprécie beaucoup Haskell et OCaml comme langages et je pense qu'ils sont relativement complémentaires. Je comprends très bien que des gens préfèrent utiliser Haskell et je les y encourage, mais je ne suis pas persuadé qu'il y ait des "années de différence" par rapport à OCaml, et je regrette un peu cette formulation négative.
[^] # Re: Perl 6 ?
Posté par Michaël (site web personnel) . Évalué à 1.
Bravo, c'est exactement la réponse que j'aurais aimé avoir écrit!
[^] # Re: Perl 6 ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Ce n'est pas très gentil de lui reprocher de ne pas avoir chercher les entreprises qui font du OCaml sur internet alors que tu ne l'as visiblement pas fait pour Haskell. Je ne connais pas Haskell mais il ne m'a pas fallu plus de 30 secondes pour trouver http://www.haskell.org/haskellwiki/Haskell_in_industry .
[^] # Re: Perl 6 ?
Posté par Krunch (site web personnel) . Évalué à 4.
C'est abordé dans le début de la vidéo. Damian Conway pense que Perl 6 ne devrait pas s'appeller Perl mais Larry Wall pense que si et c'est quand même son langage. Perl 6 reste très Perl quand même. Perl 5 et Perl 6 sont censés co-exister mais il est inévitable que des fonctionnalités de 6 se retrouvent dans 5. Il y aura « toujours » des utilisateurs de Perl 5 comme il y a toujours des utilisateurs de Perl 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Perl 6 ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je pense que Perl5 fonctionnera encore des années... Je ne serais pas étonner que dans 10 ans, il y ai encore les deux qui soit en fonctionnement.
[^] # Re: Perl 6 ?
Posté par Michaël (site web personnel) . Évalué à 4.
Comme Fortran et COBOL: il y a une base de programmes existants beaucoup trop importante pour envisager la disparition du langage…
[^] # Re: Perl 6 ?
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
C'est assez différent en fait. Perl6 est un nouveau langage réalisé par la même communauté que Perl5. C'est un langage de script de plus. Il n'est pas illogique qu'à terme, certains langages de script deviennent secondaires...
Fortran, pour ne parler que de lui, n'a pas eu d'enfant pour le moment qui arrive à lui survivre ! Par ailleurs, bien que ce soit un des langages les plus anciens, c'est un langage qui vit. La plupart des programmes écrit aujourd'hui en Fortran le sont en Fortran 95 (90) mais la révision de 2003 apporte les objets et l'héritage simple que gfortran implémente déjà. La grosse étape suivante est la gestion des Co-Array (Fortran 2008) qui permet de manipuler des tableaux répartis sur un cluster.
Bref, Fortran est un très bon langage pour les scientifiques et contrairement à ce que l'on pourrait penser, le Fortran moderne est lisible ;-) Il n'y a pas vraiment de conçurent à Fortran parmi les autres langages compilés. Je connais des codes en C++ mais c'est souvent la croix et la bannière pour les thésards ou les stagiaires qui doivent bosser dessus et adapter le code source. De plus, certain concept du C comme les pointeurs sont une aberration pour les non informaticiens. Les pointeurs du Fortran ou l'on ne manipule jamais la notion d'adresse mais qui ont un opérateur d'assignation différent sont par exemple bien plus propre.
Une des erreurs du Fortran (et de presque tous les autres langages compilés) est que la norme ne définie pas le mapping entre les objets du Fortran et ceux que l'on retrouve dans les bibliothèques compilés. Ainsi, les fichiers .mod sont différents entre deux compilateurs et chaque compilateur choisis sa sauce lors de la compilation pour nommer les appels de fonction dans les bibliothèques .so et .a !
[^] # Re: Perl 6 ?
Posté par jbbourgoin (site web personnel) . Évalué à 5.
Moins vous voyez du perl mieux vous vous portez ? Vous devriez vous réjouir alors de voir Perl 6 "stagner" (dans les faits c'est loin d'être le cas).
[^] # Re: Perl 6 ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -3.
Pas vraiment non, parce que je préférerais voir du Perl 6 que du Perl 5 ! :-)
[^] # Re: Perl 6 ?
Posté par zebra3 . Évalué à 2.
Question idiote : à quoi sert Perl6 dans ce cas ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Perl 6 ?
Posté par claudex . Évalué à 4.
hint: pas mal != toutes
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Perl 6 ?
Posté par zebra3 . Évalué à 3.
Il y aura bien une version 5.15.0 pour corriger cela :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# IPv6
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Bien ! Est-ce à dire que c'est enfin la fin de ce bordel ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.