Le naufrage est encore très très loin. Mais en me remettant à Perl récemment, j'ai souffert et me suis souvenu qu'il y a 20 ans j'aimais bien la souplesse de Perl qui me permettait de coder «comme en C» et d'aller vite avec des fonctions et des variables mal déclarées. Le côté pragmatique: j'ai besoin d'un truc (non essentiel) qui fonctionne, programmer n'est pas mon métier. Perl s'est rigidifié : les bonnes pratiques imposent d'être plus verbeux, on trouve de l'objet partout sans que ce soit justifié, le langage contient de plus en plus de fonctions avec leur lot d'astuces (in-)utiles à connaître. Perl est devenu difficile, casse-pied et long à taper.
Alors que Python… un script Python donne une impression de clarté, de rigueur et c'est concis et dépouillé. Et puis c'est de l'objet.
J'aimerai bien voir Perl revenir vers le langage de script efficace et puissant pour les administrateurs système, plutôt qu'essayer de redevenir le langage à tout faire leader dans toutes les catégories. Python est là, Perl a une place plus modeste.
Après, le côté purement objet de Python est sans doute à relativiser.
C'est l'inverse, c'est le multiparadigme qui est à relativiser. Python est un langage objet, qui comme c'est la mode, a des lambdas. Avoir des lambdas n'en fait pas un langage objet tout comme les struct du C ne font pas du C un langage objet. Cela permet de s'approcher d'un style de programmation fonctionnel, mais c'est (très) loin du moindre langage fonctionnel.
En pratique tu ne peux pas écrire de programme python sans le paradigme objet car tout est objet en python la moindre variable, le moindre entier que tu utilise est un objet.
Pour ce qui est de l'impératif c'est particulier car tous les langages objets que j'ai pu voir ont des gros morceaux d'impératif (en fait seul les langages fonctionnels, et les langages logiques que je connais n'ont pas d'impératif).
Après cela ne t'empêche pas d'utiliser un style fonctionnel/impératif/déclaratif/objet/… en python comme dans d'autres langages.
Je ne sais pas ce que l'on fait dans mon équipe mais on ne sait pratiquement pas ce que c'est l'orienté objet (nous ne sommes pas du tout programmeurs) et on fait plein de petits trucs en Python qui à mon humble avis ne ressemblent pas du tout à de l'objet.
En fait, je me suis un peu initié à Pharo avec des cours qui insistait énormément sur le côté objet et je t'assure que ce n'est pas ce que nous faisons avec Python sauf quand une librairie nous l'impose. Et dans ce dernier cas, on manipule des trucs très orienté objet en nous disant que l'implémentation/syntaxe du bazar est bizarre. Maintenant, je comprends un peu mieux.
Monsieur Jourdain ne connaît rien à la prose. Si tu manipule une variable tu as créé un objet. Vous faites, je présume du code qui ne crée pas de classe, qui fait peut usage de fonctions membres, mais ça n'empêche pas le langage d'implémenter tout ce que tu fais à travers un paradigme objet.
Python à l'amabilité syntaxique de ne pas avoir trop de boilerplate contrairement à java par exemple, mais ça n'en change pas le paradigme pour autant.
Python est un langage objet dont la syntaxe ne contraint pas à créer de classe et possède des lambdas.
La plupart des langages permettent d'avoir le style que tu veux par dessus, ce sera potentiellement moins agréable mais c'est tout (par exemple une partie du code de linux, écrit en C, utilise un pattern objet).
Non, je compare Perl à Perl 5 d'il y a 20-25 ans.
Ce n'est pas bien expliqué mais je compare à Python pour la propreté de la syntaxe et pour la grammaire vraiment objet et pas batarde. Même si Python ne fait pas que de l'objet.
Ce n'est pas bien expliqué mais je compare à Python pour la propreté de la syntaxe et pour la grammaire vraiment objet et pas batarde.
Ça vient de l'approche de l'existant. Python a cassé la compatibilité de son langage régulièrement là où perl prône la compatibilité avant tout. Mais je suis d'accord que je ne suis pas fan de l'implémentation objet de perl, même si j'ai vu des gens trouver ça super bien.
Par contre je ne suis pas d'accord avec ta critique. Ça me fait penser à une conversation qu'il y avait eu au sujet de php où un non utilisateurs du langage expliquait qu'il fallait que php reste dans son coin plutôt que d'essayer d'évoluer parce que lui il préférait.
Perl s'est rigidifié : les bonnes pratiques imposent d'être plus verbeux, on trouve de l'objet partout sans que ce soit justifié, le langage contient de plus en plus de fonctions avec leur lot d'astuces (in-)utiles à connaître.
Les bonnes pratiques restent juste des conseils. Je ne vois pas ce qui t'empêche d'écrire un script Perl comme tu l'écrivais il y a vint ans ? D'ailleurs il est fort probable qu'un script Perl écrit pendant l'année 2000 fonctionne avec la dernière version Perl 5.32.
Je ne vois pas ce qui t'empêche d'écrire un script Perl
La doc et les warnings.
La doc recommande des bonnes pratiques et les warnings sont tellement emmerdant que je respecte les bonnes pratiques pour avoir des warnings utiles. Ce qu'il faut surtout comprendre c'est que aborder ou ré-aborder aux rivages de Perl c'est devenu très lourd. Un débutant ne s'en sort pas.
C'est bizarre, mais en lisant l'article, j'ai eu l'impression que l'un des grands reproches est de ne pas pousser assez dans ce sens (doc et avertissements) et de laisser une impression d'un langage write once
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Perl a perdu son charme
Posté par orfenor . Évalué à 6.
Le naufrage est encore très très loin. Mais en me remettant à Perl récemment, j'ai souffert et me suis souvenu qu'il y a 20 ans j'aimais bien la souplesse de Perl qui me permettait de coder «comme en C» et d'aller vite avec des fonctions et des variables mal déclarées. Le côté pragmatique: j'ai besoin d'un truc (non essentiel) qui fonctionne, programmer n'est pas mon métier. Perl s'est rigidifié : les bonnes pratiques imposent d'être plus verbeux, on trouve de l'objet partout sans que ce soit justifié, le langage contient de plus en plus de fonctions avec leur lot d'astuces (in-)utiles à connaître. Perl est devenu difficile, casse-pied et long à taper.
Alors que Python… un script Python donne une impression de clarté, de rigueur et c'est concis et dépouillé. Et puis c'est de l'objet.
J'aimerai bien voir Perl revenir vers le langage de script efficace et puissant pour les administrateurs système, plutôt qu'essayer de redevenir le langage à tout faire leader dans toutes les catégories. Python est là, Perl a une place plus modeste.
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . Évalué à 3.
Tu reproche à Perl d'être trop objet en le comparant à python purement objet ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par tisaac (Mastodon) . Évalué à 3.
C'est vrai que point de vue logique argumentative, c'est particulier.
Après, le côté purement objet de Python est sans doute à relativiser.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . Évalué à 4.
C'est l'inverse, c'est le multiparadigme qui est à relativiser. Python est un langage objet, qui comme c'est la mode, a des lambdas. Avoir des lambdas n'en fait pas un langage objet tout comme les struct du C ne font pas du C un langage objet. Cela permet de s'approcher d'un style de programmation fonctionnel, mais c'est (très) loin du moindre langage fonctionnel.
En pratique tu ne peux pas écrire de programme python sans le paradigme objet car tout est objet en python la moindre variable, le moindre entier que tu utilise est un objet.
Pour ce qui est de l'impératif c'est particulier car tous les langages objets que j'ai pu voir ont des gros morceaux d'impératif (en fait seul les langages fonctionnels, et les langages logiques que je connais n'ont pas d'impératif).
Après cela ne t'empêche pas d'utiliser un style fonctionnel/impératif/déclaratif/objet/… en python comme dans d'autres langages.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par tisaac (Mastodon) . Évalué à 2.
Je ne sais pas ce que l'on fait dans mon équipe mais on ne sait pratiquement pas ce que c'est l'orienté objet (nous ne sommes pas du tout programmeurs) et on fait plein de petits trucs en Python qui à mon humble avis ne ressemblent pas du tout à de l'objet.
En fait, je me suis un peu initié à Pharo avec des cours qui insistait énormément sur le côté objet et je t'assure que ce n'est pas ce que nous faisons avec Python sauf quand une librairie nous l'impose. Et dans ce dernier cas, on manipule des trucs très orienté objet en nous disant que l'implémentation/syntaxe du bazar est bizarre. Maintenant, je comprends un peu mieux.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . Évalué à 4.
Monsieur Jourdain ne connaît rien à la prose. Si tu manipule une variable tu as créé un objet. Vous faites, je présume du code qui ne crée pas de classe, qui fait peut usage de fonctions membres, mais ça n'empêche pas le langage d'implémenter tout ce que tu fais à travers un paradigme objet.
Python à l'amabilité syntaxique de ne pas avoir trop de boilerplate contrairement à java par exemple, mais ça n'en change pas le paradigme pour autant.
Python est un langage objet dont la syntaxe ne contraint pas à créer de classe et possède des lambdas.
La plupart des langages permettent d'avoir le style que tu veux par dessus, ce sera potentiellement moins agréable mais c'est tout (par exemple une partie du code de linux, écrit en C, utilise un pattern objet).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par orfenor . Évalué à 2.
Non, je compare Perl à Perl 5 d'il y a 20-25 ans.
Ce n'est pas bien expliqué mais je compare à Python pour la propreté de la syntaxe et pour la grammaire vraiment objet et pas batarde. Même si Python ne fait pas que de l'objet.
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . Évalué à 3.
Ça vient de l'approche de l'existant. Python a cassé la compatibilité de son langage régulièrement là où perl prône la compatibilité avant tout. Mais je suis d'accord que je ne suis pas fan de l'implémentation objet de perl, même si j'ai vu des gens trouver ça super bien.
A quelque détail près si.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par barmic 🦦 . Évalué à 3.
Par contre je ne suis pas d'accord avec ta critique. Ça me fait penser à une conversation qu'il y avait eu au sujet de php où un non utilisateurs du langage expliquait qu'il fallait que php reste dans son coin plutôt que d'essayer d'évoluer parce que lui il préférait.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl a perdu son charme
Posté par orfenor . Évalué à 2.
Je n'ai jamais pensé ça. Mais Perl a évolué vers de la complication, comme s'il ne l'était déjà pas assez !
[^] # Re: Perl a perdu son charme
Posté par Bruno Ethvignot (site web personnel) . Évalué à 2. Dernière modification le 27 mars 2021 à 11:16.
Les bonnes pratiques restent juste des conseils. Je ne vois pas ce qui t'empêche d'écrire un script Perl comme tu l'écrivais il y a vint ans ? D'ailleurs il est fort probable qu'un script Perl écrit pendant l'année 2000 fonctionne avec la dernière version Perl 5.32.
[^] # Re: Perl a perdu son charme
Posté par orfenor . Évalué à 3.
La doc et les warnings.
La doc recommande des bonnes pratiques et les warnings sont tellement emmerdant que je respecte les bonnes pratiques pour avoir des warnings utiles. Ce qu'il faut surtout comprendre c'est que aborder ou ré-aborder aux rivages de Perl c'est devenu très lourd. Un débutant ne s'en sort pas.
[^] # Re: Perl a perdu son charme
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
C'est bizarre, mais en lisant l'article, j'ai eu l'impression que l'un des grands reproches est de ne pas pousser assez dans ce sens (doc et avertissements) et de laisser une impression d'un langage write once
“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.