Dans la série "Quel langage utiliser pour ...", je suis dans la
situation suivante:
Je déploie régulièrement un CMS utilisant PHP et MySQL sur des serveurs
Web. J'ai donc pris l'habitude de scripter (en shell) toutes les
opérations. Mais aujourd'hui, l'ensemble devient lourd, et difficilement
maintenable (c'est sans doute dû en partie à ma façon d'écrire en
shell). Du coup, je voudrais tout ré-écrire from scratch, et je me
demande si je devrais ou non changer de langage, et pour quel langage.
Les tâches de ces scripts sont typiquement:
- décompactage d'archives gzippées
- modification de fichiers de configuration
- upload via ftp
- création de scripts de commandes SQL
- requête HTTP (wget)
Je voudrais éventuellement étendre les capacités de ces scripts pour
qu'ils puissent lire des fichiers de configuration, exécuter directement
les scripts SQL, faire des sauvegardes avant upgrade, les rendre portables
vers des systèmes non-Unix (pas vital, toutefois) ...
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation
d'illisibilité du premier me freine, et l'existence du CPAN ne me pousse
pas vers le second. Sans vouloir provoquer de troll (comment ça "trop
tard" ?), j'aimerais bien avoir l'avis des uns et des autres, et
éventuellement des suggestions d'autres langages ...
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation d'illisibilité du premier me freine, et l'existence du CPAN ne me pousse pas vers le second. Sans vouloir provoquer de troll (comment ça "trop tard" ?), j'aimerais bien avoir l'avis des uns et des autres, et éventuellement des suggestions d'autres langages ...
On peut faire des choses très lisibles en Perl si on utilise pas les raccourcis permis, et que l'ont choisi de toujours tout écrire en entier. Après, il y a plusieurs style pour parcourir un fichier, plusieurs style pour faire tel chose, donc quand tu recuperes le programme perl de quelqu'un d'autre tu peux etre surpris. Mais dans tous les cas, je trouve que ca restera plus lisible et maintenable que du shell.
J'aime bien Perl, avec le livre Introduction a Perl de Schwartz et Phoenix (O'Reilly), pas trop long, et il permet d'aborder les bases du langage (il ne parle pas des modules pour acceder directement a un serveur SQL ou faire du dialogue http, ...).
-- Nicolas Le Scouarnec
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation
d'illisibilité du premier me freine, et l'existence du CPAN ne me pousse
pas vers le second. Sans vouloir provoquer de troll (comment ça "trop
tard" ?), j'aimerais bien avoir l'avis des uns et des autres, et
éventuellement des suggestions d'autres langages ...
On peut faire des choses très lisibles en Perl si on utilise pas les
raccourcis permis, et que l'ont choisi de toujours tout écrire en
entier. Après, il y a plusieurs style pour parcourir un fichier,
plusieurs style pour faire tel chose, donc quand tu recuperes le
programme perl de quelqu'un d'autre tu peux etre surpris. Mais dans
tous les cas, je trouve que ca restera plus lisible et maintenable que
du shell.
J'aime bien Perl, avec le livre Introduction a Perl de Schwartz et
Phoenix (O'Reilly), pas trop long, et il permet d'aborder les bases du
langage (il ne parle pas des modules pour acceder directement a un
serveur SQL ou faire du dialogue http, ...).
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation d'illisibilité du premier me freine, et l'existence du CPAN ne me pousse pas vers le second. Sans vouloir provoquer de troll (comment ça "trop tard" ?), j'aimerais bien avoir l'avis des uns et des autres, et éventuellement des suggestions d'autres langages ...
On peut faire des choses très lisibles en Perl si on utilise pas les raccourcis permis, et que l'ont choisi de toujours tout écrire en entier. Après, il y a plusieurs style pour parcourir un fichier, plusieurs style pour faire tel chose, donc quand tu recuperes le programme perl de quelqu'un d'autre tu peux etre surpris. Mais dans tous les cas, je trouve que ca restera plus lisible et maintenable que du shell.
J'aime bien Perl, avec le livre Introduction a Perl de Schwartz et Phoenix (O'Reilly), pas trop long, et il permet d'aborder les bases du langage (il ne parle pas des modules pour acceder directement a un serveur SQL ou faire du dialogue http, ...).
-- Nicolas Le Scouarnec
DoMinix
Étienne Labaume wrote:
Bonjour à tous,
Dans la série "Quel langage utiliser pour ...", je suis dans la situation suivante:
je vote Perl aussi car je le connais. et depuis que je l'utilise je n'utilise presque plus les autres. Mais je vais dans le sens de ceux qui préconise le conford de ce que l'on connais déjà. Si tu utilise déjà des langages (exclusivement) Objet, alors python sera peut etre plus "confortable" pour toi. J'ai un ami qui code tout en tcl, ça m'a toujours depassé completement mais lui il aime ça.
@++
-- dominix
Étienne Labaume wrote:
Bonjour à tous,
Dans la série "Quel langage utiliser pour ...", je suis dans la
situation suivante:
je vote Perl aussi car je le connais. et depuis que je l'utilise
je n'utilise presque plus les autres.
Mais je vais dans le sens de ceux qui préconise le conford de ce
que l'on connais déjà.
Si tu utilise déjà des langages (exclusivement) Objet, alors python
sera peut etre plus "confortable" pour toi.
J'ai un ami qui code tout en tcl, ça m'a toujours depassé
completement mais lui il aime ça.
Dans la série "Quel langage utiliser pour ...", je suis dans la situation suivante:
je vote Perl aussi car je le connais. et depuis que je l'utilise je n'utilise presque plus les autres. Mais je vais dans le sens de ceux qui préconise le conford de ce que l'on connais déjà. Si tu utilise déjà des langages (exclusivement) Objet, alors python sera peut etre plus "confortable" pour toi. J'ai un ami qui code tout en tcl, ça m'a toujours depassé completement mais lui il aime ça.
@++
-- dominix
Laurent Wacrenier
Jack Crow écrit:
je vote Perl aussi
un vrai langage, fait pour faire ce qui doit etre fait écrit par un linguiste et non pas par un barbu
Juste par un moustachu http://www.wall.org/~larry/
Jack Crow <jack.crow@caramail.com> écrit:
je vote Perl aussi
un vrai langage, fait pour faire ce qui doit etre fait
écrit par un linguiste et non pas par un barbu
Juste par un moustachu
http://www.wall.org/~larry/
J'adore son nom de domaine (dans le fichier). Tout a fait adapte a l'entreprise.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pascal Bourguignon
Christophe Gaubert writes:
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ? Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
(with-open-stream (out (ext:make-pipe-output-stream "cmd ...")) (loop for item in data do (format out "~A~%" item)))
etc..
Note qu'on peut ajouter des reader macros pour simplifier la syntaxe si on veut. Voir clash: http://clisp.cons.org/clash.html
On pourrait écrire une reader macro pour pouvoir échaper vers un shell normal quand on a beaucoup de sous commandes à utiliser; voir: #[ ls -l ] dans clash.
Ou bien, on peut lancer les commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de ne pas utiliser un langage de shell ?
Une alternative qui peut être plus adaptée pour écrire des scripts, c'est scsh, une scheme avec des fonctions "shell" (pipes, redirections, etc). Mais je préfère Common Lisp à Scheme.
Ah, j'ai fait du scheme, "il y a fort longtemps", m'en rappelle plus bien.
C'est un vrai langage de programmation, ainsi je n'ai aucun problème,
aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à
tous les outils habituels : grep, sed, find, etc
Il y a des outils de ce genre en clisp ?
Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
(with-open-stream (out (ext:make-pipe-output-stream "cmd ..."))
(loop for item in data
do (format out "~A~%" item)))
etc..
Note qu'on peut ajouter des reader macros pour simplifier la syntaxe
si on veut. Voir clash: http://clisp.cons.org/clash.html
On pourrait écrire une reader macro pour pouvoir échaper vers un shell
normal quand on a beaucoup de sous commandes à utiliser;
voir: #[ ls -l ] dans clash.
Ou bien, on peut lancer les
commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de
ne pas utiliser un langage de shell ?
Une alternative qui peut être plus adaptée pour écrire des scripts,
c'est scsh, une scheme avec des fonctions "shell" (pipes,
redirections, etc). Mais je préfère Common Lisp à Scheme.
Ah, j'ai fait du scheme, "il y a fort longtemps", m'en rappelle plus bien.
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ? Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
(with-open-stream (out (ext:make-pipe-output-stream "cmd ...")) (loop for item in data do (format out "~A~%" item)))
etc..
Note qu'on peut ajouter des reader macros pour simplifier la syntaxe si on veut. Voir clash: http://clisp.cons.org/clash.html
On pourrait écrire une reader macro pour pouvoir échaper vers un shell normal quand on a beaucoup de sous commandes à utiliser; voir: #[ ls -l ] dans clash.
Ou bien, on peut lancer les commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de ne pas utiliser un langage de shell ?
Une alternative qui peut être plus adaptée pour écrire des scripts, c'est scsh, une scheme avec des fonctions "shell" (pipes, redirections, etc). Mais je préfère Common Lisp à Scheme.
Ah, j'ai fait du scheme, "il y a fort longtemps", m'en rappelle plus bien.
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais lisp est beaucoup plus expressif!
Ceci dit; je ne suis pas sur que les ordinateurs actuels aient assez de mémoire pour implémenter en sed un programme lisp quelconque. Rappelons nous que la turing-equivalence se base sur une mémoire infinie!
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais
lisp est beaucoup plus expressif!
Ceci dit; je ne suis pas sur que les ordinateurs actuels aient assez
de mémoire pour implémenter en sed un programme lisp quelconque.
Rappelons nous que la turing-equivalence se base sur une mémoire
infinie!
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais lisp est beaucoup plus expressif!
Ceci dit; je ne suis pas sur que les ordinateurs actuels aient assez de mémoire pour implémenter en sed un programme lisp quelconque. Rappelons nous que la turing-equivalence se base sur une mémoire infinie!
Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY.
drkm
Christophe Gaubert writes:
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ? Ou bien, on peut lancer les commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de ne pas utiliser un langage de shell ?
Ce n'est jamais que ce que fait un shell. La syntaxe est juste différente. L'intérêt avec CL (enfin, un intérêt) est que tu peux facilement adapter la syntaxe à ce que tu souhaites.
Avec 'scsh', que je ne connais pas, il semblerait que l'équivalent du script shell :
Pour ce qui est des avantages, il y a le fait que tu peux faire tout ce que tu peux faire en CL. Ce n'est pas à négliger.
--drkm
Christophe Gaubert writes:
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à
tous les outils habituels : grep, sed, find, etc
Il y a des outils de ce genre en clisp ? Ou bien, on peut lancer les
commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de
ne pas utiliser un langage de shell ?
Ce n'est jamais que ce que fait un shell. La syntaxe est juste
différente. L'intérêt avec CL (enfin, un intérêt) est que tu
peux facilement adapter la syntaxe à ce que tu souhaites.
Avec 'scsh', que je ne connais pas, il semblerait que
l'équivalent du script shell :
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ? Ou bien, on peut lancer les commandes du système, mais à ce moment-là, je ne vois pas l'intérêt de ne pas utiliser un langage de shell ?
Ce n'est jamais que ce que fait un shell. La syntaxe est juste différente. L'intérêt avec CL (enfin, un intérêt) est que tu peux facilement adapter la syntaxe à ce que tu souhaites.
Avec 'scsh', que je ne connais pas, il semblerait que l'équivalent du script shell :
