Je trouve l'idée rigolote, mais je suis surpris de cibler bash et de ne pas se servir de ce qu'il peut apporter. Autant cibler un shell POSIX à ce moment là.
Par exemple, pour faire de la validation de paramètres (vérifier qu'un code postal ou qu'une adresse mail correspond bien au format attendu), tu as peu de méthodes lisibles et maintenables. Dès que tu as des espaces ou des retours à la ligne dans tes paramètres ou le flux d'entrée (stdin), ça devient galère, faut sortir 25 outils, et ça devient illisible.
En soi, c'est prévu comme ça : un outil pour chaque tâche, flux orienté texte, des outils qui peuvent se brancher ensemble. Mais dès que tu commences à envoyer des trucs tordus, ça ne tient pas avec du shell. Alors qu'avec un langage qui gère les variables en tant qu'entité, tu as plus de contrôle.
Bash a de quoi gérer les cas simples avec l'opérateur =~, mais tu es vite en train d'empiler des cut et des tr. Rapidement, on se retrouve avec du sed, du awk, ou des appels à des outils comme jq, ou des sous-shell (blah="{mathjax} (echo \"{blih}\" | grep ...)") qui permettent l'injection de code. Ça ressemble plus à du scrapping qu'à de la validation, à la fin.
Et quitte à utiliser sed et awk, autant se donner les moyens et sortir Python ou Perl :).
Mais : souvent, je fais malgré tout des scripts shell pour des trucs simples, parce que la flemme, parce que pratique et vite fait. Mais je sais que ça reste limité et que tôt ou tard ça va me péter au nez !
Oui, car la phrase (que j'ai écrite) est bien ça fait une belle démonstration que le shell est très mal placé pour faire du code sûr et maintenable, et je le maintiens. Ce que je veux dire, c'est que faire des trucs un peu rigoureux en shell est voué à l'échec.
Je n'ai pas vraiment d'avis sur Amber en soi, en dehors de trouver l'exercice amusant1 : l'objectif du projet ne m'intéresse tout simplement pas :).
Dans l'exemple donné, tu pars de code simple et clair, et tu arrives avec un pile de merde, comme montré par barmic.
J'ai bien compris ton point de vue sur le shell, ce que je n'ai pas compris par contre, c'est en quoi l'existence même de amber en est une démonstration.
Je suis pas certain que beaucoup de transpilateurs donnent dans le langage cible des programmes concis et élégants, ce n'est en général pas le but.
L'affirmation « Ça fait une belle démonstration que le shell est très mal placé pour faire du code sûr et maintenable » me perturbe, je ne vois vraiment pas en quoi il y a une démonstration.
En effet, mon commentaire portait sur le shell et ses difficultés, et pas tellement sur Amber ou d'autres systèmes équivalents (Typescript me vient à l'esprit).
Je suis sincèrement désolé d'avoir heurté la logique et par la même, de t'avoir perturbé, par manque de précision et de rigueur dans mon expression écrite.
Je suis pas certain que beaucoup de transpilateurs donnent dans le langage cible des programmes concis et élégants, ce n'est en général pas le but.
Un compilateur peut avoir effectivement différent objectifs :
la performance: ici la multiplication des sous programme ne va pas dans ce sens
la vérification de certaines propriétés (comme le typage): il y a effectivement du typage dans amber
les fonctionnalités: amber apporte donne plus de contrôle quand on importe un fichier (le fichier importé choisi ce qui est publique ou pas et celui qui importe choisi ce qu'il importe), la gestion des erreurs de commande sympa et probablement quelques autres choses
Leur choix d'exemple de la page d'accueil est vraiment le plus nul que j'ai eu l'occasion de voir, mais je révise mon jugement je comprends à quoi il sert.
C'est surtout que la démonstration est faite qu'avoir un langage qui compile en shell/bash est un peu une étrangeté.
Si c'est pas pour maintenir le shell derrière je peine à trouver un intérêt. Tu compiles vers un langage pas trop fait pour être une cible, avec un interpréteur peu performant …
C'est surtout que la démonstration est faite qu'avoir un langage qui compile en shell/bash est un peu une étrangeté.
Pas plus que de compiler vers JS. Tu compile vers JS pour que ça puisse s'exécuter dans n'importe quel navigateur. Tu pourrais imaginer compiler vers du shell pour exécuter sur n'importe quel unix-like. Le choix de bash par rapport à un bourne shell est surprenant, mais je pense que c'est par simplicité pour eux pour certains types.
Posté par barmic 🦦 .
Évalué à 6.
Dernière modification le 29 mai 2024 à 09:31.
En fait je serais d'accord si le projet utilisait correctement le shell, ce qui n'est pas le cas de mon point de vu.
Leur exemple
ifage<18{echo"I'm not an adult yet"}else{echo"I'm an adult"}
devient
__0_age=30;if[$(echo${__0_age}'<'18| bc -l | sed '/\./ s/\.\{0,1} 0\{1,\}$//') !=0];thenecho"I'm not an adult yet"elseecho"I'm an adult"fi
Personne n'écrirait ça. Pas parce qu'il laisserait des problèmes potenitels juste parce que la bonne manière de l'écrire c'est
__0_age=30;if[["${__0_age}" -lt 18]];thenecho"I'm not an adult yet"elseecho"I'm an adult"fi
Ca ne gère pas les cas où l'opération mathématique est plus complexe ni quand à la place de 18 tu as un nombre qui est arbitrairement lent, mais j'attends d'un compilateur qu'il utilise la forme la plus efficace possible pour le code que je lui ai donné. Là je ne vois pas ce qu'il apporte en générant du code moins efficace, moins lisible et moins performant que ce que j'aurais écris (probablement pas plus difficilement que la source que j'aurais dû donner au compilateur).
Je oense surtout que beaucoup de monde veut faire faire a des scripts shell des choses pour lesquelles il n'est pas prevu ni conçu. Il ne me viendrait jamais à l'idée d'utiliser le shell pour les cas que tu presentes. Dans ce cas je prefère utiliser d'autres langages mieux adaptés (ona eu Perl, ensuite Ruby et Python, et maintenant on a go … ), même si c'est faisable en shell.
Ne pas oublier que le shel n'est pas là pour faire, mais pour faire faire: c'est avant tout une espece de glue entre plein d'outils.
je comprends ce point de vue, et j'abonde sur le fait que le shell c'est pas fait pour faire des choses complexes; y'a toujours un présupposé quelque part qui peut tout foutre en l'air cependant je trouve aussi que les gens ont tendance à se compliquer la vie à coup de sed/awk/grep alors que read fait beaucoup, surtout couplé avec IFS.
en gros un
IFS='#'read _ id _ prenom nom _ <<<"$MESCHAMPS"
sera bien plus lisible qu'une succession de
id=$(...)prenom=$(...)
mais j'ai comme présupposé que # n'apparait pas dans les champs utilisés; une parade peut être en entrée de chaine un sed -r 's/#/YAUNDIESEDANSLECHAMP/' et son opération inverse en sortie, mais dans ce cas on remplace le présupposé que y'a pas la chaine YAUNDIESEDANSLECHAMP en entrée; on peut aussi donner 3 coups de tête sur le clavier pour générer la chaine de remplacement, ça devrait éviter les accidents.
Bien évidemment on peut remplacer # par autre chose, mais faut s'assurer que ce n'est pas présent dans le flux.
pour revenir à la validation d'un code postal ou d'un email, je pense qu'il est illusoire de chercher à valider à 100%, que la saisie est correcte; mais juste que le champs ressemble bien à l'attendu en gros pour une adresse mail .+@.+ devrait suffire à gérer le plus gros, car de toutes façon on ne peut pas savoir si le mail est bon, pour ça faut une validation en envoyant le mail, et au vu de la véritable validation d'une adresse de courriel, c'est plus simple.
Pour le code postal, a moins d'avoir une règle par pays, un code de plus de 2 caractères devrait suffire.
enfin faut pas hésiter a sortir d'autre outils comme le perl, quitte à les instrumenter via du shell, des choses se font très bien en bash, et sont plus galère à gérer avec le perl (et inversement)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Si, comme je le comprends, l'objectif est la portabilité, oui ils auraient dû transpiler vers du shell posix.
Oui le code est immonde (en particulier la dépendance à bc pour les boucles !!).
Cependant si le but est d'éviter les plus grosses bourdes en bash en utilisant un langage plus strict, tout en conservant la compatibilité, je trouve la démarche plutôt intéressante.
Oui le code est immonde (en particulier la dépendance à bc pour les boucles !!).
et fait en plus appel à des sous processus inutiles
for((i=0; i < 11; i++ ))doecho"je sais compter jusqu'à $i"done
pour l'immense majorité des opération $(( )) fait l'affaire, bc c'est si on va jouer avec des flotant, sauf que si comme le machin le prétends il a un typage fort, il devrait privilégier les fonctionnalité du bash; et si on commence à vouloir faire du calcul flottant en script shell, faut se poser la question sur sa santé mentale.
ps : il ne manque pas de $ à ma boucle for.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Résultat
Posté par barmic 🦦 . Évalué à 10.
C'est moi où le code compilé est immonde?
Je trouve l'idée rigolote, mais je suis surpris de cibler bash et de ne pas se servir de ce qu'il peut apporter. Autant cibler un shell POSIX à ce moment là.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résultat
Posté par cg . Évalué à 2.
Mon premier réflexe a été d'aller voir si c'était pas un canular :), mais non, le projet a presque deux ans !
Ça fait une belle démonstration que le shell est très mal placé pour faire du code sûr et maintenable.
[^] # Re: Résultat
Posté par barmic 🦦 . Évalué à 2.
Je ne comprends pas en quoi ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résultat
Posté par cg . Évalué à 5.
Par exemple, pour faire de la validation de paramètres (vérifier qu'un code postal ou qu'une adresse mail correspond bien au format attendu), tu as peu de méthodes lisibles et maintenables. Dès que tu as des espaces ou des retours à la ligne dans tes paramètres ou le flux d'entrée (stdin), ça devient galère, faut sortir 25 outils, et ça devient illisible.
En soi, c'est prévu comme ça : un outil pour chaque tâche, flux orienté texte, des outils qui peuvent se brancher ensemble. Mais dès que tu commences à envoyer des trucs tordus, ça ne tient pas avec du shell. Alors qu'avec un langage qui gère les variables en tant qu'entité, tu as plus de contrôle.
Bash a de quoi gérer les cas simples avec l'opérateur
=~, mais tu es vite en train d'empiler descutet destr. Rapidement, on se retrouve avec dused, duawk, ou des appels à des outils commejq, ou des sous-shell (blah="{mathjax} (echo \"{blih}\" | grep ...)") qui permettent l'injection de code. Ça ressemble plus à du scrapping qu'à de la validation, à la fin.Et quitte à utiliser sed et awk, autant se donner les moyens et sortir Python ou Perl :).
Mais : souvent, je fais malgré tout des scripts shell pour des trucs simples, parce que la flemme, parce que pratique et vite fait. Mais je sais que ça reste limité et que tôt ou tard ça va me péter au nez !
[^] # Re: Résultat
Posté par Barnabé . Évalué à 1. Dernière modification le 29 mai 2024 à 09:00.
là, tu réponds à la question « En quoi le shell est-il très mal placé pour faire du code sûr et maintenable ? »
Tu ne nous dis pas en revanche en quoi l'existence du projet Amber en est «une belle démonstration».
[^] # Re: Résultat
Posté par cg . Évalué à 3.
Oui, car la phrase (que j'ai écrite) est bien ça fait une belle démonstration que le shell est très mal placé pour faire du code sûr et maintenable, et je le maintiens. Ce que je veux dire, c'est que faire des trucs un peu rigoureux en shell est voué à l'échec.
Je n'ai pas vraiment d'avis sur Amber en soi, en dehors de trouver l'exercice amusant1 : l'objectif du projet ne m'intéresse tout simplement pas :).
Dans l'exemple donné, tu pars de code simple et clair, et tu arrives avec un pile de merde, comme montré par barmic.
et y'a plein de langages farfelus, c'est chouette ! ↩
[^] # Re: Résultat
Posté par Barnabé . Évalué à 1.
J'ai bien compris ton point de vue sur le shell, ce que je n'ai pas compris par contre, c'est en quoi l'existence même de amber en est une démonstration.
[^] # Re: Résultat
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Peut-être dans le sens où, avec Amber, il est très facile d'écrire un code simpliste, et d'observer sa retranscription assez hermétique en shell ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Résultat
Posté par Barnabé . Évalué à 3.
Je suis pas certain que beaucoup de transpilateurs donnent dans le langage cible des programmes concis et élégants, ce n'est en général pas le but.
L'affirmation « Ça fait une belle démonstration que le shell est très mal placé pour faire du code sûr et maintenable » me perturbe, je ne vois vraiment pas en quoi il y a une démonstration.
[^] # Re: Résultat
Posté par cg . Évalué à 3.
En effet, mon commentaire portait sur le shell et ses difficultés, et pas tellement sur Amber ou d'autres systèmes équivalents (Typescript me vient à l'esprit).
Je suis sincèrement désolé d'avoir heurté la logique et par la même, de t'avoir perturbé, par manque de précision et de rigueur dans mon expression écrite.
[^] # Re: Résultat
Posté par barmic 🦦 . Évalué à 4.
Un compilateur peut avoir effectivement différent objectifs :
Leur choix d'exemple de la page d'accueil est vraiment le plus nul que j'ai eu l'occasion de voir, mais je révise mon jugement je comprends à quoi il sert.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résultat
Posté par Thomas Douillard . Évalué à 4.
C'est surtout que la démonstration est faite qu'avoir un langage qui compile en shell/bash est un peu une étrangeté.
Si c'est pas pour maintenir le shell derrière je peine à trouver un intérêt. Tu compiles vers un langage pas trop fait pour être une cible, avec un interpréteur peu performant …
[^] # Re: Résultat
Posté par barmic 🦦 . Évalué à 3.
Pas plus que de compiler vers JS. Tu compile vers JS pour que ça puisse s'exécuter dans n'importe quel navigateur. Tu pourrais imaginer compiler vers du shell pour exécuter sur n'importe quel unix-like. Le choix de bash par rapport à un bourne shell est surprenant, mais je pense que c'est par simplicité pour eux pour certains types.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résultat
Posté par barmic 🦦 . Évalué à 6. Dernière modification le 29 mai 2024 à 09:31.
En fait je serais d'accord si le projet utilisait correctement le shell, ce qui n'est pas le cas de mon point de vu.
Leur exemple
devient
Personne n'écrirait ça. Pas parce qu'il laisserait des problèmes potenitels juste parce que la bonne manière de l'écrire c'est
Ca ne gère pas les cas où l'opération mathématique est plus complexe ni quand à la place de 18 tu as un nombre qui est arbitrairement lent, mais j'attends d'un compilateur qu'il utilise la forme la plus efficace possible pour le code que je lui ai donné. Là je ne vois pas ce qu'il apporte en générant du code moins efficace, moins lisible et moins performant que ce que j'aurais écris (probablement pas plus difficilement que la source que j'aurais dû donner au compilateur).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Résultat
Posté par totof2000 . Évalué à 9.
Je oense surtout que beaucoup de monde veut faire faire a des scripts shell des choses pour lesquelles il n'est pas prevu ni conçu. Il ne me viendrait jamais à l'idée d'utiliser le shell pour les cas que tu presentes. Dans ce cas je prefère utiliser d'autres langages mieux adaptés (ona eu Perl, ensuite Ruby et Python, et maintenant on a go … ), même si c'est faisable en shell.
Ne pas oublier que le shel n'est pas là pour faire, mais pour faire faire: c'est avant tout une espece de glue entre plein d'outils.
[^] # Re: Résultat
Posté par fearan . Évalué à 5.
je comprends ce point de vue, et j'abonde sur le fait que le shell c'est pas fait pour faire des choses complexes; y'a toujours un présupposé quelque part qui peut tout foutre en l'air cependant je trouve aussi que les gens ont tendance à se compliquer la vie à coup de sed/awk/grep alors que read fait beaucoup, surtout couplé avec IFS.
en gros un
sera bien plus lisible qu'une succession de
mais j'ai comme présupposé que # n'apparait pas dans les champs utilisés; une parade peut être en entrée de chaine un sed -r 's/#/YAUNDIESEDANSLECHAMP/' et son opération inverse en sortie, mais dans ce cas on remplace le présupposé que y'a pas la chaine YAUNDIESEDANSLECHAMP en entrée; on peut aussi donner 3 coups de tête sur le clavier pour générer la chaine de remplacement, ça devrait éviter les accidents.
Bien évidemment on peut remplacer # par autre chose, mais faut s'assurer que ce n'est pas présent dans le flux.
pour revenir à la validation d'un code postal ou d'un email, je pense qu'il est illusoire de chercher à valider à 100%, que la saisie est correcte; mais juste que le champs ressemble bien à l'attendu en gros pour une adresse mail .+@.+ devrait suffire à gérer le plus gros, car de toutes façon on ne peut pas savoir si le mail est bon, pour ça faut une validation en envoyant le mail, et au vu de la véritable validation d'une adresse de courriel, c'est plus simple.
Pour le code postal, a moins d'avoir une règle par pays, un code de plus de 2 caractères devrait suffire.
enfin faut pas hésiter a sortir d'autre outils comme le perl, quitte à les instrumenter via du shell, des choses se font très bien en bash, et sont plus galère à gérer avec le perl (et inversement)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Résultat
Posté par steph1978 . Évalué à 2.
Si, comme je le comprends, l'objectif est la portabilité, oui ils auraient dû transpiler vers du shell posix.
Oui le code est immonde (en particulier la dépendance à
bcpour les boucles !!).Cependant si le but est d'éviter les plus grosses bourdes en bash en utilisant un langage plus strict, tout en conservant la compatibilité, je trouve la démarche plutôt intéressante.
Ça manque de
|par contre …[^] # Re: Résultat
Posté par fearan . Évalué à 5.
et fait en plus appel à des sous processus inutiles
pour l'immense majorité des opération $(( )) fait l'affaire, bc c'est si on va jouer avec des flotant, sauf que si comme le machin le prétends il a un typage fort, il devrait privilégier les fonctionnalité du bash; et si on commence à vouloir faire du calcul flottant en script shell, faut se poser la question sur sa santé mentale.
ps : il ne manque pas de $ à ma boucle for.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Résultat
Posté par barmic 🦦 . Évalué à 4.
À mon avis c'est pour les tableaux qu'ils ont préféré cibler bash. Les faire en bourn shell est vraiment douloureux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# alternatives
Posté par steph1978 . Évalué à 3.
Ça me rappelle ce que font un google zx ou un Bun Shell.
J'imagine que cela permet à des DEV de faire un peu d'OPS.
[^] # Re: alternatives
Posté par barmic 🦦 . Évalué à 4.
Ouai après perl, python, ruby et consorts sont là depuis longtemps aussi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternatives
Posté par steph1978 . Évalué à 2.
Oui, je proposais des choses qui restent autour d'une syntaxe ECMA script, point commun de ces trois outils.
[^] # Re: alternatives
Posté par barmic 🦦 . Évalué à 2.
Ah effectivement je n'avais pas relevé ce point. Bien vu !
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.