Journal Utilisation de Perl aujourd'hui.

Posté par  . Licence CC By‑SA.
Étiquettes :
19
6
oct.
2024

Hello.

En répondant à une demande à propos de Vim/regexp sur le forum, je me suis souvenu de mes premiers pas avec les regexp. J'ai essayé de me remémorer les meilleures docs que j'ai lues à ce sujet, et il me semble que celle qui m'a permis de vraiment les comprendre est le livre "programmation Perl - 3eme édition" qui dissèque de manière très claire et très précise les regexp, et de fil en aiguille je me suis demandé ce que devenait Perle aujourd'hui.

En effet, ce langage a été très prisé à une époque. En dépit de sa syntaxe assez pzrmissive, qui permettait de faire des trucs vraiment très cool mais que l'on arrivait plus à déchiffrer 3 jours après, ce langage avait quand même un certain nombre de points forts, parmi lesquels :
- une rapidité d'exécution relativement proche de celle d'un programme compilé : dans une de mes précédentes missions, Perl a été choisi à la place de python à cause de cette caractéristique : il y a eu des benchmarks de faits entre C, Python et Perl, et le constat était sans appel : le Perl était presque aussi proche en terme de perf que le C, et le python se trainait assez loin derrière.
- la souplesse de la syntaxe et de la "grammaire" : il s'agit d'une lame à deux tranchants, mais cette souplesse est très agréable lorsqu'on code. En effet, le langage n'impose pas grand chose. Ce n'est pas au développeur de s'adapter, lui et son problème au langage, mais c'est le langage qui s'adapte au problème à résoudre. Je sais que ça déplait à certaines personnes, qui aiment les chemins bien bornés, mais pour ma part, je me sens "enfermé" avec Python, bien plus qu'avec Ruby, Perl, ou même Go. Alors certes, Perl va très loin dans la permissivité, mais avec quelques directives bien placées, on peut avoir du code lisible et maintenable (j'ai vu du code python en apparence bien écrit, et bien indenté, qui syntaxiquement était correct, bien moins maintenable qu'un code Perl écrit en respectant les règles et bonnes pratiques de base d'écriture de code et d'organisation de celui-ci ).

Du coup, aujourd'hui je me demande : J'ai vu qu'il y a eu des mise à jours de quelques bouquins Perl depuis 2019 (notamment chez O Reilly): si ça existe c'est que Ca s'utilise encore. Qui utilise encore Perl et pourquoi faire ? Est-ce pour maintenir du code existant, ou y a-t-il encore de nouveau projets qui utilisent Perl ?

Autre question : perl6. Il semble qu'aujourd'hui l'avenir de Perl ne soit plus Perl6. Pourquoi ? Pourquoi est-ce que ça n'a pas pris  ? Le syndrome Hurd ? Etait-ce trop ambitieux ?

Si quelqu'un suit (ou a suivi) Perl ces dernières années, je serais intéressé pour avoir quelques informations à ce sujet, ou des liens qui me permettraient d'avoir des réponses à mes questions. Merci d'avance à vous.

  • # performances

    Posté par  . Évalué à 8 (+6/-0).

    Il me semble que ton affirmation nécessite une référence. Pour ma part, ce que j'ai en tête, c'est plutôt que c'est aussi lent que python.

    https://programmation.developpez.com/actu/296868/Le-langage-C-ne-sera-t-il-jamais-battu-en-termes-de-rapidite-d-execution-et-de-faible-consommation-d-energie-Voici-les-resultats-d-une-etude-sur-27-langages-de-programmation-les-plus-populaires/

    • [^] # Re: performances

      Posté par  . Évalué à 6 (+4/-0).

      Il me semble que ton affirmation nécessite une référence.

      Je n'ai malheureusement pas de référence publique, ce benchmark avait été fait chez un opérateur réseau/téléphonie en interne( je l'ai vu lors d'une de mes missions chez cet opérateur), et date pas mal (une dizaine d'année je pense), et dans un contexte donné (gestion de trames SNMP dans une solution de supervision réseau style CACTI). Il est fort possible que Python se soit amélioré depuis par rapport à Perl. D'autre part, python "triche" un peu dans certains cas avec utilisation de bindings python vers bibliothèques écrites en C et compilées, donc on ne peut pas forcément parler de code natif.

      Celà dit le sens de mon propos n'est pas forcément d'affirmer qu'aujourd'hui, Perl est plus performant que Python. Ca a été le cas à une époque (au moins pour certains types de traitements), c'était un de ses points forts par rapport à Python, mais malgré cet avantage à ce moment, ce point n'a pas empêché celui-ci de perdre en popularité.

      • [^] # Re: performances

        Posté par  . Évalué à 6 (+4/-0).

        D'autre part, python "triche" un peu dans certains cas avec utilisation de bindings python vers bibliothèques écrites en C et compilées, donc on ne peut pas forcément parler de code natif.

        Il y a un peu plusieurs réponses a cela:

        • Perl utilise également des librairies compilées. Pourquoi re-ecrire un truc plus lent s'il existe deja une implémentation compilée ?
        • L'étude donnée en haut est purement en utilisant le language en question, sinon l'étude ne veut rien dire.
        • Le fait qu'en pratique, on utilise bien souvent des librairies compilées ou alors le programme est en train d'attendre les IO, implique qu'il ne suffit pas de réécrire un programme depuis Perl/Python en C pour qu'il aille 100 fois plus vite. Sinon personne n'utiliserait ces languages en fait.

        Après c'est tout a fait possible que dans le cadre d'un certaine domaine, Perl dispose ou disposait d'un meilleur écosystème et de meilleures performances.

        • [^] # Re: performances

          Posté par  (site web personnel, Mastodon) . Évalué à -1 (+3/-5).

          Mis a part les librairies compilées, le code Python est conceptuellement un langage hyper lent. Cela vient du fait qu'il a été conçu pour sa simplicité de programmation. Ses pythonneries sont hyper pratique mais très complexe à optimiser pour les compilateurs. A l'inverse PERL est basé sur les regexp ce qui le rends bien plus efficace si l'on programme en bon PERL car les Regexp sont compilable facilement.

          Après, c'est certains, qu'en pratique, les moyens de Python n'ont rien a voir avec ceux de PERL. Il est donc probable que les défauts de Python soient largement compensés par les efforts surhumains déployés pour améliorer ses perfs.

          Les 2 langages restent des langages interprétés non typés intrinsèquement lent. Je préfère Julia quand on peut pour ses performances (Et son typage).

          Reste que Python est largement plus populaire et plus simple à mettre en place partout… au moins pour les prototypes.

          Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

          • [^] # Re: performances

            Posté par  . Évalué à 8 (+6/-0). Dernière modification le 06 octobre 2024 à 21:51.

            Python est conceptuellement un langage hyper lent […] A l'inverse PERL

            Pures spéculations qui vont à l'encontre de la conclusion postée dans le commentaire plus haut : Perl et Python au coude à coude, environ 75x plus lent que C.

            PERL est basé sur les regexp […]

            Je ne suis même pas sûr de comprendre ce que ça peut vouloir dire, les regeexp ne sont pas Turing complete, Perl si.

            car les Regexp sont compilable facilement

            Facilement compilable, oui (machine à état) mais leur temps d'exécution est très peu maîtrisable ; en gros, modifier un peu une regexp rapide peut la transformer en une regexp lente. Bref compilation != exécution.

            efforts surhumains

            Par définition, non ; ce sont bien des êtres humains qui écrivent les interpréteurs python tout comme les complilateurs des autres langages qui ne sont jamais une mince affaire.

            Je préfère Julia quand on peut pour ses performances (Et son typage).

            Là ok, interprété ~= lent et typé ~= rapide ; on peut d'ailleurs accélérer Python en le typant (on peut aussi faire du Jit) ; je ne sais pas si ça a été tenté pour Perl.

            Python … au moins pour les prototypes

            Attaque classique, mais sans fondement ; Python est en prod (Instagram, Spotify, Dropbox, Reddit, Pinterest, Quora, YouTube) de même que Perl (IMDb, Slashdot, LiveJournal, Bugzilla), Ruby (GitHub, Basecamp, Shopify, Twitch, Airbnb, Hulu) ou Php (Facebook, WordPress, Wikipedia, Tumblr, Slack, Mailchimp, Drupal).

            • [^] # Re: performances

              Posté par  . Évalué à 4 (+2/-0).

              Par définition, non ; ce sont bien des êtres humains qui écrivent les interpréteurs python tout comme les complilateurs des autres langages qui ne sont jamais une mince affaire.

              Je pense au contraire que si. La complexité de ces choses là dépassent l'humain et sont le travail d'une communauté qui produisent un effort dépassant ce que l'humain peut produire.

              J'avais aussi en tête que python était plus lent que perl, mais surtout que démarrer l'interpréteur perl était moins couteux et c'est une idée qui courrait à une époque où python 2 était la norme.

              Facilement compilable, oui (machine à état) mais leur temps d'exécution est très peu maîtrisable ; en gros, modifier un peu une regexp rapide peut la transformer en une regexp lente.

              Mais perl a déployé des trésors d'inventivité pour permettre de les rendre efficace en contrôlant le backtracking dans beaucoup de cas.

              C'est de mon point de vu frustrant de voir l'hégémonie de python là où j'adorerais voir une émulation entre python, perl et ruby. Mais on ne peut pas refaire le match et l'humain à minimat par la manière de se socialiser aime les positions dominantes (j'ai le même problème avec git/mercurial par exemple). Ça économise de la réflexion de suivre le mouvement plutôt que de choisir une solution qui serait (hypothétiquement) plus pertinent dans ton contexte. Ou dis autrement l'effet de groupe a une part importante dans l'évaluation de la pertinence d'un choix (les gens connaissent, il y a un écosystème, on te demande pas pourquoi avoir fait un choix)

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: performances

                Posté par  . Évalué à 3 (+1/-0).

                Challenger le status quo, trouver la meilleure option, explorer des sentiers plus exotiques, oui

                Dénigrer l'"adversaire" avec des arguments fallacieux ou tout du moins non étayés, bof.

                perl a déployé des trésors d'inventivité

                J'en doute pas, mais j'imagine que ces avancées pourraient être reprises dans un autre langage, car regesp n'est pas la syntaxe, c'est un outil.

                une émulation entre python, perl et ruby

                considérant le même code dans ces trois langages

                sub foo {
    my ($a, $b) = @_;
    return $a + $b;
}

sub bar {
    my ($func, $x, $y) = @_;
    return $func->($x, $y);
}

my $num1 = 5;
my $num2 = 10;

my $result = bar(\&foo, $num1, $num2);

print "The result of adding $num1 and $num2 is: $result\n";
                def foo(a, b):
    return a + b

def bar(func, x, y):
    return func(x, y)

# Main part
num1 = 5
num2 = 10

result = bar(foo, num1, num2)
print(f"The result of adding {num1} and {num2} is: {result}")
                def foo(a, b)
  a + b
end

def bar(func, x, y)
  func.call(x, y)
end

num1 = 5
num2 = 10

result = bar(method(:foo), num1, num2)
puts "The result of adding #{num1} and #{num2} is: #{result}"

                Si on commençait par la syntaxe 😉 ; IMHA ruby ≥ python > perl.
                Je taquine, la syntaxe c'est un peu l'âme d'un langage (sauf lisp like), difficile de tout chambouler.
                Mais j'aimerai fondamentalement comprendre ce qu'aime les aficionado du Perl.

                • [^] # Re: performances

                  Posté par  . Évalué à 4 (+1/-0).

                  J'ai un gros bémol sur ton code perl

                  les deux premiers point te permettent d'avoir une vérification qui manque cruellement au python, le 3eme (plus souple) permet une meilleur lisibilité;

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                  • [^] # Re: performances

                    Posté par  . Évalué à 2 (+0/-0).

                    Merci pour ta review.
                    Pour le premier point, ils y sont mais je les ai pas collé.
                    Pour les deux autres, je ne connaissais pas mais c'est bien dommage car ça aurait encore plus appuyé le propos.

                    sub bar($$$) {
    my $func = shift @_;
    my $x = shift @_;
    my $y = shift @_;
    return $func->($x, $y);
}

                    à comparer à

                    def bar(func, x, y):
    return func(x, y)

                    tu n'as pas spécifié le nombre d'arguments : sub foo($$)

                    tu n'as pas nommé les arguments par exemple (https://dev.to/nicholasbhubbard/named-subroutine-arguments-in-perl-2a3h) pour la fonction bar :P

                    Dans l'exemple pour le point 3, il n'applique pas le point 2:

                    sub safe_open {   # <= là, ça devrait être safe_open($$$)

    my $file = shift @_;
    my $mode = shift @_;
    my $die_on_failure = shift @_;
    # ...
}

                    • [^] # Re: performances

                      Posté par  . Évalué à 6 (+4/-0).

                      En utilisant les signatures

                      sub bar($func, $x, $y) {
    return $func->($x, $y);
}

                      Mais bon c'est un bout d'exemple, les lambda sont plus sympa a écrire en perl qu'en python. Perl a une forme de pattern matching assez cool quand python a un switch depuis 1 ans ou 2, je préfère le modèle objet de python par contre, mais c'est agréable pour moi de pouvoir écrire des post conditions say 'hello' if x;, je préfère ipython en REPL, mais j'adore les one-liner de perl,… ruby je connais moins il a des possibilité de méta programmation très cool, mais il y a des lacunes que je ne comprends pas comme le fait d'une variable constante ne l'ai pas effectivement

                      On a pas besoin de se choisir une église et de la vénérer tout en insultant le reste.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: performances

                        Posté par  . Évalué à 4 (+2/-0).

                        j'adore les one-liner de perl

                        Ca c'est le genre de trucs qu'on adore écrire, mais qu'on déteste relire :-)

                        ruby je connais moins il a des possibilité de méta programmation très cool

                        La syntaxe ruby est vraiment très propre, ce qui autorise cette meta programmation. Bon apres les metaclasses python, c'est pas mal non plus.

                        La doc ruby est aussi vraiment propre. Quand tu arrives sur python et ses special methods qui ne sont pas vraiment documentes, mais qu'il est largement autorise de redéfinir si tu lis les PEP, c'est pas genial.

                        • [^] # Re: performances

                          Posté par  . Évalué à 2 (+0/-0).

                          Ca c'est le genre de trucs qu'on adore écrire, mais qu'on déteste relire :-)

                          Franchement non et c'est un truc que la plupart des gens me disent de n'importe quoi que j'écris dans mon terminal même si c'est du bourn avec un ou 2 binutils

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: performances

                        Posté par  . Évalué à 2 (+0/-0).

                        En utilisant les signatures

                        C'est un souhait ou c'est sensé marcher ?
                        Parce que chez moi ça fait Malformed prototype for main::bar: $func, $x, $y at firstclassfunc.pl line ; perl 5.36.

                        On a pas besoin de se choisir une église et de la vénérer tout en insultant le reste.

                        Tout à fait. Par contre à un moment il faut choisir un outil et on ne peut pas tous les maîtriser, en particulier les maîtriser à un niveau qui soit productif.

                        • [^] # Re: performances

                          Posté par  . Évalué à 3 (+1/-0).

                          C'est un souhait ou c'est sensé marcher ?

                          Parfaitement oui, faut juste savoir que perl est tellement conservateur que les fonctionnalités doivent être activées (pour l'exemple les signatures sont arrivées expérimentales en 2015 et 7 ans plus tard sont devenues stable, mais il faut toujours les activer).

                          Tout à fait. Par contre à un moment il faut choisir un outil et on ne peut pas tous les maîtriser, en particulier les maîtriser à un niveau qui soit productif.

                          Bien sûr mais tu fais un choix en fonction de différents paramètres qui peuvent être aussi flous et subjectifs que "j'aime mieux" (ce qui peut être tout à fait pertinent), il n'y a pas besoin d'expliquer à tous que les autres options sont de la merde pour se rassurer qu'on a fait un bon choix.

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: performances

              Posté par  (site web personnel, Mastodon) . Évalué à 1 (+1/-1).

              efforts surhumains

              Comme si tu ne comprenait pas? PERL est un langage ou la communauté est bien plus restreinte que Python… par conséquent les moyens aussi. Avec de gros moyens on peut faire beaucoup… dont améliorer les perfs… ce qui explique qu'aujourd'hui les perfs de Python soient comparable à PERL même si de base Python est plus lent (Python est mieux optimisé).

              Python est en prod

              Évidemment mais cela ne veut pas dire que ce soit toujours ce qu'il y a de plus judicieux et quand je dis "Python pour les prototypes" ce n'est pas une affirmation absolu mais une visée. Dans certains cas la performance est secondaire et l'évolutivité primordiale. Python a toute sa place dans les scripts d'admin ou de lancement d'applis ou dans les applis sans besoin de ressources. YouTube en tout cas ne tourne pas en Python. Ils ont surement des scripts de management en Python, mais le cœur est compilé et hyper optimisé.

              Php (Facebook)

              Non, Facebook a créé Hack pour justement accélérer PHP et a retranscrit sa base de code. Et après Hack a été plus ou moins intégré à PHP… Mais PHP n'est pas aussi lent que Python. D'ailleurs PHP est plus rapide que Python, je ne vois pas ce qu'il vient faire là.

              Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

              • [^] # Re: performances

                Posté par  . Évalué à 2 (+0/-0). Dernière modification le 08 octobre 2024 à 12:19.

                Évidemment mais cela ne veut pas dire que ce soit toujours ce qu'il y a de plus judicieux et quand je dis "Python pour les prototypes" ce n'est pas une affirmation absolu mais une visée. Dans certains cas la performance est secondaire et l'évolutivité primordiale.

                Dans certains cas comme le machine learning ou l'analyse de données, la performance est primordiale et c'est pour ca que python est choisi.

                • [^] # Re: performances

                  Posté par  . Évalué à 8 (+6/-0).

                  Dans certains cas comme le machine learning ou l'analyse de données, la performance est primordiale et c'est pour ca que python est choisi.

                  Bah c'ezst pas réellement du Python, il y a beaucup de binding python vers C. Ce n'est pas un reproche ni une attaque, mais une précision qui me parait importante, car dans ce cas on ne peut pas dire qu'on choisit python pour ses perfs. Les perfs, c'est le code C compilé qui l'assure.

                  • [^] # Re: performances

                    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 08 octobre 2024 à 16:29.

                    L'autre jour je devais faire une aggregation sur un grand nombre d'elements stocke dans une table postgre.

                    Je commence par une requête SQL classique => c'est lent. Je check les index avec ANALYZE EXPLAIN, tout est bon. Bref, pas d'explication, c'est juste lent. J'essaie de bricoler des materialized view, franchement c'est galère, c'est pas terrible.

                    Je fais le goret, j'importe la table dans une dataframe pandas, je fais mon aggregation => bim c'est rapide.

                    OK alors, quand je dis qu'on choisit python pour les performances, je trolle peut etre un peu en faisant un raccourci mais c'est vrai. On choisit python pour son écosystème d'outils qui sont très performants. Si vous avez beaucoup de données a traiter/aggreger de plein de manières différentes, c'est certainement le meilleur choix que vous pouvez faire.

                    • [^] # Re: performances

                      Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-0).

                      Si vous avez beaucoup de données a traiter/aggreger de plein de manières différentes, c'est certainement le meilleur choix que vous pouvez faire.

                      Non, mais oui.
                      Non car clairement il y a beaucoup plus performant : Rust.
                      Mais en pratique c'est vrai que généralement tu as à le faire 1 fois de temps en temps dans ce cas ce qui compte ce n'est pas la performance mais la rapidité à le développer et généralement un compromis.
                      Alors là oui Python est intéressant notamment car il a plein d'outils performant… encore faut-il les connaître car en Python pur sans panda, numpy et Cie…

                      PS: je pense que SQL est quand même capable d'être plus rapide. Mais je sais que nous étions plus rapide que SQL en faisant un "select into outfile" en MySQL et agrégation en C…

                      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

            • [^] # Re: performances

              Posté par  . Évalué à 2 (+0/-0).

              Attaque classique, mais sans fondement

              Pourquoi voir une attaque là ou il n'y en a pas ?

  • # Perl 6 => Raku

    Posté par  . Évalué à 10 (+9/-0).

    La branche de développement 6 de Perl a finalement dérivé en un nouveau langage: Raku. (voir aussi la page WikiPédia de ce langage)
    Du coup, Perl est toujours en version 5.x.

    Il semble y avoir très peu de bouquins sur Raku, selon O'Reilly: https://www.oreilly.com/search/?q=raku&rows=100

    • [^] # Re: Perl 6 => Raku

      Posté par  . Évalué à 7 (+5/-0).

      Je pense que Perl6/Raku répondait à un réel besoin, mais est arrivé bien trop tard : d'autres langages on répondu à ce besoin. D'autre part la rupture majeure entre perl5 et Raku de mon point de vue était trop importante pour séduire la communauté Perl.

    • [^] # Re: Perl 6 => Raku

      Posté par  . Évalué à 6 (+4/-0).

      Et aussi, la prochaine version majeure de Perl devrait être la 7, qui sera plus ou moins équivalente à la dernière 5.x.

      Personnellement, je trouve Perl super pratique, expressif et amusant, c'est un langage que j'ai beaucoup utilisé, avec le C et le shell. Aujourd'hui, je l'évite, principalement parce que quand tu travailles avec des personnes plus proches de la sortie d'école que de la retraite, et bien Python fait souvent partie de leur boîte à outils :p.

    • [^] # Re: Perl 6 => Raku

      Posté par  (site web personnel, Mastodon) . Évalué à -1 (+1/-3).

      C'est la malédiction de la version 6 en informatique… Aussi étrange que cela soit, cela se vérifie assez souvent (pas toujours). Certains projets choisissent de sauter la version 6 pour cette raison…

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Perl 6 => Raku

      Posté par  . Évalué à 4 (+2/-0).

      Syntaxe auto-hébergée
      La syntaxe de Raku est elle-même définie en Raku.
      […]
      la possibilité pour le langage de modifier sa propre syntaxe en cours d'exécution, ce qui constitue une performance accomplie par de très rares langages de programmation, le plus emblématique étant Lisp.

      🤯🤯🤯
      ça doit pouvoir donner des trucs de ouf.

  • # elegant weapons from a more civilized age

    Posté par  . Évalué à 8 (+6/-0).

    Je n'ai jamais fais plus en Perl que de hacker des bases de code existantes. Je trouve Python beaucoup plus appétant.

    Mais quand je regarde le /bin de mon système, je trouve 150 programmes en Perl, 58 en Python. Il y a donc un réel usage dans une distrib Linux.

    Ma conclusion pifométrique : Perl fait un très bon super-shell.

    • [^] # Re: elegant weapons from a more civilized age

      Posté par  (site web personnel) . Évalué à 5 (+4/-0).

      Perl fait un très bon super-shell.

      Pareil.
      Dès que je galère un peu trop en bash, je passe en perl.
      Le code est réduit d'un facteur 5 à 10.

      Dans les deux cas, j'ai besoin de la doc sous la main.
      En bash pour écrire le moindre test (la pire syntaxe de tous les langages, à mon avis).
      En perl pour retrouver comment écrire en une ligne ce qui en prend 30 dans la plupart des autres langages.

      Beaucoup de choses sont scriptées en perl dans Linux. Il serait difficile de s'en passer.

    • [^] # Re: elegant weapons from a more civilized age

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+1/-0).

      Non, c'est surtout historique. Perl était là avant Python et les habitudes sont là. Surtout les vieux développeurs…
      Après il y a une autre raison plus technique. Perl est hyper stable et n'évolue que très lentement avec des nouveauté pas activées par défaut. Le passage de Python2 à Python3 qui a tout cassé en a refroidi plus d'un… surtout chez les vieux de la vieille… je crois que ça a même servi de leçon à l'équipe Python qui depuis fait tout pour rester retro-compatible.

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

  • # Que du classique

    Posté par  (site web personnel) . Évalué à 5 (+4/-0).

    Pour ma part, je m'en sert encore, principalement pour de l'extraction de données et générer des rapports automatiquement : rien de bien original.
    C'est un langage que j'aime bien car on peut programmer librement en allant du gros sale au truc bien conçu et bien pensé, selon les besoins ou le temps disponible pour le projet en cours. Quand on connait déjà le langage, on peut l'utiliser pour faire des choses correctes très rapidement, c'est son gros plus à mes yeux : produire du vite fait bien fait sans avoir à réinventer la roue.

    Perl 6 est très chouette également, mais assez différent, langage essayant de répondre simplement à plein de besoins qu'ont les programmeurs de nos jours. Y'a un Taptempo en Perl6 quelque part sur ce site…

  • # Qui utilise Perl et pour quoi faire ?

    Posté par  (site web personnel, Mastodon) . Évalué à 8 (+6/-0).

    Pour répondre à la question

    Qui utilise encore Perl et pourquoi faire ? Est-ce pour maintenir du code existant, ou y a-t-il encore de nouveau projets qui utilisent Perl ?

    Un très gros projet qui est développé en Perl : https://koha-community.org
    Le logiciel équipe plus d'une vingtaine de BUs en France, c'est le 2eme logiciel le plus important dans le domaine.
    Au niveau mondial, c'est le logiciel le plus répandu.
    Pourquoi Perl ? -question qu'on me pose régulièrement-
    La réponse est simple : la petite équipe de 3 devs qui a commencé le projet fin 1999 connaissait Perl et pas JAVA. PHP n'était pas dans les radars, c'était trop jeune [https://www.php.net/manual/fr/history.php.php]

    Pourquoi on ne change pas : heu… excellente blague, vu la taille du soft et son périmètre fonctionnel :d

  • # perl6 / raku

    Posté par  (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 07 octobre 2024 à 13:40.

    perl6 n'existe plus, c'est maintenant un langage à part entière et séparé nommé raku.

    J'ai tendance à personnellement préferer ruby à perl mais je maintiens encore des trucs en perl au boulot et si je me rencontre que je dois faire des trucs gruik en shell + awk, je me rends compte que c'est plus simple de partir sur perl directement.

    Je n'utilise python professionnellement qu'à contrecœur, tout comme typescript.

  • # Traitement de données, génération de rapports, et… one liners

    Posté par  . Évalué à 4 (+2/-0).

    Presque tout est dans le titre. :-)

    Pour les one-liners : je m'en sers pour envoyer des étudiants au tableau au hasard, en leur laissant une petite chance de pré-calculer le modulo pour qu'ils puissent cibler leurs camarades. :-)

    Je n'ai pas produit de scripts ou applications de grande envergure en Perl depuis un bail, et il est clairement en train de prendre le chemin de sed/awk : quand je commençais mes études il y a ~25 ans, (CGI/)Perl était super populaire (PHP commençait doucement à monter pour faire du web dynamique côté serveur), mais beaucoup d'admins UNIX ne juraient que par sed et awk quand (ba)sh ne suffisait plus. De nos jours, je pense que c'est devenu la place de Perl.

    Je continue d'utiliser Perl régulièrement, parce que je sais comment m'en servir (et donc être relativement efficace avec), et que lorsque j'oublie comment utiliser certaines fonctions, perldoc reste l'une des meilleures docs en ligne et locales qui soit.

  • # Vrai langage objet

    Posté par  . Évalué à 2 (+0/-0).

    Je ne fais plus vraiment de dev en dehors de scripts d'admin et d'outils à usage unique, mais une chose que j'aimais bien quand je faisais du dev en perl est qu'on pouvait passer directement d'une conception objet à une implémentation dans le code, sans passer par une étape de réingénérie pour s'adapter au langage. Dans les années 2000, c'était par exemple l'un des très rares langages à gérer l'héritage multiple (j'espère que ça s'est amélioré depuis).

    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

  • # Encore largement utilisé

    Posté par  . Évalué à 3 (+0/-0). Dernière modification le 09 octobre 2024 à 00:50.

    Perl 5 et Python 3 sont vraiment à l’opposé l’un de l’autre. Perl permet d’écrire le même algorithme de 36 manières différentes, de la plus concise (en recourant intensivement à l’implicite dans sa syntaxe), à la plus verbeuse. Son slogan, du moins l’un de ses slogan (?), est :

    There is more than one way to do it.

    En Python au contraire on ne cesse de recommander LA façon « pythonique » de faire telle ou telle chose. Le but premier du langage est d’être le plus simple possible à relire, par les autres, comme par soi-même, afin de réduire les temps de développement des projets, en gagnant du temps sur ces aspects de (re)lecture de code, qui sont loin d’être négligeables. En particulier sur des projets avec une équipe de contributrices nombreuse et fluctuante, comme c’est le cas pour énormément de logiciels libres.

    Perl 5 exige également le recours aux pointeurs, comme en C. Alors que Python non, bien qu’on puisse faire du passage d’argument par valeur ou référence aussi si besoin, mais c’est peu courant. En Perl c’est obligatoire.

    Au niveau des bibliothèques disponibles j’ai tendance à croire que c’est à peu près kif-kif entre Perl et Python. Les « bonnes » bibliothèque, les plus largement utilisées, sont disponibles bien souvent pour l’un et l’autre et au moins C, et quelques autres langages.

    Bash à côté c’est quasimodo avec des verrues à la sortie du lit avec la gueule de bois. La raison est assez compréhensible à mon avis : contrairement aux deux précédents, ce n’est pas, initialement, un langage de programmation. C’est un shell. Qui de plus « hérite » du vénérable sh, conçu à la préhistoire de l’informatique pour des ordinateur sans écran utilisant des bandes magnétiques comme stockage, avec 8kB de RAM.

    On peut utiliser les trois comme des langages de programmation ou comme des shell, bien sûr, mais ça explique quand même beaucoup des spécificités extraordinaires du shell pour la programmation.

    • [^] # Re: Encore largement utilisé

      Posté par  . Évalué à 3 (+1/-0).

      Une raison, je crois, de l'opposition d'approche entre Perl et Python, est que Python est largemnt inspiré de ABC, un langage conçu pour apprendre à programmer à des débutants (des enfants ?). Les choses doivent être simples et identifiables : syntaxe sans accolades, utilisation d'idiomes, par exemple. De son côté, Larry Wall est un genre de farfelu passionné par le langage, qui apprécie les truc décoiffés ("Perl is hairy"). D'ailleurs dans l'ouvrage de référence de O'Reilly Programmation en Perl, on trouve un chapitre sur l'écriture de poème en Perl.

    • [^] # Re: Encore largement utilisé

      Posté par  . Évalué à 2 (+0/-0).

      Je ne comprends pas bien ta remarque sur les pointeurs en Perl. Il y a des références, et avoir une idée de ce qu'est la notion de mémoire et d'adresse mémoire aide énormément, mais il y a peu de cas où tu as vraiment besoin de toucher à des pointeurs (au sens de « je change l'adresse pointée et pas le contenu pointé par la référence »). Est-ce que tu veux parler de cas de ce genre ? 

      use strict;
use warnings;

my $hash = { "a" => 3, "b" => 4 };
my $array = [ "a", 3, "b", 4 ];
# ...

      • [^] # Re: Encore largement utilisé

        Posté par  . Évalué à 3 (+0/-0).

        il y a peu de cas où tu as vraiment besoin de toucher à des pointeurs

        Je faisais référence au fait que tu ne peux pas, contrairement à en Python, avoir par exemple un « tableau de tableaux », tu ne peux avoir qu’un tableau de scalaires, ou un tableau de pointeurs. D’où les notations \$var, \@var et \%var. Qui désigne ce que j’entends, peut-être à tort, par respectivement : pointeur sur scalaire, pointeur sur tableau et pointeur sur hash.

        À ce sujet je trouve que le vocabulaire employé en Python pour désigner ces deux derniers types d’objet est de loin le plus parlant : liste et dictionnaire. Je me rappelle avoir eût beaucoup de mal à mes tous débuts avec le terme « tableau », qui évoque pour moi un tableau à double entrée. Le terme « liste » est bien plus signifiant je trouve.

        C’est en tous cas ce que j’en avais retenu quand je m’étais un peu penché sur le langage afin de pas mourir idiot. Mais je n’y connais vraiment pas grand-chose. Je n’ai écrit qu’un seul script utile en Perl, et c’était un script assez simple et c’était juste pour voir si je pouvais m’en sortir.

        Je comprends néanmoins qu’on puisse adorer ce langage ceci dit.

  • # principalement pour la maintenance.

    Posté par  . Évalué à 3 (+1/-0).

    salut,

    j'ai utilisé Perl pendant des années et il est évident que Perl est quasi-mort: c'est à dire principalement utilisé pour maintenir l'existant.
    Pour des nouveaux projets comme les nouveaux programmeurs connaissent beaucoup plus souvent Python que Perl..

    Avant pour les scripts qui devenaient trop complexe le réflexe était Perl, maintenant c'est Python.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.