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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Étienne Labaume <etienne.lab@wanadoo.fr> écrit:
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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour
moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Étienne Labaume
Le 31-08-2005, Laurent Wacrenier a écrit:
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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
-- Tinou
Le 31-08-2005, Laurent Wacrenier <lwa@teaser> a écrit:
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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour
moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et
l'autre de ces 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 ...
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
-- Tinou
Stephane Zuckerman
[réécriture de scripts]
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,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit de ne pas être paresseux (exactement comme en C), et de s'imposer des règles de codage -- surtout si vous ne serez pas le seul amené à relire les sources.
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas avoir vraiment cherché.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette fois en tête tout ce que ceux-ci sont sensés faire ?
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 ...
Python et Perl me semblent effectivement les deux "meilleurs" langages pour ce genre de choses, même si Ruby semble faire des émules aussi, comme il a déjà été dit.
En gros, si dans tous les cas vous devrez apprendre un langage, il me semble utile de se demander si *vraiment* il est impossible d'obtenir un script shelle unifié avec les extensions voulues, qui soit plus performant. Si la réponse à cette question est non, je ne peux que vous conseiller les tutoriels disponibles sur le Net, et de vous faire une idée par vous-même. Perl et Python se valent en terme de puissance. J'ai cru comprendre que Perl est néanmoins légèrement plus réactif que Python, mais rien n'est moins sûr.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
[réécriture de scripts]
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,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit de ne
pas être paresseux (exactement comme en C), et de s'imposer des règles de
codage -- surtout si vous ne serez pas le seul amené à relire les sources.
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas
avoir vraiment cherché.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette
fois en tête tout ce que ceux-ci sont sensés faire ?
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 ...
Python et Perl me semblent effectivement les deux "meilleurs" langages
pour ce genre de choses, même si Ruby semble faire des émules aussi, comme
il a déjà été dit.
En gros, si dans tous les cas vous devrez apprendre un langage, il me
semble utile de se demander si *vraiment* il est impossible d'obtenir un
script shelle unifié avec les extensions voulues, qui soit plus
performant. Si la réponse à cette question est non, je ne peux que vous
conseiller les tutoriels disponibles sur le Net, et de vous faire une idée
par vous-même. Perl et Python se valent en terme de puissance. J'ai cru
comprendre que Perl est néanmoins légèrement plus réactif que Python, mais
rien n'est moins sûr.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
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,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit de ne pas être paresseux (exactement comme en C), et de s'imposer des règles de codage -- surtout si vous ne serez pas le seul amené à relire les sources.
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas avoir vraiment cherché.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette fois en tête tout ce que ceux-ci sont sensés faire ?
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 ...
Python et Perl me semblent effectivement les deux "meilleurs" langages pour ce genre de choses, même si Ruby semble faire des émules aussi, comme il a déjà été dit.
En gros, si dans tous les cas vous devrez apprendre un langage, il me semble utile de se demander si *vraiment* il est impossible d'obtenir un script shelle unifié avec les extensions voulues, qui soit plus performant. Si la réponse à cette question est non, je ne peux que vous conseiller les tutoriels disponibles sur le Net, et de vous faire une idée par vous-même. Perl et Python se valent en terme de puissance. J'ai cru comprendre que Perl est néanmoins légèrement plus réactif que Python, mais rien n'est moins sûr.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Emmanuel Florac
Le Wed, 31 Aug 2005 11:31:45 +0000, Étienne Labaume a écrit :
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
Perl n'est pas illisible, mais il permet de faire du code illisible si on le souhaite. Le défaut de perl c'est la liberté absolue. C'est aussi bien sûr son gros avantage... Python au contraire est plutôt rigide...
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Le Wed, 31 Aug 2005 11:31:45 +0000, Étienne Labaume a écrit :
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et
l'autre de ces langages.
Perl n'est pas illisible, mais il permet de faire du code illisible si on
le souhaite. Le défaut de perl c'est la liberté absolue. C'est aussi
bien sûr son gros avantage...
Python au contraire est plutôt rigide...
--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.
Le Wed, 31 Aug 2005 11:31:45 +0000, Étienne Labaume a écrit :
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
Perl n'est pas illisible, mais il permet de faire du code illisible si on le souhaite. Le défaut de perl c'est la liberté absolue. C'est aussi bien sûr son gros avantage... Python au contraire est plutôt rigide...
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Pascal Bourguignon
Étienne Labaume writes:
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Étienne Labaume <etienne.lab@wanadoo.fr> writes:
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour
moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et
l'autre de ces langages.
Tant qu'à être débutant, écrit des scripts en Common Lisp.
clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en
suis satisfait.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Il vaut mieux utiliser le langage que connaissez le mieux (perl pour moi). Si vous voulez nourrir le troll, envisagez aussi ruby.
Ahem, ... j'ai oublié de préciser que je suis débutant dans l'un et l'autre de ces langages.
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Benoit Izac
Bonjour,
le 31/08/2005 à 11:22, Étienne Labaume a écrit dans le message <431576d6$0$25402$ :
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 ...
Personnellement, j'ai choisis Perl car : - il est diponible pour beaucoup d'OS ; - la documentation est fournie avec le langage (perldoc) ; - la documentation, sur le Net et en librairie, est abondante ; - il couvre beaucoup de domaines (on peut quasiment tout faire avec) ; - on peut faire quelque chose de relativement intéressant dès le début de son apprentissage (grace notamment au nombre impressionnant de modules disponibes) ; - il est parfaitement lisible si l'on veut s'en donner la peine.
-- Benoit Izac
Bonjour,
le 31/08/2005 à 11:22, Étienne Labaume a écrit
dans le message <431576d6$0$25402$626a14ce@news.free.fr> :
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 ...
Personnellement, j'ai choisis Perl car :
- il est diponible pour beaucoup d'OS ;
- la documentation est fournie avec le langage (perldoc) ;
- la documentation, sur le Net et en librairie, est abondante ;
- il couvre beaucoup de domaines (on peut quasiment tout faire
avec) ;
- on peut faire quelque chose de relativement intéressant dès le
début de son apprentissage (grace notamment au nombre impressionnant
de modules disponibes) ;
- il est parfaitement lisible si l'on veut s'en donner la peine.
le 31/08/2005 à 11:22, Étienne Labaume a écrit dans le message <431576d6$0$25402$ :
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 ...
Personnellement, j'ai choisis Perl car : - il est diponible pour beaucoup d'OS ; - la documentation est fournie avec le langage (perldoc) ; - la documentation, sur le Net et en librairie, est abondante ; - il couvre beaucoup de domaines (on peut quasiment tout faire avec) ; - on peut faire quelque chose de relativement intéressant dès le début de son apprentissage (grace notamment au nombre impressionnant de modules disponibes) ; - il est parfaitement lisible si l'on veut s'en donner la peine.
-- Benoit Izac
Christophe Gaubert
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes scripts ?
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé par Emacs ?
Merci d'avance pour ton avis :)
christophe
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
Tant qu'à être débutant, écrit des scripts en Common Lisp.
clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en
suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes
scripts ?
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé
par Emacs ?
Merci d'avance pour ton avis :)
christophe
--
Christophe Gaubert
http://perso.wanadoo.fr/christophe.gaubert
Mail posté depuis un système libre GNU/Linux
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes scripts ?
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé par Emacs ?
Merci d'avance pour ton avis :)
christophe
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
Jack Crow
je vote Perl aussi simple, puissant, disponible, efficace
un vrai langage, fait pour faire ce qui doit etre fait écrit par un linguiste et non pas par un barbu
disponible partout
beaucoup de doc (les bouquins OReilly sont excellents d'ailleurs)
bonne chance
Bonjour,
le 31/08/2005 à 11:22, Étienne Labaume a écrit dans le message <431576d6$0$25402$ :
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 ...
Personnellement, j'ai choisis Perl car : - il est diponible pour beaucoup d'OS ; - la documentation est fournie avec le langage (perldoc) ; - la documentation, sur le Net et en librairie, est abondante ; - il couvre beaucoup de domaines (on peut quasiment tout faire avec) ; - on peut faire quelque chose de relativement intéressant dès le début de son apprentissage (grace notamment au nombre impressionnant de modules disponibes) ; - il est parfaitement lisible si l'on veut s'en donner la peine.
je vote Perl aussi
simple, puissant, disponible, efficace
un vrai langage, fait pour faire ce qui doit etre fait
écrit par un linguiste et non pas par un barbu
disponible partout
beaucoup de doc (les bouquins OReilly sont excellents d'ailleurs)
bonne chance
Bonjour,
le 31/08/2005 à 11:22, Étienne Labaume a écrit
dans le message <431576d6$0$25402$626a14ce@news.free.fr> :
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 ...
Personnellement, j'ai choisis Perl car :
- il est diponible pour beaucoup d'OS ;
- la documentation est fournie avec le langage (perldoc) ;
- la documentation, sur le Net et en librairie, est abondante ;
- il couvre beaucoup de domaines (on peut quasiment tout faire
avec) ;
- on peut faire quelque chose de relativement intéressant dès le
début de son apprentissage (grace notamment au nombre impressionnant
de modules disponibes) ;
- il est parfaitement lisible si l'on veut s'en donner la peine.
je vote Perl aussi simple, puissant, disponible, efficace
un vrai langage, fait pour faire ce qui doit etre fait écrit par un linguiste et non pas par un barbu
disponible partout
beaucoup de doc (les bouquins OReilly sont excellents d'ailleurs)
bonne chance
Bonjour,
le 31/08/2005 à 11:22, Étienne Labaume a écrit dans le message <431576d6$0$25402$ :
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 ...
Personnellement, j'ai choisis Perl car : - il est diponible pour beaucoup d'OS ; - la documentation est fournie avec le langage (perldoc) ; - la documentation, sur le Net et en librairie, est abondante ; - il couvre beaucoup de domaines (on peut quasiment tout faire avec) ; - on peut faire quelque chose de relativement intéressant dès le début de son apprentissage (grace notamment au nombre impressionnant de modules disponibes) ; - il est parfaitement lisible si l'on veut s'en donner la peine.
Pascal Bourguignon
Christophe Gaubert writes:
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts. Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes scripts ?
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé par Emacs ?
Non. emacs lisp est plus "vieillot" que Common Lisp. http://cliki.net/
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.
En plus, pour rigoler, il y a quelques années j'avais comparé les vitesses de démarrage de perl, clisp, scsh et emacs -batch, et perl était le plus lent...
-- __Pascal Bourguignon__ http://www.informatimago.com/ Wanna go outside. Oh, no! Help! I got outside! Let me back inside!
Tant qu'à être débutant, écrit des scripts en Common Lisp.
clisp est assez bien adapté pour écrire des scripts.
Depuis quelques années, j'écris tous mes scripts en clisp, et j'en
suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes
scripts ?
C'est un vrai langage de programmation, ainsi je n'ai aucun problème,
aucune limitation venant du langage.
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé
par Emacs ?
Non. emacs lisp est plus "vieillot" que Common Lisp.
http://cliki.net/
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.
En plus, pour rigoler, il y a quelques années j'avais comparé les
vitesses de démarrage de perl, clisp, scsh et emacs -batch, et perl
était le plus lent...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Tant qu'à être débutant, écrit des scripts en Common Lisp. clisp est assez bien adapté pour écrire des scripts. Depuis quelques années, j'écris tous mes scripts en clisp, et j'en suis satisfait.
Quels sont les avantages que tu trouves à Common Lisp pour écrire tes scripts ?
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Question subsidiaire : est-ce que c'est le même lisp que celui utilisé par Emacs ?
Non. emacs lisp est plus "vieillot" que Common Lisp. http://cliki.net/
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.
En plus, pour rigoler, il y a quelques années j'avais comparé les vitesses de démarrage de perl, clisp, scsh et emacs -batch, et perl était le plus lent...
-- __Pascal Bourguignon__ http://www.informatimago.com/ Wanna go outside. Oh, no! Help! I got outside! Let me back inside!
Christophe Gaubert
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 ? 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.
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
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 ? 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.
--
Christophe Gaubert
http://perso.wanadoo.fr/christophe.gaubert
Mail posté depuis un système libre GNU/Linux
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 ? 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.
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
