Pour la première partie, je ne sais pas trop ; surtout qu'on fait du CGI avec divers langages…
Pour la seconde partie, oui il y a clairement une base énorme d'existant qui n'est pas prêt de disparaître …même si de plus en plus en voit de nouveaux langages essayer de prendre ce relais (Ruby, TCL, PHP, Python, etc.)
Par contre, bien dommage que l'article soit écrit par une personne de la vieille école (ses exemples n'obéissent pas aux nouveaux canons de PERL) pas très à jour (une bonne partie de son argumentation aurait pu s'écrire il y a dix ou quinze ans, et sur ces points tous les langages ont évolué.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
de nouveaux langages essayer de prendre ce relais (Ruby, TCL, PHP, Python, etc.)
Tu veux dire de vieux langages? Ruby, TCL ou même PHP sont des vieux langages encore plus poussiéreux et moins puissant que PERL. Python, est le seul qui aurait un intérêt je pense (plus moderne, plus connu et donc mieux maîtrisé par la jeune génération)…
Si on regarde les langages de programmation les plus populaire dans le top 3 on a (et dans cet ordre):
- Python
- Java
- Javascript
De ces 3 python est le plus vieux mais si on compare, java, javascript, ruby ont tous été créés en 1995, bien après Perl.
Et au final en 2022 qu'est-ce qui fait qu'un langage interprété est populaire chez les cool kids? Qu'il soit directement supporté par un navigateur. Raison pour laquelle javascript et typescript prennent le pouvoir.
De toute façon poussiéreux ça ne veut pas dire grand chose pour un langage. Python, perl, ruby, js évoluent toujours. TCL est peut-être moins dynamique mais la dernière version stable est de novembre 2021. C'est d'ailleurs pas forcément une mauvais chose, moins ça évolue moins on a des choses dépréciées.
Posté par flan (site web personnel) .
Évalué à 2.
Dernière modification le 24 juillet 2022 à 10:20.
Python n'est pas supporté directement par un navigateur, et pourtant il est populaire chez les cool kids.
Par contre, JavaScript étant le seul à être directement supporté par les navigateurs, ça lui donne évidemment un avantage par rapport aux autres. Le jour où webassembly sera vraiment utilisable et utilisé, cela changera peut-être.
Pour Python, il faudra certainement trouver un compromis pour la bibliothèque standard (elle est bien trop lourde pour être fournie sur chaque page, mais on peut difficilement ne pas en fournir au moins une partie).
poussiéreux ça ne veut pas dire grand chose pour un langage
C'est sure cela ne veut pas dire grand chose en sois. Ce que j'entends par là, c'est que Php, TCL ou Ruby n'ont pas des communautés grandissantes parce qu’ils n'apportent plus grand chose de nouveau et d'intéressants par rapport aux autres langages. A contrario, ils traînent quelques tares. Ils ne sont certes pas les seuls, mais je ne vois pas en quoi ils seraient plus "modernes" et intéressants que Perl.
Certes Ruby, a eu son côté cool et innovant dans sa simplicité et standardisation avec Ruby on rail, mais c'est bien le seul truc qui m'est parvenu de lui et rien d'insurmontables aux autres langages.
PHP est certes encore dynamique sur le Web mais c'est surtout grâce a tous ce qui existe déjà comme framework que par un réel intérêt pour le langage.
Pour TCL, c'est bien pire. Je l'ai connu pour TCL/TK et pour "Expect"… mais c'est vraiment pas un langage simple a mes yeux. Depuis que j'ai découvert que Python possède un équivalent à Expect (Pexpect), je n'y vois plus aucun intérêt.
PS : je suis développeur PHP et je connais TCL pour ce que j'ai dis.
Bref je ne vois pas en ces langages des remplaçant de PERL. Et si je n'utilise pas vraiment PERL (par méconnaissance), je le remplace par AWK (Qui est à l'abandon pour le coup), Python ou Julia… Je ne vois pas de remplaçant réel à PERL mais évidemment cela n'empêche pas à d'autres de grignoter sa place (je pense à Python) plus par méconnaissance de PERL.
Posté par mahikeulbody .
Évalué à 9.
Dernière modification le 14 juillet 2022 à 16:32.
C'est utilisé par l'outil le plus complet pour lire et écrire les méta-données des fichiers photos et vidéos (en ligne de commande ou via de nombreux logiciels qui l'utilisent) : exiftool. Rien que pour ça, PERL is still relevant en 2022.
C'est un peu dommage que cet article compare Perl avec différents langages sauf avec celui qui lui est le plus proche : Ruby.
Pour tous les cas d'usage où Perl est intéressant, Ruby est aussi bon et à mon humble avis meilleur avec une syntaxe plus claire et cohérente, un modèle objet inspiré de Smalltalk, …
Posté par abriotde .
Évalué à 1.
Dernière modification le 20 juillet 2022 à 13:16.
Je ne suis pas contre Ruby en sois je dis juste que Ruby n'est pas vraiment plus moderne que PERL.
En fait, dis autrement je doute que Perl soit désuet.
Perl est ancien mais évolue. Ruby est à peine plus récent et évolue guère plus…
J'imagine ne pas être le seul à l'utiliser encore fréquemment pour faire en une ligne des recherches/remplacements de motifs dans des fichiers, plutôt que d'utiliser gawk,sed,etc. J'ai toujours trouvé ça assez rapide et efficace, même si pour des choses nécessitant d'ouvrir un éditeur et d'écrire rapidement un bout de code je le fais plus naturellement en python désormais.
Aussi, un jeune ingénieur d'une filiale d'EADS me disait qu'il avait dû se former à Perl car c'était au coeur du framework créé pour tester les produits de la boîte.
Sans troll quelconque malgré le jour, la question se pose vraiment à l'heure actuelle. Le postulat de "je peux faire comme je veux" est le contraire de l'industrialisation.
Perso j'ai tendance à aimer ce genre de postulat, qui ne te bloque pas dès que tu veux sortir un peu des chemin battus. Mais il faut bien avouer que c'est plutôt de l'artisanat ou alors seulement des cas bien particuliers.
Mais dans une industrie (traduire: avec gros travail d'équipe), "un tel va faire comme il veux, peu importe pour les autres", ça marche pas longtemps.
Après bien sûr qu'il y a le poids de l'histoire, le langage ne disparaitra jamais. Mais de là à attirer de nouveaux projets en masse, je ne pense pas.
C'est loin d'être le seul langage comme ça. C++, lisp, scala, groovy,… sont peut être encore plus souples.
Ce qui fait mal à perl, c'est la popularité de python. Elle fait presque aussi mal à ruby. Les 3 langages de scripts qui se valaient il y a 20 ans, aujourd'hui python les a largement dépassé en terme de popularité. C'est une sorte d'effet boule de neige.
Posté par freem .
Évalué à 10.
Dernière modification le 15 juillet 2022 à 09:36.
Justement.
Il y a une plus grosse base de code perl dans le coeur de mon système (debian) que, par exemple, python. Quelqu'un a mentionné ruby, plus haut: idem.
A tel point que l'interpréteur perl est required (sur debian) mais j'ai eu de nombreux systèmes parfaitement fonctionnels sans python ni ruby ou autres.
Du coup, ça ne serait pas, justement, les gens qui utilisent ces langages qui n'en font qu'à leur tête?
Ton argument est, justement, en faveur des langages qui sont arrivés les premiers…
python3-minimal: 5 dépendances (je "déplie" libpython hein), ~10megs installé, à noter que je n'ai pas encore vu de paquet python utiliser le minimal, hein, a chaque fois en pratique il y a une chiée de trucs qui arrivent avec…
Ce que je veux dire, c'est que rien qu'en théorie, perl gagne sur le nombre de paquets et l'espace disque occupés. En théorie, python est comparable, mais en pratique je n'ai pas souvenir d'avoir vu une seule application python ne pas dépendre des paquets plus complets. Je sais que de nos jours, quelques megs de stockage ne font pas une grande différence dans l'immense majorité des cas, mais le fait d'avoir moins de paquets installés, ça permets de pouvoir plus facilement lire les changelogs de tous les paquets lors des mises à jour. Et ça, je pense que c'est important, d'un point de vue sécurité.
Toujours sur une Debian, ou perl est requis, se concentrer sur perl ou dash pour automatiser ça implique qu'il n'y a pas besoin d'installer d'autres interpréteurs, ce qui réduit la surface d'attaque.
Et vu que tu parles d'automatisation, avant qu'on ne me demande "comment on gère le parc", je dirais que pour éviter un nouvel interpréteur, toujours sur une debian, je vois:
drist, en shell posix
rexify, en perl
cfengine3, en C
Seul cfengine3 dispose d'un système d'agents, par contre (pour un outil codé dans l'un de ces langages. Je peux me tromper) ce qui implique que les systèmes peuvent se mettre au propre d'eux mêmes, quand ils ont le temps et l'accès au réseau (l'air de rien, l'accès constant au réseau etre loin d'être aussi garanti qu'on ne le pense, il suffit de voir les équipements de rue qui peuvent être placés dans des endroits ou ça ne capte pas, par exemple. Je ne parle pas juste de mémé dans son coin perdu ou c'est a peine si le téléphone cuivre passe).
A ma connaissance, il existe de nombreux autres outils de gestion de conf, qui eux, sont en ruby ou python principalement, donc c'est vrai qu'il y a de très, très grandes chances que de toute façon python ou ruby soient installés.
Mon propos n'est pas de nier une réalité (dans la plupart des cas, il y aura un truc plus connu de nos jours que perl d'installé) mais bien de rappeler qu'il est très possible que perl5 soit justement la façon de faire au sein d'une industrie, puisqu'il est la depuis très longtemps (je n'ai pas souvenir d'avoir utilisé debian basée sur perl4, ni même embarquer les deux… pour python, no comment) et a une belle assise dans nos systèmes actuels. A moins de considérer debian comme négligeable :) (plutôt utilisé par des petites boîtes il paraît).
A noter que je ne code ni en python, ni en ruby, ni en perl, donc je ne sais pas ce que ces langages valent en terme de perf.
Vrai, mais là tu te places sur le terrain du purement technique ou de l'ultra embarqué (où chaque Mo compte).
Si tu prends dans un plan plus global/standard, quelques Mo ça ne compte juste pas dans l'équation. Ni d'ailleurs en quoi sont fait les outils (je me fiche bien de savoir que tel outil est codé en perl tant que la distribution gère les dépendances comme il faut).
Si tes points sont tout à fait valides sur les chiffres, mais quand je démarre un projet ce ne sont pas des questions que je me pose. Les Mo et l'empaquetage, on y arrive, c'est jamais un vrai soucis (ça prends juste du temps qu'il faut compter, point), sauf grosses exceptions (ultra embarqué).
Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
Là on en arrive à la philosophie du langage et à son image dans l'industrie (le premier influe le second dans le temps).
Déjà que faire travailler du monde ensemble en Python c'est pas facile, mais en perl c'est une autre paire de manches (la philosophie du langage l'implique directement). Et trouver du monde employable pour Perl est … heu… disons ultra complexe. C'est déjà un peu plus jouable en Python même si c'est tendu.
C'est pas pour dire que tes points sont faux, pas du tout, ils sont tout à fait juste techniquement, juste que d'un point de vue d'un chef de projet, ils ne comptent pas cher dans son équation.
Or c'est bien eux qui sont au manettes désormais, plus les petits artisans qui souhaitent que tout soit cohérent. Eux veulent juste que ça soit "gérable", peux importe la cohérence technique sous-jacente. Chacun ses contraintes, mais eux ont le financement :p
Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.
Chacun ses contraintes, mais eux ont le financement :p
Et au pire quand ça pète ils sont plus dans la même boîte :D
Blague a part, je ne voulais pas dire que perl est mieux que les autres. Ce que je voulais dire, c'est que ton point n'était pas autant en défaveur de perl qu'il n'en donne l'impression, parce que justement il y a une grosse de base de code qui existe, et que ce n'est pas parce que les utilisateurs de perl sont discrets qu'ils n'existent pas.
Pour prendre un cas bien, bien extrême (on est vendredi après tout): "cobol is still relevant in 2022". Ca recrute encore sur cette tech, et il faut bien maintenir, le temps de finir les migrations, si elles ont été commencées, ce qui est loin d'être garantit partout.
Qu'un langage devienne un langage de niche n'est pas choquant, surtout que bon, perl, ça a toujours été un langage de niche pour moi: conçu pour remplacer /bin/sh, awk, grep, sed… mais les gens utiliserons toujours ces outils la en premier, par simple flemme et puis c'est ce qui est utilisé dans le terminal. Puis c'est simple. Chiant a maintenir quand ça se développe, un peu comme un fichier excel, et perl serait un peu le ms access du coup. Possiblement moins chiant, mais pas le truc qu'on fait naturellement.
Et je n'utiliserais pas perl sur de l'embarqué ou la contrainte de stockage est hyper forte. J'ai souri quand j'ai vu l'article considérer qu'une raspberry pi c'est serré… Je veux dire, il y a combien de stockage sur un rPI? Sur les BBB, de mémoire il y a un lecteur de carte + 8 gig de stockage. Tellement de place que c'est dur à remplir, si on fait juste un peu attention.
microperl A small standalone perl interpreter that can be built from the perl sources via "make -f Makefile.micro". If you really feel the need for perl on an embedded system, this is where to start.
Suivi juste après d'une phrase qui semble plutôt encourager à utiliser lua pour du code neuf. Et en terme d'embarqué ultra contraint, j'aurai tendance a me fier aux auteurs de busybox.
D'ailleurs, vu qu'il existe des compilateurs python, je dirais même que ça serait la solution la plus simple: une fois compilé, j'ose espérer que les programmes sont plus compacts que tout l'environnement (et plus rapide, mais ça, tant qu'on n'a pas mesuré, on peut pas savoir si c'est pertinent, et impossible d'avoir une estimation simple et générique, contrairement au stockage).
Ma question est plutôt sur le nombre de paquets a installer, et maintenir. Le contexte de cyber sécurité est loin d'être détendu, il me semble, donc même si je sais que la sécurité on s'en fout un peu, il me semble que faciliter la maintenance et réduire la surface d'attaque, c'est pas une mauvaise chose.
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.
Pour la compilation de Python, il me semble que la plupart du temps c'est surtout un interpréteur embarqué qui se lance facilement (donc grosse boite noire), mais donc avec tout son volume. Après il y en a peux être qui "compilent" vraiment, mais pour du Python générique (non modifié pour) j'en vois pas.
Tout à fait d'accord que de toute manière ces langages ont atteint un tel poids dans l'historique, qu'ils ne vont pas disparaitre comme ça. Mais dès qu'il y aura une contraite (légale, sécurité, "plus de dev/trop cher") là ils seront remplacé par le standard de l'industrie à ce moment là (qui deviendra lui même obsolète, cycle éternel et merveilleux :D )
L'argument de la sécurité est valable en tout cas. Quand on voit l'enfer d'audit des dépendances en cascades, moins de langages ne serait pas un mal. Après mêmes les langages compilés sont touchés, juste que les dépendances sont bundlelisées et pas ultra-visibles comme sur python/node/XXX.
Mais là encore: est-ce que notre très cher (double sens) chef de projet a plus d'intérêt (€) à faire un projet rapide qu'un projet blindé/audité/maitrisé? Pour l'instant je n'ai pas l'impression qu'on va dans ce sens pour une majorité (je mets de côté les industries où c'est le légal qui l'impose, genre aérospatial, etc).
Or même avec les derniers soucis majeur en terme de sécurité sur la chaine, j'ai pas l'impression que les habitudes aient tellement changées. Jusqu'à la prochaine faille exploitable à distance dans un module standard? :p
Non, non, il y a vraiment des compilo pour du Python et du Perl aussi. Mais la plupart du temps en effet, c'est un interpréteur (du byte code)
Pour l'enfer d'audit des dépendance, ce n'est pas forcément la réduction du nombre de langages qui peut solutionner cela je pense. Avec n'importe quel langage, on peut faire beaucoup de dépendances ou en avoir un nombre réduit, et c'est la maîtrise de ce nombre réduit qui doit être recherché et qui n'est pas toujours fait.
Le problème du chefs de projets actuels est que ce sont comme des commerciaux qui promettent toujours d'aller plus vite que la musique et espèrent être très loin quand ça pète. Du coup, n'ayant pas à répondre par la suite de leur méfaits, ils ne peuvent pas rechercher la qualité intrinsèquement. (ma méchante humeur du vendredi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par barmic 🦦 .
Évalué à 4.
Dernière modification le 15 juillet 2022 à 11:00.
Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.
Ah noter que dans un avenir proche tous les bacheliers ou tous les bacheliers scientifiques auront eu une formation initiale en python.
En tout cas ça va fortement jouer en sa faveur pour les nouveaux projets. On est toujours un peu attaché à son premier langage (ah mon cher C, ce qu'on a pu se détester mutuellement, moi avec des insultes sur gdb, toi avec des segfaults).
Ce n'est pas un mauvais choix en tout cas, Python a quand même été pensé au tout début pour des débutants. On peux encore faire des choses simplement avec.
La tendance est à fournir des gens qui savent écrire dans un langage de programmation et non des gens qui savent faire des algorithmes et les traduire dans n'importe quel autre langage. Mais je m'éloigne du sujet avec ces allégations.
On est toujours un peu attaché à son premier langage
Ça n'a pas fait pour autant perdurer BASIC (en dehors de µ$) ou Pascal malgré Delphi (qui est son pendant VB non ?)
Mais je comprends ce que tu veux dire quand j'ai vu qu'une génération de gens formés à Java ont eu du mal à appliquer les concepts POO avec d'autres langages.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.
Moins de libs, c'est effectivement mieux du point de vue de la securite. Mais ca n'est pas la seule variable a prendre en compte.
Des audits du code, une communauté importante et impliquée, un système de mise a jour des dépendances bien huile, tout ça compte. Et la dessus Python a nettement l'avantage sur Perl.
Personnellement, ca me rassure pas tant que ca que l'install systeme de perl fasse 7 MB au lieu de 10 MB pour python. Je ne suis meme jamais pose la question, et je ne vois pas vraiment quel lien je pourrais faire avec la securite. Par contre la facilite de pouvoir relire moi même les scripts dans un langage pas obscure et sans siouxeries de syntaxe toutes les 3 lignes, ca je trouve ca plus important.
Des audits du code, une communauté importante et impliquée, un système de mise a jour des dépendances bien huile, tout ça compte. Et la dessus Python a nettement l'avantage sur Perl.
Euh… Que reproches-tu aux modules Perl et qui serait mieux fait de l'autre côté ? Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.
Par contre la facilite de pouvoir relire moi même les scripts dans un langage pas obscure et sans siouxeries de syntaxe toutes les 3 lignes, ca je trouve ca plus important.
Exactement le souci que j'ai avec nombre de scripts Python dont j'hérite et qui sont imbitables à souhait pour une bonne moitié. J'ai souvent plus vite fait de réécrire et ça n'empêche que je tombe une fois sur cinq sur des trucs un peu tordus.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par GuieA_7 (site web personnel) .
Évalué à 2.
Dernière modification le 16 juillet 2022 à 15:23.
Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.
Les gens du CPAN ont vraiment une solution à ce problème, ou bien le problème existe quand même mais on en n'entend juste pas (ou moins) parler ?
Bonne question :-) Je ne me suis jamais personnellement penché dessus, mais j'ai remarqué que dans la plupart des distributions Linux (quand j'ai regardé), c'est organisé comme les bibliothèques partagées : plusieurs versions peuvent cohabiter. Mais, je pense que la réponse est ailleurs : PERL est l'un des rares langages de scripting à tenter de garder un maximum de compatibilité ascendante. Du coup, les distributions fournissent juste la dernière distribution stable en sachant que tous les anciens codes vont continuer à tourner.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
C'est étrange, je n'ai pas du tout la même expérience.
Déjà que faire travailler du monde ensemble en Python c'est pas facile, mais en perl c'est une autre paire de manches (la philosophie du langage l'implique directement). Et trouver du monde employable pour Perl est … heu… disons ultra complexe. C'est déjà un peu plus jouable en Python même si c'est tendu.
Pour ce que j'en ai vu, c'est exactement la même chose : la philosophie du langage ne dit pas qu'un projet ne doit pas avoir de règles et je n'ai jamais vu de devs Perl ne pas se faire aux règles du projet. Par ailleurs, ces gens (qui son décrits comme des aliens) ne sont pas si rares que tu dis, en tout cas ce n'est pas le constat que je fais.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Alors pour l'occupation mémoire de Python, il existe Micropython, d'après https://lwn.net/Articles/725508/ il peut fonctionner avec 256K de code et 16K de RAM (et c'est en baremetal sans avoir besoin d'un OS en-dessous).
Il ne me semble pas avoir vu Perl faire aussi bien.
D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages: MicroPython pour l'embarqué avec quelques Ko de RAM, cython quand on a besoin de compiler le code pour qu'il tourne plus vite, etc. On est en fait bien au-delà d'un simple langage de script.
Il va donc peut être remplacer C++ quand il en aura fini avec Perl?
Un autre commentaire a invoqué l'implémentation de busybox… On peut ajouter, par exemple, Jerl et PLJava et perljvm comme implémentations Java. Et Parrot est pensé pour se voir interfacer n'importe quel langage (y compris Python, cf. PEP401) tandis que Raku-do permet à Perl/Raku d'implémenter n'importe quel autre langage.
Maintenant, pendant que certaines personnes s'échinent inutilement à remplacer l'un par l'autre, les principaux acteurs préfèrent faire des ponts : Inline::Python et PyPerl
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
À ma connaissance Parrot est mort (je n'ai jamais trouvé de gros intérêt au projet, mais j'étais quand même curieux de voir ce qu'ils arriveraient à faire).
D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages
Oui et non. Ces implémentations n'implémentent que le langage et pas l'API C, ils ont généralement une tambouille pour numpy, mais hors de ça tu n'a pas accès aux bibliothèques qui utilisent du C. On est pas sur un drop in remplacement tel qu'on pourrait s'y attendre. Ensuite micropython implémente pas tout python (toute la bibliothèque standard n'est pas là) et la dernière version est en python 3.4 (avec des bouts de 3.5) version qui a 8 ans et qui est considérée en fin de vie. Pypy supporte jusqu'à 3.7 (version encore supportée upstream) et a une couche de compatibilité pour les bibliothèques qui utilisent du c c'est cool.
Et on pourrait faire la liste comme ça pour chacun. Bref mon point c'est qu'il s'agit pas d'implémentations où tu change la stack et c'est parti. Tu code généralement en sachant quelle implementation tu va utiliser c'est très différent comme approche.
Après quant à perl vs python, il faut comprendre qu'une grande partie du succès ou non ne vient pas d'une valeur intrinsèque. Perl, ruby, python sont 3 très bons languages sinon on en parlerai plus 25 ans après leur apparition. Il se fait qu'actuellement c'est python qui semble de loin le plus populaire, mais ça n'est pas une raison pour tuer les autres.
Pour moi déjà quand tu en arrives à devoir écrire un article pour justifier une technologie, c'est que la dite techno est mourante.
Bien évidemment tout est subjectif mais pour moi Perl est le langage dont la syntaxe est la plus horrible avec des mots clés de une à deux lettres q, qq, qx, qw, etc.
git is great because linus did it, mercurial is better because he didn't
Pour moi déjà quand tu en arrives à devoir écrire un article pour justifier une technologie, c'est que la dite techno est mourante.
Ouch… Ça ne va pas plaire aux gens qui l'ont fait pour… Python, Rust, etc. :-)
Mais bien d'accord que c'est trop succinct (et donc parait cryptique —et non horrible) d'avoir une flopée de mot-clés d'une à deux lettres …même si ça ne bat pas : APL, J, BrainFuck, SKI, …
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Contrairement à une idée très répandue le brainfuck est pas très compliqué. Par contre le moins connu malbolge est de très loin le langage le plus complexe que j'ai pu voir.
Je ne connaissais pas Malbolge. Je trouve bien l'usage de 3 états au lieu de 2, par contre le chiffrement complexifie alors que le fonctionnement du registre c n'est déjà pas évident…
Brainfuck est juste un assembleur d'une machine de Turing, avec des mots clés d'un seul caractère… (d'où le fait que je l'ai mentionné.) Mais comparativement j'ai trouvé Whitespace plus hermétique …bien que je doive admettre aujourd'hui que c'est rien à côté de Malbolge.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Version courte
Posté par Pol' uX (site web personnel) . Évalué à 5.
« It is still being used in CGI scripts. It is used in several sys admin tasks. »
Adhérer à l'April, ça vous tente ?
[^] # Re: Version courte
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Pour la première partie, je ne sais pas trop ; surtout qu'on fait du CGI avec divers langages…
Pour la seconde partie, oui il y a clairement une base énorme d'existant qui n'est pas prêt de disparaître …même si de plus en plus en voit de nouveaux langages essayer de prendre ce relais (Ruby, TCL, PHP, Python, etc.)
Par contre, bien dommage que l'article soit écrit par une personne de la vieille école (ses exemples n'obéissent pas aux nouveaux canons de PERL) pas très à jour (une bonne partie de son argumentation aurait pu s'écrire il y a dix ou quinze ans, et sur ces points tous les langages ont évolué.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Version courte
Posté par abriotde . Évalué à -2.
Tu veux dire de vieux langages? Ruby, TCL ou même PHP sont des vieux langages encore plus poussiéreux et moins puissant que PERL. Python, est le seul qui aurait un intérêt je pense (plus moderne, plus connu et donc mieux maîtrisé par la jeune génération)…
[^] # Re: Version courte
Posté par barmic 🦦 . Évalué à 2.
Ça se mesure en Watt ? Du coup c'est combien de différence ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Version courte
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Février 1991, soit 31 ans ; c'est sûr que ce n'est pas vieux et très moderne.
Février 1988, juste 3 ans de plus ; c'est sûr que ça fait archi vieux n'est-ce pas ?
Juin 1995, soit 27 ans, c'est encore plus vieux que 31… dans la distorsion de vue.
Quand on veut noyer son animal…
Mis à part les sentiments tirés du chapeau, peux-tu développer factuellement ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Version courte
Posté par Psychofox (Mastodon) . Évalué à 4.
Oublies, c'est un troll.
Si on regarde les langages de programmation les plus populaire dans le top 3 on a (et dans cet ordre):
- Python
- Java
- Javascript
De ces 3 python est le plus vieux mais si on compare, java, javascript, ruby ont tous été créés en 1995, bien après Perl.
Et au final en 2022 qu'est-ce qui fait qu'un langage interprété est populaire chez les cool kids? Qu'il soit directement supporté par un navigateur. Raison pour laquelle javascript et typescript prennent le pouvoir.
De toute façon poussiéreux ça ne veut pas dire grand chose pour un langage. Python, perl, ruby, js évoluent toujours. TCL est peut-être moins dynamique mais la dernière version stable est de novembre 2021. C'est d'ailleurs pas forcément une mauvais chose, moins ça évolue moins on a des choses dépréciées.
[^] # Re: Version courte
Posté par flan (site web personnel) . Évalué à 2. Dernière modification le 24 juillet 2022 à 10:20.
Python n'est pas supporté directement par un navigateur, et pourtant il est populaire chez les cool kids.
Par contre, JavaScript étant le seul à être directement supporté par les navigateurs, ça lui donne évidemment un avantage par rapport aux autres. Le jour où webassembly sera vraiment utilisable et utilisé, cela changera peut-être.
Pour Python, il faudra certainement trouver un compromis pour la bibliothèque standard (elle est bien trop lourde pour être fournie sur chaque page, mais on peut difficilement ne pas en fournir au moins une partie).
[^] # Re: Version courte
Posté par abriotde . Évalué à 1.
C'est sure cela ne veut pas dire grand chose en sois. Ce que j'entends par là, c'est que Php, TCL ou Ruby n'ont pas des communautés grandissantes parce qu’ils n'apportent plus grand chose de nouveau et d'intéressants par rapport aux autres langages. A contrario, ils traînent quelques tares. Ils ne sont certes pas les seuls, mais je ne vois pas en quoi ils seraient plus "modernes" et intéressants que Perl.
Certes Ruby, a eu son côté cool et innovant dans sa simplicité et standardisation avec Ruby on rail, mais c'est bien le seul truc qui m'est parvenu de lui et rien d'insurmontables aux autres langages.
PHP est certes encore dynamique sur le Web mais c'est surtout grâce a tous ce qui existe déjà comme framework que par un réel intérêt pour le langage.
Pour TCL, c'est bien pire. Je l'ai connu pour TCL/TK et pour "Expect"… mais c'est vraiment pas un langage simple a mes yeux. Depuis que j'ai découvert que Python possède un équivalent à Expect (Pexpect), je n'y vois plus aucun intérêt.
PS : je suis développeur PHP et je connais TCL pour ce que j'ai dis.
Bref je ne vois pas en ces langages des remplaçant de PERL. Et si je n'utilise pas vraiment PERL (par méconnaissance), je le remplace par AWK (Qui est à l'abandon pour le coup), Python ou Julia… Je ne vois pas de remplaçant réel à PERL mais évidemment cela n'empêche pas à d'autres de grignoter sa place (je pense à Python) plus par méconnaissance de PERL.
# exiftool
Posté par mahikeulbody . Évalué à 9. Dernière modification le 14 juillet 2022 à 16:32.
C'est utilisé par l'outil le plus complet pour lire et écrire les méta-données des fichiers photos et vidéos (en ligne de commande ou via de nombreux logiciels qui l'utilisent) : exiftool. Rien que pour ça, PERL is still relevant en 2022.
# Ruby
Posté par Gawan . Évalué à 4.
C'est un peu dommage que cet article compare Perl avec différents langages sauf avec celui qui lui est le plus proche : Ruby.
Pour tous les cas d'usage où Perl est intéressant, Ruby est aussi bon et à mon humble avis meilleur avec une syntaxe plus claire et cohérente, un modèle objet inspiré de Smalltalk, …
[^] # Re: Ruby
Posté par abriotde . Évalué à 0.
Mais Ruby est tout aussi désuet que PERL. Sauf que Ruby n'a jamais été aussi populaire que PERL…
[^] # Re: Ruby
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C'est bon, on a compris que tu es juste anti.
Au cas où tu ne le saurais pas, tu crois que ce n'est plus en usage et pourtant : on continue de le lister (parmi sept autres à considérer) en 2022 ; ailleurs c'est en dixième position juste avant C++ pour 2022 ; même github montre une activité importante pour un mort. Bref, on te laisse à tes croyances.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ruby
Posté par abriotde . Évalué à 1. Dernière modification le 20 juillet 2022 à 13:16.
Je ne suis pas contre Ruby en sois je dis juste que Ruby n'est pas vraiment plus moderne que PERL.
En fait, dis autrement je doute que Perl soit désuet.
Perl est ancien mais évolue. Ruby est à peine plus récent et évolue guère plus…
# one liners, supershell
Posté par bistouille . Évalué à 3.
J'imagine ne pas être le seul à l'utiliser encore fréquemment pour faire en une ligne des recherches/remplacements de motifs dans des fichiers, plutôt que d'utiliser gawk,sed,etc. J'ai toujours trouvé ça assez rapide et efficace, même si pour des choses nécessitant d'ouvrir un éditeur et d'écrire rapidement un bout de code je le fais plus naturellement en python désormais.
Aussi, un jeune ingénieur d'une filiale d'EADS me disait qu'il avait dû se former à Perl car c'était au coeur du framework créé pour tester les produits de la boîte.
# Relevant ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Ça veut dire qu'il fait souvent se relever la nuit pour corriger des bugs ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Vraie question
Posté par Jean Gabes (site web personnel) . Évalué à 5. Dernière modification le 15 juillet 2022 à 07:57.
Sans troll quelconque malgré le jour, la question se pose vraiment à l'heure actuelle. Le postulat de "je peux faire comme je veux" est le contraire de l'industrialisation.
Perso j'ai tendance à aimer ce genre de postulat, qui ne te bloque pas dès que tu veux sortir un peu des chemin battus. Mais il faut bien avouer que c'est plutôt de l'artisanat ou alors seulement des cas bien particuliers.
Mais dans une industrie (traduire: avec gros travail d'équipe), "un tel va faire comme il veux, peu importe pour les autres", ça marche pas longtemps.
Après bien sûr qu'il y a le poids de l'histoire, le langage ne disparaitra jamais. Mais de là à attirer de nouveaux projets en masse, je ne pense pas.
[^] # Re: Vraie question
Posté par barmic 🦦 . Évalué à 10.
C'est loin d'être le seul langage comme ça. C++, lisp, scala, groovy,… sont peut être encore plus souples.
Ce qui fait mal à perl, c'est la popularité de python. Elle fait presque aussi mal à ruby. Les 3 langages de scripts qui se valaient il y a 20 ans, aujourd'hui python les a largement dépassé en terme de popularité. C'est une sorte d'effet boule de neige.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Vraie question
Posté par freem . Évalué à 10. Dernière modification le 15 juillet 2022 à 09:36.
Justement.
Il y a une plus grosse base de code perl dans le coeur de mon système (debian) que, par exemple, python. Quelqu'un a mentionné ruby, plus haut: idem.
A tel point que l'interpréteur perl est required (sur debian) mais j'ai eu de nombreux systèmes parfaitement fonctionnels sans python ni ruby ou autres.
Du coup, ça ne serait pas, justement, les gens qui utilisent ces langages qui n'en font qu'à leur tête?
Ton argument est, justement, en faveur des langages qui sont arrivés les premiers…
Ah oui. Et aussi…
Ce que je veux dire, c'est que rien qu'en théorie, perl gagne sur le nombre de paquets et l'espace disque occupés. En théorie, python est comparable, mais en pratique je n'ai pas souvenir d'avoir vu une seule application python ne pas dépendre des paquets plus complets. Je sais que de nos jours, quelques megs de stockage ne font pas une grande différence dans l'immense majorité des cas, mais le fait d'avoir moins de paquets installés, ça permets de pouvoir plus facilement lire les changelogs de tous les paquets lors des mises à jour. Et ça, je pense que c'est important, d'un point de vue sécurité.
Toujours sur une Debian, ou perl est requis, se concentrer sur perl ou dash pour automatiser ça implique qu'il n'y a pas besoin d'installer d'autres interpréteurs, ce qui réduit la surface d'attaque.
Et vu que tu parles d'automatisation, avant qu'on ne me demande "comment on gère le parc", je dirais que pour éviter un nouvel interpréteur, toujours sur une debian, je vois:
Seul cfengine3 dispose d'un système d'agents, par contre (pour un outil codé dans l'un de ces langages. Je peux me tromper) ce qui implique que les systèmes peuvent se mettre au propre d'eux mêmes, quand ils ont le temps et l'accès au réseau (l'air de rien, l'accès constant au réseau etre loin d'être aussi garanti qu'on ne le pense, il suffit de voir les équipements de rue qui peuvent être placés dans des endroits ou ça ne capte pas, par exemple. Je ne parle pas juste de mémé dans son coin perdu ou c'est a peine si le téléphone cuivre passe).
A ma connaissance, il existe de nombreux autres outils de gestion de conf, qui eux, sont en ruby ou python principalement, donc c'est vrai qu'il y a de très, très grandes chances que de toute façon python ou ruby soient installés.
Mon propos n'est pas de nier une réalité (dans la plupart des cas, il y aura un truc plus connu de nos jours que perl d'installé) mais bien de rappeler qu'il est très possible que perl5 soit justement la façon de faire au sein d'une industrie, puisqu'il est la depuis très longtemps (je n'ai pas souvenir d'avoir utilisé debian basée sur perl4, ni même embarquer les deux… pour python, no comment) et a une belle assise dans nos systèmes actuels. A moins de considérer debian comme négligeable :) (plutôt utilisé par des petites boîtes il paraît).
A noter que je ne code ni en python, ni en ruby, ni en perl, donc je ne sais pas ce que ces langages valent en terme de perf.
[^] # Re: Vraie question
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Vrai, mais là tu te places sur le terrain du purement technique ou de l'ultra embarqué (où chaque Mo compte).
Si tu prends dans un plan plus global/standard, quelques Mo ça ne compte juste pas dans l'équation. Ni d'ailleurs en quoi sont fait les outils (je me fiche bien de savoir que tel outil est codé en perl tant que la distribution gère les dépendances comme il faut).
Si tes points sont tout à fait valides sur les chiffres, mais quand je démarre un projet ce ne sont pas des questions que je me pose. Les Mo et l'empaquetage, on y arrive, c'est jamais un vrai soucis (ça prends juste du temps qu'il faut compter, point), sauf grosses exceptions (ultra embarqué).
Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
Là on en arrive à la philosophie du langage et à son image dans l'industrie (le premier influe le second dans le temps).
Déjà que faire travailler du monde ensemble en Python c'est pas facile, mais en perl c'est une autre paire de manches (la philosophie du langage l'implique directement). Et trouver du monde employable pour Perl est … heu… disons ultra complexe. C'est déjà un peu plus jouable en Python même si c'est tendu.
C'est pas pour dire que tes points sont faux, pas du tout, ils sont tout à fait juste techniquement, juste que d'un point de vue d'un chef de projet, ils ne comptent pas cher dans son équation.
Or c'est bien eux qui sont au manettes désormais, plus les petits artisans qui souhaitent que tout soit cohérent. Eux veulent juste que ça soit "gérable", peux importe la cohérence technique sous-jacente. Chacun ses contraintes, mais eux ont le financement :p
[^] # Re: Vraie question
Posté par freem . Évalué à 4.
Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.
Et au pire quand ça pète ils sont plus dans la même boîte :D
Blague a part, je ne voulais pas dire que perl est mieux que les autres. Ce que je voulais dire, c'est que ton point n'était pas autant en défaveur de perl qu'il n'en donne l'impression, parce que justement il y a une grosse de base de code qui existe, et que ce n'est pas parce que les utilisateurs de perl sont discrets qu'ils n'existent pas.
Pour prendre un cas bien, bien extrême (on est vendredi après tout): "cobol is still relevant in 2022". Ca recrute encore sur cette tech, et il faut bien maintenir, le temps de finir les migrations, si elles ont été commencées, ce qui est loin d'être garantit partout.
Qu'un langage devienne un langage de niche n'est pas choquant, surtout que bon, perl, ça a toujours été un langage de niche pour moi: conçu pour remplacer /bin/sh, awk, grep, sed… mais les gens utiliserons toujours ces outils la en premier, par simple flemme et puis c'est ce qui est utilisé dans le terminal. Puis c'est simple. Chiant a maintenir quand ça se développe, un peu comme un fichier excel, et perl serait un peu le ms access du coup. Possiblement moins chiant, mais pas le truc qu'on fait naturellement.
Et je n'utiliserais pas perl sur de l'embarqué ou la contrainte de stockage est hyper forte. J'ai souri quand j'ai vu l'article considérer qu'une raspberry pi c'est serré… Je veux dire, il y a combien de stockage sur un rPI? Sur les BBB, de mémoire il y a un lecteur de carte + 8 gig de stockage. Tellement de place que c'est dur à remplir, si on fait juste un peu attention.
Sur le site de busybox on peut lire:
Suivi juste après d'une phrase qui semble plutôt encourager à utiliser lua pour du code neuf. Et en terme d'embarqué ultra contraint, j'aurai tendance a me fier aux auteurs de busybox.
D'ailleurs, vu qu'il existe des compilateurs python, je dirais même que ça serait la solution la plus simple: une fois compilé, j'ose espérer que les programmes sont plus compacts que tout l'environnement (et plus rapide, mais ça, tant qu'on n'a pas mesuré, on peut pas savoir si c'est pertinent, et impossible d'avoir une estimation simple et générique, contrairement au stockage).
Ma question est plutôt sur le nombre de paquets a installer, et maintenir. Le contexte de cyber sécurité est loin d'être détendu, il me semble, donc même si je sais que la sécurité on s'en fout un peu, il me semble que faciliter la maintenance et réduire la surface d'attaque, c'est pas une mauvaise chose.
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.
[^] # Re: Vraie question
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Je vois qu'on a eu les mêmes chefs de projets :p
Pour la compilation de Python, il me semble que la plupart du temps c'est surtout un interpréteur embarqué qui se lance facilement (donc grosse boite noire), mais donc avec tout son volume. Après il y en a peux être qui "compilent" vraiment, mais pour du Python générique (non modifié pour) j'en vois pas.
Tout à fait d'accord que de toute manière ces langages ont atteint un tel poids dans l'historique, qu'ils ne vont pas disparaitre comme ça. Mais dès qu'il y aura une contraite (légale, sécurité, "plus de dev/trop cher") là ils seront remplacé par le standard de l'industrie à ce moment là (qui deviendra lui même obsolète, cycle éternel et merveilleux :D )
L'argument de la sécurité est valable en tout cas. Quand on voit l'enfer d'audit des dépendances en cascades, moins de langages ne serait pas un mal. Après mêmes les langages compilés sont touchés, juste que les dépendances sont bundlelisées et pas ultra-visibles comme sur python/node/XXX.
Mais là encore: est-ce que notre très cher (double sens) chef de projet a plus d'intérêt (€) à faire un projet rapide qu'un projet blindé/audité/maitrisé? Pour l'instant je n'ai pas l'impression qu'on va dans ce sens pour une majorité (je mets de côté les industries où c'est le légal qui l'impose, genre aérospatial, etc).
Or même avec les derniers soucis majeur en terme de sécurité sur la chaine, j'ai pas l'impression que les habitudes aient tellement changées. Jusqu'à la prochaine faille exploitable à distance dans un module standard? :p
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Non, non, il y a vraiment des compilo pour du Python et du Perl aussi. Mais la plupart du temps en effet, c'est un interpréteur (du byte code)
Pour l'enfer d'audit des dépendance, ce n'est pas forcément la réduction du nombre de langages qui peut solutionner cela je pense. Avec n'importe quel langage, on peut faire beaucoup de dépendances ou en avoir un nombre réduit, et c'est la maîtrise de ce nombre réduit qui doit être recherché et qui n'est pas toujours fait.
Le problème du chefs de projets actuels est que ce sont comme des commerciaux qui promettent toujours d'aller plus vite que la musique et espèrent être très loin quand ça pète. Du coup, n'ayant pas à répondre par la suite de leur méfaits, ils ne peuvent pas rechercher la qualité intrinsèquement. (ma méchante humeur du vendredi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 15 juillet 2022 à 11:00.
Ah noter que dans un avenir proche tous les bacheliers ou tous les bacheliers scientifiques auront eu une formation initiale en python.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Vraie question
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Enlever les Maths, rajouter du Python, why not :p
En tout cas ça va fortement jouer en sa faveur pour les nouveaux projets. On est toujours un peu attaché à son premier langage (ah mon cher C, ce qu'on a pu se détester mutuellement, moi avec des insultes sur gdb, toi avec des segfaults).
Ce n'est pas un mauvais choix en tout cas, Python a quand même été pensé au tout début pour des débutants. On peux encore faire des choses simplement avec.
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
La tendance est à fournir des gens qui savent écrire dans un langage de programmation et non des gens qui savent faire des algorithmes et les traduire dans n'importe quel autre langage. Mais je m'éloigne du sujet avec ces allégations.
Ça n'a pas fait pour autant perdurer BASIC (en dehors de µ$) ou Pascal malgré Delphi (qui est son pendant VB non ?)
Mais je comprends ce que tu veux dire quand j'ai vu qu'une génération de gens formés à Java ont eu du mal à appliquer les concepts POO avec d'autres langages.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par flagos . Évalué à 3.
Moins de libs, c'est effectivement mieux du point de vue de la securite. Mais ca n'est pas la seule variable a prendre en compte.
Des audits du code, une communauté importante et impliquée, un système de mise a jour des dépendances bien huile, tout ça compte. Et la dessus Python a nettement l'avantage sur Perl.
Personnellement, ca me rassure pas tant que ca que l'install systeme de perl fasse 7 MB au lieu de 10 MB pour python. Je ne suis meme jamais pose la question, et je ne vois pas vraiment quel lien je pourrais faire avec la securite. Par contre la facilite de pouvoir relire moi même les scripts dans un langage pas obscure et sans siouxeries de syntaxe toutes les 3 lignes, ca je trouve ca plus important.
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Euh… Que reproches-tu aux modules Perl et qui serait mieux fait de l'autre côté ? Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.
Exactement le souci que j'ai avec nombre de scripts Python dont j'hérite et qui sont imbitables à souhait pour une bonne moitié. J'ai souvent plus vite fait de réécrire et ça n'empêche que je tombe une fois sur cinq sur des trucs un peu tordus.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par GuieA_7 (site web personnel) . Évalué à 2. Dernière modification le 16 juillet 2022 à 15:23.
Les gens du CPAN ont vraiment une solution à ce problème, ou bien le problème existe quand même mais on en n'entend juste pas (ou moins) parler ?
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Bonne question :-) Je ne me suis jamais personnellement penché dessus, mais j'ai remarqué que dans la plupart des distributions Linux (quand j'ai regardé), c'est organisé comme les bibliothèques partagées : plusieurs versions peuvent cohabiter. Mais, je pense que la réponse est ailleurs : PERL est l'un des rares langages de scripting à tenter de garder un maximum de compatibilité ascendante. Du coup, les distributions fournissent juste la dernière distribution stable en sachant que tous les anciens codes vont continuer à tourner.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
C'est étrange, je n'ai pas du tout la même expérience.
Pour ce que j'en ai vu, c'est exactement la même chose : la philosophie du langage ne dit pas qu'un projet ne doit pas avoir de règles et je n'ai jamais vu de devs Perl ne pas se faire aux règles du projet. Par ailleurs, ces gens (qui son décrits comme des aliens) ne sont pas si rares que tu dis, en tout cas ce n'est pas le constat que je fais.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 15 juillet 2022 à 17:06.
Alors pour l'occupation mémoire de Python, il existe Micropython, d'après https://lwn.net/Articles/725508/ il peut fonctionner avec 256K de code et 16K de RAM (et c'est en baremetal sans avoir besoin d'un OS en-dessous).
Il ne me semble pas avoir vu Perl faire aussi bien.
D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages: MicroPython pour l'embarqué avec quelques Ko de RAM, cython quand on a besoin de compiler le code pour qu'il tourne plus vite, etc. On est en fait bien au-delà d'un simple langage de script.
Il va donc peut être remplacer C++ quand il en aura fini avec Perl?
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme répondu ailleurs, la plupart des langages de script sont compilables aussi, y compris Perl
https://www.marcbilodeau.com/compiling-perl/
Un autre commentaire a invoqué l'implémentation de busybox… On peut ajouter, par exemple, Jerl et PLJava et perljvm comme implémentations Java. Et Parrot est pensé pour se voir interfacer n'importe quel langage (y compris Python, cf. PEP401) tandis que Raku-do permet à Perl/Raku d'implémenter n'importe quel autre langage.
Maintenant, pendant que certaines personnes s'échinent inutilement à remplacer l'un par l'autre, les principaux acteurs préfèrent faire des ponts : Inline::Python et PyPerl
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par GuieA_7 (site web personnel) . Évalué à 2.
À ma connaissance Parrot est mort (je n'ai jamais trouvé de gros intérêt au projet, mais j'étais quand même curieux de voir ce qu'ils arriveraient à faire).
[^] # Re: Vraie question
Posté par barmic 🦦 . Évalué à 5.
Oui et non. Ces implémentations n'implémentent que le langage et pas l'API C, ils ont généralement une tambouille pour numpy, mais hors de ça tu n'a pas accès aux bibliothèques qui utilisent du C. On est pas sur un drop in remplacement tel qu'on pourrait s'y attendre. Ensuite micropython implémente pas tout python (toute la bibliothèque standard n'est pas là) et la dernière version est en python 3.4 (avec des bouts de 3.5) version qui a 8 ans et qui est considérée en fin de vie. Pypy supporte jusqu'à 3.7 (version encore supportée upstream) et a une couche de compatibilité pour les bibliothèques qui utilisent du c c'est cool.
Et on pourrait faire la liste comme ça pour chacun. Bref mon point c'est qu'il s'agit pas d'implémentations où tu change la stack et c'est parti. Tu code généralement en sachant quelle implementation tu va utiliser c'est très différent comme approche.
Après quant à perl vs python, il faut comprendre qu'une grande partie du succès ou non ne vient pas d'une valeur intrinsèque. Perl, ruby, python sont 3 très bons languages sinon on en parlerai plus 25 ans après leur apparition. Il se fait qu'actuellement c'est python qui semble de loin le plus populaire, mais ça n'est pas une raison pour tuer les autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Tentative de résurrection
Posté par David Demelier (site web personnel) . Évalué à 3.
Pour moi déjà quand tu en arrives à devoir écrire un article pour justifier une technologie, c'est que la dite techno est mourante.
Bien évidemment tout est subjectif mais pour moi Perl est le langage dont la syntaxe est la plus horrible avec des mots clés de une à deux lettres
q, qq, qx, qw, etc.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Tentative de résurrection
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 15 juillet 2022 à 16:05.
Ouch… Ça ne va pas plaire aux gens qui l'ont fait pour… Python, Rust, etc. :-)
Mais bien d'accord que c'est trop succinct (et donc parait cryptique —et non horrible) d'avoir une flopée de mot-clés d'une à deux lettres …même si ça ne bat pas : APL, J, BrainFuck, SKI, …
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Tentative de résurrection
Posté par barmic 🦦 . Évalué à 3.
Contrairement à une idée très répandue le brainfuck est pas très compliqué. Par contre le moins connu malbolge est de très loin le langage le plus complexe que j'ai pu voir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tentative de résurrection
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne connaissais pas Malbolge. Je trouve bien l'usage de 3 états au lieu de 2, par contre le chiffrement complexifie alors que le fonctionnement du registre c n'est déjà pas évident…
Brainfuck est juste un assembleur d'une machine de Turing, avec des mots clés d'un seul caractère… (d'où le fait que je l'ai mentionné.) Mais comparativement j'ai trouvé Whitespace plus hermétique …bien que je doive admettre aujourd'hui que c'est rien à côté de Malbolge.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.