Dommage que tu utilise un temps condescendant comme ça mais bon.
Ce n'était pas mon intention. J'espère que depuis le temps, tu sais que si je parle de quelque chose c'est que je pense que l'échange est intéressant.
Dans ton script je ne sais pas ce que font la méthode get_fname par exemple.
Je l'ai volontairement omis. C'est une méthode qui se débrouille pour m'extraire ce dont j'ai besoin (ou rien) d'une ligne. Typiquement en shell tu ferais ca extrayant le dernier champs (awk) et tu traiterait ce champ pour virer un prefix et quelques autres règle métier pourries (plus chiant en shell ca).
C'est nettement moins concis, alors que je trouve qu'en shell avec pipe, tu as tes traitements qui sont découpés et tu lis ton algo.
Je ne considère plus la concision comme une bonne métrique, surtout pas en ce basant sur du code "facile". La facilité, lisibilité, la maintenance et la sécurité sont pour moi bien plus important.
Tu retrouves avec les pipes les mêmes problème que quand tu joues en fonctionnel sur des collections. C'est itératif à développer, c'est plaisant mais tu as vite fait de faire des trucs imbitables à postériori. Il faut être vigilant
Pour la typo sur les noms de variables c'est bizarre d'en parler et d'expliquer que python c'est mieux parce qu'en effet c'est un peu mieux, mais si tu te rate uniquement sur une écriture intermédiaire dans ta variable tu est tout aussi mal
Je ne milite absolument pas pour Python et j'aimerai laisser de côté cela, je m'en suis servi comme exemple. L'idée c'est que tu as des langages mieux designé que le shell, avec des environnements de dev beaucoup mieux fourni et évolués. Pourquoi ne pas chercher à leur permettre de faire élégamment ce que tu fais avec des scripts shell. Il y a tout a y gagner. Tu gardes les mêmes fonctionnalité en te libérant de beaucoup de contraintes.
Pour ton point précis, l'interpréteur Python sera beaucoup moins tolérant aux erreurs, et l'environnement t'apporte une plus grand sureté (IDE qui t'insulte, facilité à écrire des tests etc.). Mais comme j'ai dit, ce n'est qu'un exemple. J'aurais pu l'écrire avec autre chose, chaque choix à ses faiblesses.
la gestion des ressources (la fermeture des fichiers par exemple) est gérée de base, etc
Pour les mêmes opérations c'est la même chose. Si tu veux faire un pipe ou écrire dans un fichier, aucune raison de faire autre chose. Maintenant si je veux des set, je préfère utiliser un objet plutôt que de m'emmerder à jouer avec 4 commandes par ce qu'il n'y a pas mieux. Bref le but c'est que tu ne perde "rien" mais que tu gagnes beaucoup de choses.
Tout le travail est d'exporter des API propre dans les autres langages. Par exemple en Scala
Si a un endroit je pense qu'il faut mieux faire un traitement moi même plutôt que le déléguer à un outil je peux le faire très facilement. Il n'est pas question de remplacer l'un par l'autre.
[^] # Re: hop hop
Posté par ckyl . En réponse au journal Lister les programmes installés sur un (ou plusieurs) poste(s) sous Windows (XP ou 7). Évalué à 3.
Ce n'était pas mon intention. J'espère que depuis le temps, tu sais que si je parle de quelque chose c'est que je pense que l'échange est intéressant.
Je l'ai volontairement omis. C'est une méthode qui se débrouille pour m'extraire ce dont j'ai besoin (ou rien) d'une ligne. Typiquement en shell tu ferais ca extrayant le dernier champs (awk) et tu traiterait ce champ pour virer un prefix et quelques autres règle métier pourries (plus chiant en shell ca).
Je ne considère plus la concision comme une bonne métrique, surtout pas en ce basant sur du code "facile". La facilité, lisibilité, la maintenance et la sécurité sont pour moi bien plus important.
Tu retrouves avec les pipes les mêmes problème que quand tu joues en fonctionnel sur des collections. C'est itératif à développer, c'est plaisant mais tu as vite fait de faire des trucs imbitables à postériori. Il faut être vigilant
Je ne milite absolument pas pour Python et j'aimerai laisser de côté cela, je m'en suis servi comme exemple. L'idée c'est que tu as des langages mieux designé que le shell, avec des environnements de dev beaucoup mieux fourni et évolués. Pourquoi ne pas chercher à leur permettre de faire élégamment ce que tu fais avec des scripts shell. Il y a tout a y gagner. Tu gardes les mêmes fonctionnalité en te libérant de beaucoup de contraintes.
Pour ton point précis, l'interpréteur Python sera beaucoup moins tolérant aux erreurs, et l'environnement t'apporte une plus grand sureté (IDE qui t'insulte, facilité à écrire des tests etc.). Mais comme j'ai dit, ce n'est qu'un exemple. J'aurais pu l'écrire avec autre chose, chaque choix à ses faiblesses.
Pour les mêmes opérations c'est la même chose. Si tu veux faire un pipe ou écrire dans un fichier, aucune raison de faire autre chose. Maintenant si je veux des set, je préfère utiliser un objet plutôt que de m'emmerder à jouer avec 4 commandes par ce qu'il n'y a pas mieux. Bref le but c'est que tu ne perde "rien" mais que tu gagnes beaucoup de choses.
Tout le travail est d'exporter des API propre dans les autres langages. Par exemple en Scala
Si a un endroit je pense qu'il faut mieux faire un traitement moi même plutôt que le déléguer à un outil je peux le faire très facilement. Il n'est pas question de remplacer l'un par l'autre.