Quel langage pour ...

Emmanuel Florac <eflorac@imaginet.fr> writes:

C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple

perl -pi bak -e "s/toto/titi/g" monfichier.txt

Avec des raccourcis prévus pour, en lisp c'est plus court:

clisp -x '(s"toto""titi""monfichier.txt")'


--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay

Le Sat, 03 Sep 2005 13:48:37 +0200, Pascal Bourguignon a écrit :

Avec des raccourcis prévus pour, en lisp c'est plus court:

clisp -x '(s"toto""titi""monfichier.txt")'

Et est-ce que ça fait une copie de backup avec extension .bak? Quoi qu'il
en soit, le point important est : mieux vaut utiliser un langage évolué
(lisp, perl, python, ruby peu importe) que shell.
Le choix du langage après c'est 1) le goût 2) le besoin de
portabilité/disponibilité/etc 3) le besoin d'outils pour faire X ou Y,
etc.

--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.

Emmanuel Florac <eflorac@imaginet.fr> writes:

Le Sat, 03 Sep 2005 13:48:37 +0200, Pascal Bourguignon a écrit :

Avec des raccourcis prévus pour, en lisp c'est plus court:

clisp -x '(s"toto""titi""monfichier.txt")'

Et est-ce que ça fait une copie de backup avec extension .bak?

Oui bien sur, tout ce que tu veux. Ça peut même faire la sauvegarde
sur un site déporté, et te préparer un café.

Quoi qu'il
en soit, le point important est : mieux vaut utiliser un langage évolué
(lisp, perl, python, ruby peu importe) que shell.
Le choix du langage après c'est 1) le goût 2) le besoin de
portabilité/disponibilité/etc 3) le besoin d'outils pour faire X ou Y,
etc.

C'est tout l'intérêt: avec un langage de haut niveau on peut
abstraire, et raccourcir autant qu'on veut.


--
__Pascal Bourguignon__ http://www.informatimago.com/

In a World without Walls and Fences,
who needs Windows and Gates?

On Fri, 02 Sep 2005 10:51:33 +0000, Étienne Labaume wrote:

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.

Question peut-être triviale: Selon vous, quelles sont ces règles ? Vous
avez des pointeurs ?

D'une manière générale, elle est présente sur le site officiel du
langage. Par exemple, pour Python:

http://www.python.org/peps/pep-0008.html

Pour le C, je cherche encore...


--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

R12y writes:

On Fri, 02 Sep 2005 10:51:33 +0000, Étienne Labaume wrote:

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.

Question peut-être triviale: Selon vous, quelles sont ces règles ? Vous
avez des pointeurs ?

D'une manière générale, elle est présente sur le site officiel du
langage. Par exemple, pour Python:

http://www.python.org/peps/pep-0008.html

Pour le C, je cherche encore...

Il y en a beaucoup pourtant, il me semble. Ne serait-ce que
celles de GNU et celles du noyau Linux. Ce n'est pas
spécialement des styles que j'affectionne. Mais tu trouveras
plus d'infos sur f.c.l.c.

--drkm

Le 03-09-2005, Pascal Bourguignon <spam@mouse-potato.com> a écrit :

Emmanuel Florac <eflorac@imaginet.fr> writes:

C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple
perl -pi bak -e "s/toto/titi/g" monfichier.txt
Avec des raccourcis prévus pour, en lisp c'est plus court:

clisp -x '(s"toto""titi""monfichier.txt")'

user@doriel:~$ echo toto > monfichier.txt
user@doriel:~$ clisp -x '(s "toto" "titi" "monfichier.txt")' > /dev/null 2>&1
user@doriel:~$ cat monfichier.txt
toto

A ben mince ca marche pas %)

Je suis moi aussi adepte des Lisp et scheme en particulier, mais je
trouve ton argumentation proselite un peu osée. Il est relativement
evident que les Lisp sont des platformes de predilection pour
implementer des "Domain Specific Langages" et que cela les rends
tout aussi efficace et pratique que perl ou n'importe quel autre
langage pour les taches d'administration mais pas sans certaines
contraintes dont tu sembles faire abstraction.

Il etait precedemment question de la lisibilité de perl, que dire de
celle d'un langage implementé en CL que personne ne connait a par
toi (remarque que je ne parle pas de syntaxe, scsh est plus qu'un
scheme), De la reutilisation des scripts en question sur de multiples
platformes (sans doute la raison pour laquelle tu as choisi de baser
ton exemple sur clisp ;). Quelles seront les facilités d'integrations
des scripts realisés dans ce langage aux environnements dans lesquels
ils devront s'executer (sans oublier que recharger une image lisp pour
executer quelques "commandes/taches" ici ou là n'est pas sans
consequence). Quid de la disponibilité de bibliotheques repondant plus
ou moins directement aux taches les plus souvent rencontrées par les
administrateurs system & resal qui, faut'il le rappeler, ne sont pas
programmeurs de profession.

Tu parlais egalement de manageurs, peut etre ne sont'il pas aussi
obtus que tu sembles vouloir le sous-entendre. Si un langage de
programmation quel qu'il soit permet a _un_ et _un_seul_ programmeur
d'abattre le travail de 100 autres, mais que tu as besoin de former
100 programmeurs comme celui-ci, le choix d'un langage de programmation
un peu moins miraculeux mais relativement plus connus n'est pas la
pire des solutions. Surtout si le langage miraculeux s'avere
soudainement beaucoup moins productif lorsqu'il sagit de faire
bosser une equipe de 100 personnes sur un seul projet (ahhh le
facteur "humain"... ;). L'expressivité pour "communiquer" avec des
machines c'est bien, pour communiquer egalement avec des humains,
c'est mieux.

J'ai beau avoir largement devellopé une haine viscerale pour perl,
je n'en pense pas moins qu'il sera naturellement plus adapté qu'un
quelconque Lisp pour des taches d'administration pour la simple
raison que les soi-disant "libertées" qu'il offre faciliteront
son apprentissage et qu'il repondra ainsi plus directement aux
besoins qui nous occupent dans le post original. Python fournis
egalement un cadre qui dans ce contexte ne peut etre qu'un avantage.

Malgré tout cela je continuerais moi aussi a faire de plus en plus
de taches d'admin avec des Lisp-like, mais je ne bosse que pour moi,
et finalement, de ce point de vue là, les Lisp sont sans doute
culturellement des langages incontournables pour qui pretend
"savoir/apprendre a" programmer :)

mon centime, xavier.

--
"The angle brackets cause my eyes to burn
First left, then right they want my head to turn
In verbose pairs of tags my data rest
Yet I still think parentheses the best".

Pour le C, je cherche encore...
ftp.laas.fr/pub/ii/matthieu/c-superflu/c-superflu.pdf

--
Thomas Baruchel

On Fri, 02 Sep 2005 10:51:33 +0000, Étienne Labaume wrote:

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.

Question peut-être triviale: Selon vous, quelles sont ces règles ? Vous
avez des pointeurs ?

D'une manière générale, elle est présente sur le site officiel du
langage. Par exemple, pour Python:

http://www.python.org/peps/pep-0008.html

Pour le C, je cherche encore...

Facile: rtff (celle-là est d'ailleurs un modèle du genre)
http://www.isty-info.uvsq.fr/~rumeau/fclc/fclc0015.html

;-)

Xavier Gachon <xavier@shagshag.frmug.org> writes:

Le 03-09-2005, Pascal Bourguignon <spam@mouse-potato.com> a écrit :

Emmanuel Florac <eflorac@imaginet.fr> writes:

C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple
perl -pi bak -e "s/toto/titi/g" monfichier.txt
Avec des raccourcis prévus pour, en lisp c'est plus court:

clisp -x '(s"toto""titi""monfichier.txt")'

user@doriel:~$ echo toto > monfichier.txt
user@doriel:~$ clisp -x '(s "toto" "titi" "monfichier.txt")' > /dev/null 2>&1
user@doriel:~$ cat monfichier.txt
toto

A ben mince ca marche pas %)

Oui, il te manque la bibliothèque qui va bien :-)

Je suis moi aussi adepte des Lisp et scheme en particulier, mais je
trouve ton argumentation proselite un peu osée. Il est relativement
evident que les Lisp sont des platformes de predilection pour
implementer des "Domain Specific Langages" et que cela les rends
tout aussi efficace et pratique que perl ou n'importe quel autre
langage pour les taches d'administration mais pas sans certaines
contraintes dont tu sembles faire abstraction.

Il etait precedemment question de la lisibilité de perl, que dire de
celle d'un langage implementé en CL que personne ne connait a par
toi (remarque que je ne parle pas de syntaxe, scsh est plus qu'un
scheme), De la reutilisation des scripts en question sur de multiples
platformes (sans doute la raison pour laquelle tu as choisi de baser
ton exemple sur clisp ;).

Quelles seront les facilités d'integrations
des scripts realisés dans ce langage aux environnements dans lesquels
ils devront s'executer

Common Lisp a été conçu pour fonctionner dans des environnements
beaucoup plus divers que les outils unix où à la limite POSIX...

(sans oublier que recharger une image lisp pour
executer quelques "commandes/taches" ici ou là n'est pas sans
consequence).

Ceci est un non-problème: il est résolu de la même manière pour les
autres languages, avec des bibliothèques partagées et avec des textes
collants et autres caches.

Ceci dit, il y a une paire d'année j'avais fais un benchmark et le
plus lent à charger et exécuter un script vide était perl, le plus
rapide clisp, avec emacs au millieu, proche de clisp. Ce qui n'est pas
significatif pour un script normal, mais c'est pour dire...

Quid de la disponibilité de bibliotheques repondant plus
ou moins directement aux taches les plus souvent rencontrées par les
administrateurs system & resal

Les bibliothèques se construisent en fonction des besoins, ce sont les
administrateurs-programmeurs qui les écriront. Il faut effectivement
former une boule de neige. perl a déjà sa grosse boule de neige, mais
c'est de la neige sale et boueuse, pleine de gravillon et de pics de
glaces. Je propose de faire une nouvelle boule de neige bien blanche
et bien jolie, en Common Lisp.

Je te dirais un mots des bibliothèques. J'avais une belle
bibliothèque de 30+ modules que j'avais écris en Modula-2, de jolis
modules bien réutilisable dont j'étais fier. L'autre jour je me suis
dis tiens, je vais les traduire en lisp, puisqu'ils sont si utiles mes
beaux modules... Quand j'ai eu fini de les traduire en lisp, il ne
m'en restait plus que deux sur les trente, les autres étaient
totalement inutiles en lisp et ne servaient qu'à palier les
déficiences du langage original.

Ce n'est pas un exemple isolé: d'une manière générale la taille d'un
programme écrit en lisp est 10 à 20 fois moindre qu'un programme
équivalent dans un autre language.

Voir aussi: http://norvig.com/design-patterns/
http://norvig.com/design-patterns/img010.htm

qui, faut'il le rappeler, ne sont pas
programmeurs de profession.

Raison de plus pour ne pas leur mettre entre les mains un langage de
programmation comme perl... Voir http://www.gnu.org/gnu/rms-lisp.html
comment lisp peut être utilisée par des secrétaires non-programmeuses
tant qu'on ne leur dit pas que c'est de la programmation qu'elles font...

Tu parlais egalement de manageurs, peut etre ne sont'il pas aussi
obtus que tu sembles vouloir le sous-entendre. Si un langage de
programmation quel qu'il soit permet a _un_ et _un_seul_ programmeur
d'abattre le travail de 100 autres, mais que tu as besoin de former
100 programmeurs comme celui-ci, le choix d'un langage de programmation
un peu moins miraculeux mais relativement plus connus n'est pas la
pire des solutions. Surtout si le langage miraculeux s'avere
soudainement beaucoup moins productif lorsqu'il sagit de faire
bosser une equipe de 100 personnes sur un seul projet (ahhh le
facteur "humain"... ;). L'expressivité pour "communiquer" avec des
machines c'est bien, pour communiquer egalement avec des humains,
c'est mieux.

Merci pour abonder dans mon sens.
Google: perl+"line noise" donne 13600 hits
lisp+"line noise" donne 4810 hits
lisp+"line noise"-perl donne 707 hits
Sujet largement débatu au conclusions connues...

J'ai beau avoir largement devellopé une haine viscerale pour perl,
je n'en pense pas moins qu'il sera naturellement plus adapté qu'un
quelconque Lisp pour des taches d'administration pour la simple
raison que les soi-disant "libertées" qu'il offre faciliteront
son apprentissage et qu'il repondra ainsi plus directement aux
besoins qui nous occupent dans le post original. Python fournis
egalement un cadre qui dans ce contexte ne peut etre qu'un avantage.

Malgré tout cela je continuerais moi aussi a faire de plus en plus
de taches d'admin avec des Lisp-like, mais je ne bosse que pour moi,
et finalement, de ce point de vue là, les Lisp sont sans doute
culturellement des langages incontournables pour qui pretend
"savoir/apprendre a" programmer :)

Continuons à programmer en lisp pour nos besoins personnels; on
arrivera finalement à produire une bibliothèques trés utile pour les
administrateurs "professionnels" :-)

--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner

Xavier Gachon writes:

Il etait precedemment question de la lisibilité de perl, que dire de
celle d'un langage implementé en CL que personne ne connait a par
toi

Qu'est-ce ça change à la lisibilité intrinsèque du code ?

De la reutilisation des scripts en question sur de multiples
platformes

Je ne vois pas le problème. Du moins pas plus qu'avec Perl ou
Python.

Quelles seront les facilités d'integrations
des scripts realisés dans ce langage aux environnements dans lesquels
ils devront s'executer

Là, je n'ai pas assez d'expérience pour répondre. Mais il
existe au moins le moyen de s'interfacer avec les systèmes POSIX
(ce qui fait déjà pas mal de monde).

(sans oublier que recharger une image lisp pour
executer quelques "commandes/taches" ici ou là n'est pas sans
consequence).

Quelles conséquences ?

Quid de la disponibilité de bibliotheques repondant plus
ou moins directement aux taches les plus souvent rencontrées par les
administrateurs system & resal qui, faut'il le rappeler, ne sont pas
programmeurs de profession.

L'offre en bibliothèques est sans doute le désavantage de CL
par rapport à Perl ou Python, ÀMHA. Bien que la situation est en
train d'évoluer, je pense. Voir plus bas.

J'ai beau avoir largement devellopé une haine viscerale pour perl,
je n'en pense pas moins qu'il sera naturellement plus adapté qu'un
quelconque Lisp pour des taches d'administration pour la simple
raison que les soi-disant "libertées" qu'il offre faciliteront
son apprentissage

Je n'ai jamais nourri de haine envers Perl, mais je pense au
contraire que ces libertés nuisent à son apprentissage. Elles
sont intéressantes après, lorsque l'on sait ce que l'on fait,
ÀMHA.

et qu'il repondra ainsi plus directement aux
besoins qui nous occupent dans le post original.

Je ne vois pas la relation entre ce que tu viens de dire et
cette affirmation. Pour ce qui est de l'article initial, pour en
revenir aux bibliothèques, voici ce qui est demandé :

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) ...

Je comprend donc que le PO, qui de son propre aveux ne connaît
pas encore Perl ni Python, cherche un langage adapté à ses
besoins. Pour les cinq points de la liste ci-dessus :

- gzip : appel de l'exécutable, ou utilisation d'une
bibliothèque (ça doit exister, ou on peut utiliser la zlib
C) ;

- CL me semble tout adapté pour ce genre de choses ;

- ftp : ici aussi, appel de l'exécutable. Je ne vois pas
l'intérêt de faire autrement ;

- création de scripts : encore une fois, CL me semble tout
adapté. Maintenant, pourquoi ? Mmh, sans doute une
certaine sensibilité. Mais à voir des bibliothèques comme
TAL, générant de l'HTML, c'est vraiment très intuitif et
très lisible, et l'adaptation à des instructions SQL
devrait l'être tout autant, si ça n'existe pas déjà ;

- HTTP : il existe des outils pour cela.

Pour le paragraphe suivant :

- lire config file : encore une fois, CL me semble adapté
pour parser des fichiers ;

- SQL : il existe des bibliothèques pour cela, de plutôt
bonne facture d'après les retours que j'ai pu voir ;

- sauvegardes : ben CL ou autre, je vois pas trop de
différences ici ;

- non-UNIX : il faut voir ici ce que l'on veut. En s'en
tenant à la norme, il y a déjà moyen de faire énormément de
choses. S'il faut vraiment descendre au niveau du système,
là, je ne sais pas. Mais je pense que si l'on veut à la
fois être portable entre systèmes et entre implémentations
(ce dont on ne doit pas se soucier pour Perl, mais
simplement parce que l'on n'a pas le choix), ça devient
peut-être plus compliqué. Mais si l'on doit descendre au
niveau du système, je ne vois pas d'inconvénient à imposer
un ensemble d'implémentations particulières.

Python fournis
egalement un cadre qui dans ce contexte ne peut etre qu'un avantage.

À quoi penses-tu (je ne connais Python que de très loin) ?

--drkm