Quel langage pour ...

Le Sun, 04 Sep 2005 16:54:14 +0200, drkm a écrit :

Je suis d'accord. Je n'écris moi-même jamais de Perl sans 'use
strict'. Mais je ne suis pas d'accord avec le fait de dire que
ces libertés que laisse Perl facilitent son apprentissage.

Elles le rendent plus difficile à maîtriser. Mais c'est pareil pour Lisp
(et à mon avis pour la plupart des langages qui valent vraiment la peine
d'être maîtrisé : Lisp, C, Perl...)

--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.

Le 04-09-2005, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit:

Je ne remets aucunement en doute la qualité de common lisp, mais je
pense que l'investissement à faire pour en tirer parti, n'est pas
justifié dans le contexte de l'OP.

Bof, le contexte est très vague et l'OP cherche un nouveau
langage à apprendre, d'après ce que j'ai compris.

Je ne crois pas qu'il cherche à apprendre. Il veut un vrai langage car
ces scripts sont difficiles à maintenir, faire évoluer.

Exact.

L'apprentissage est la conséquence de cette volonté de changer de
langage. Autant que cet apprentissage ne prenne pas plus de temps que
ce que lui apporte le langage.

Après avoir lu ce thread, j'envisage la possibilité de commencer à
écrire mes scripts en Perl _et_ en Python, et de choisir celui qui me
plaira le plus après quelques centaines de lignes.

Je ne dis pas que l'un est mieux que les autres pour l'OP, ça je n'en
sais rien, mais a priori CL est une alternative possible.

Mais coûteuse si on en a pas l'usage.

Désolé pour les afficionados de CL, mais si quelqu'un doit maintenir les
scripts que j'aurais pondu une fois qu'ils ne m'intéressent plus, je
préfère un langage "populaire".

--
Étienne

Le 04-09-2005, drkm <usenet@fgeorges.org> a écrit:

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) ;
[...]

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

Ben, c'est déjà ce que je fais avec le shell, et dans mes scripts, c'est
souvent sur les appels aux exécutables que les problèmes interviennent.
Avoir la possibilité avec un langage de script d'effectuer directement
un traîtement à base d'expression régulière (sans appeler sed et awk, je
veux dire), pouvoir intégrer un client HTTP/FTP, ou travailler avec une
librairie de décompression des archives, c'est ce qui m'intéresse. S'il
faut appeler des exécutables, je garde le shell, ce sera aussi simple.
Ou plutôt, ce ne sera pas moins compliqué.

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

Si j'ai le choix,_ toutes choses égales par ailleurs_, je préfère me
baser sur un langage qui est aussi disponible sous Win. Mais
visiblement, CL l'est. On peut donc couper cette branche du troll.

--
Étienne

Le Mon, 05 Sep 2005 09:34:13 +0000, Étienne Labaume a écrit :

Après avoir lu ce thread, j'envisage la possibilité de commencer à
écrire mes scripts en Perl _et_ en Python, et de choisir celui qui me
plaira le plus après quelques centaines de lignes.

Ca me parait tres raisonnable. Un point peut etre a considerer : Perl est
installe en standard sur toutes les machines Unix de moins de 10 ans, pas
python.

--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.

Le 05-09-2005, Emmanuel Florac <eflorac@imaginet.fr> a écrit:

Après avoir lu ce thread, j'envisage la possibilité de commencer à
écrire mes scripts en Perl _et_ en Python, et de choisir celui qui me
plaira le plus après quelques centaines de lignes.

Ca me parait tres raisonnable. Un point peut etre a considerer : Perl est
installe en standard sur toutes les machines Unix de moins de 10 ans, pas
python.

Moui ... faut voir comment, aussi ... J'ai eu un jour un problème sur
une machine sous Solaris, où un script Perl ne fonctionnait pas parce
que la version de Perl installée par défaut n'admettait pas le
chargement de modules ou quelque chose du même tonneau (je rapporte ça
de mémoire, ça a plus d'un an). Bon, maintenant, je ne dis pas qu'elle
était bien administrée, hein ... Mais ça s'oppose à ton argument, je
pense.

--
Étienne

Benoit Izac writes:

le 04/09/2005 à 16:51, drkm a écrit
dans le message <uirxg9988.fsf_-_@fgeorges.org> :

entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la
seconde expression est quand même plus naturelle

Oui, on y voit plus clairement qu'il faut diviser par 6 le
résultat de l'affectation à '$foo' de la réponse universelle.

-- c'est celle qu'on
enseigne à l'école.

Personnellement, on ne m'a jamais enseigné le concept d'affectation
à l'école (mmh, si, mais après le bac). On m'y a par contre appris la
NPI.

Heu... c'est de la mauvaise foi ou tu n'es pas passé par le collège ?

Si, et j'y ai même écouté ce qui s'y disait. Et je n'y ai
jamais entendu parler d'affectation, que tu le veuilles ou non.

« y = 2 * x », tu n'as jamais vu ça ? Et ton professeur t'a dit : on
affecte « 2 » à « y » et on multiplie par « x » ?

Je le répète, il ne m'a jamais parlé d'affectation. J'ai bien
vu ce qu'était une équation, par contre. Mais cela est
différent. Car ta syntaxe naturelle, elle ne me fait pas penser
à une affectation alors (si j'oublie ce que j'ai appris depuis le
bac), mais à une équation.

Il est donc « naturel » de voir ci-dessus une équation. Mais
si ce n'est pas le cas, si l'opérateur « = » n'a en fin de compte
rien a voir avec les équations, mais est quelque chose de
totalement différent, en quoi la priorité de ce nouvel opérateur
inconnu est-elle alors « naturelle » ?

Mais je suppose que tout cela est tout de même plus naturel
qu'avec une notation préfixe ou postfixe. Ahem.

Là ça devient n'importe quoi...

En effet.

--drkm

Xavier Gachon writes:

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

rien une fois que l'on a appris le nouveau langage et l'eventuelle
nouvelle syntaxe, il y avait un contexte a ces propos.

Je le sais. C'est bien pour cela que je l'avais laissé.
Pourquoi l'as-tu coupé, pour ensuite te plaindre qu'il n'y est
plus ?

Nous parlons
d'un langage qui n'existe pas mais serait implementer en Lisp, sa
lisibilité reste donc une inconnue

Non, tu laissais entendre que la lisibilité d'un « langage
implémenté en CL et que personne ne connaît à part toi » serait
mauvaise, a priori.

[reutilisation]

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

par ce que perl et python sont des langages a implementations quasi
uniques, ce n'est pas le cas de CL et encore moins des Lisp en general.

Si tu veux te limiter à une seule implémentation, tu peux le
faire en CL également. Tu peux même livrer un zoli exécutable
tout beau tout propret. Je ne vois donc pas où est le problème.

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

la necessité de travailler principalement a partir d'un lisp
system sur ce lisp system sous peine de perdre un temps qui
deviendra d'autant plus deraisonnable que le lisp system
en question va gonfler et qu'on l'on y fera appel que
ponctuellement.

Je ne comprend pas. Peux-tu reformuler, stp ?

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.

Je ne connais presque aucun admin sachant reellement ce qu'il
fait lorsqu'il utilise perl, c'est bien là le probleme, on prend
un bout de code ici, un autre là, on colle les morceaux comme
on peux, si ca fonctionne on garde si ca ne fonctionne pas on
essaye autre chose (d'un autre coté ca me permet aussi de gagner
ma croute, au moins en partie, meme si je ne pratique pas perl :)

Ah, bien sûr, si l'on parle de programmer sans savoir
programmer, ben le langage n'est que de peu d'intérêt. Beaucoup
de personnes font cela aussi avec Emacs Lisp, et y arrivent plus
ou moins bien également, par « copier/coller de bouts de code ».

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.

Les bibliotheques sont nombreuses et facile a integrer, le langage
lui meme integre deja bon nombre des fonctionnalités de base
qu'attend un admin et il est globalement peut contraignant ou
tout au moins correspond bien aux habitudes et connaissances en
programmation des personnes qui l'utilises ou se tourne vers lui,
et ce syntaxiquement comme semantiquement.

Mais qu'est-ce concrètement ces « fonctionnalités de base
qu'attend un admin » qu'intègre le langage ? En quoi est-il
« peu contraignant ou correspond-il aux habitudes et
connaissances en programmation des personnes qui l'utilises » ?

BTW, je ne vois toujours pas d'où tu tires cela de « les
soi-disant "libertées" qu'offre Perl facilitent son apprentissage
donc ... ».

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

[...] Pour des admins devant apprendre un langage pour scripter
l'on pourrait le comparer, par analogie, a un scheme+srfi vis a
vis de CL

Tu parles des « Requests for Implementation » ? Si c'est le
cas, j'ai du mal à suivre l'analogie.

--drkm

Étienne Labaume writes:

Le 04-09-2005, drkm <usenet@fgeorges.org> a écrit:

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

Ben, c'est déjà ce que je fais avec le shell, et dans mes scripts, c'est
souvent sur les appels aux exécutables que les problèmes interviennent.
Avoir la possibilité avec un langage de script d'effectuer directement
un traîtement à base d'expression régulière (sans appeler sed et awk, je
veux dire), pouvoir intégrer un client HTTP/FTP, ou travailler avec une
librairie de décompression des archives, c'est ce qui m'intéresse. S'il
faut appeler des exécutables, je garde le shell, ce sera aussi simple.
Ou plutôt, ce ne sera pas moins compliqué.

Mmh, dans le cas de FTP, je ne vois pas vraiment l'intérêt,
mais il doit bien exister une bibliothèque. Sinon, si tu restes
en shell, Zsh contient un tel module ftp.

--drkm

Le Mon, 05 Sep 2005 14:45:17 +0000, Étienne Labaume a écrit :

Bon, maintenant, je ne dis pas qu'elle
était bien administrée, hein ... Mais ça s'oppose à ton argument, je
pense.

Non, les unix proprios ont souvent un Perl antédiluvien installé (genre
perl 5.005). Il suffit de le savoir et d'en tenir compte au départ, si on
souhaite la portabilité maximale.

--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.

Le 05-09-2005, drkm <usenet@fgeorges.org> a écrit :

Je le sais. C'est bien pour cela que je l'avais laissé. Pourquoi
l'as-tu coupé, pour ensuite te plaindre qu'il n'y est plus ?

Par ce que le passage laissé etait insuffisant a exprimer le
contexte en question amha (raison pour laquelle je l'ai
a nouveau precisé dans ma reponse :)

Non, tu laissais entendre que la lisibilité d'un « langage
implémenté en CL et que personne ne connaît à part toi » serait
mauvaise, a priori.

oui, la lisibilité d'un langage qu'on ne connais pas n'est
jamais evidente a prioris, mais qu'est ce que la lisibilité
d'un langage informatique independement de la culture
informatique de celui qui l'apprend... la question reste
entiere :)

[reutilisation]
Si tu veux te limiter à une seule implémentation, tu peux le

faire en CL également. Tu peux même livrer un zoli exécutable
tout beau tout propret. Je ne vois donc pas où est le problème.

cette implementation devras donc fonctionner sur toutes les
platformes ciblée... mais la on rentre dans un autre debat qui
n'existe pas en perl ou python puisque la portabilité y est lié
a leurs uniques implementations.

Je ne comprend pas. Peux-tu reformuler, stp ?

tu as deja utilisé CL, tu sais (puisque tu en parle ci-dessus)
que les premieres demandes de debutants passe par comment generer
un executable ou script independant, et qui si l'on parle
generalement de lisp systems et non de simples implés c'est
justement par ce que ce n'est pas le mode de travail habituel
dans ce langage malgré ces possibilités.

Ah, bien sûr, si l'on parle de programmer sans savoir
programmer, ben le langage n'est que de peu d'intérêt.

Il y a de nombreuses nuances de gris egalement :)

Mais qu'est-ce concrètement ces « fonctionnalités de base
qu'attend un admin » qu'intègre le langage ? En quoi est-il
« peu contraignant ou correspond-il aux habitudes et
connaissances en programmation des personnes qui l'utilises » ?

je pourrais aussi ecrire un pavé sur toutes les difference entre
perl et lisp et le temps passé par les futurs admins a etudier
certaines categories de langages, pense tu que ce soit l'endroit,
moi pas et je n'en ais ni l'envie ni le temps :)

la syntaxe a deja fait parler d'elle, un admin est habitué au shell,
a sed, a awk, et autres outils systemes que perl se voulait a l'origine
remplacer. adopter CL ou autre Lisp pour remplacer/aller au dela de ces
outils implique pour la pluspart des admins un effort qui n'est pas
comparable a l'adoption de perl, c'est un avis, et je ne doute pas
que des exceptions confirme la regle, j'en suis. chercher des raisons
techniques a un probleme culturel ne t'aideras pas a comprendre.

BTW, je ne vois toujours pas d'où tu tires cela de « les
soi-disant "libertées" qu'offre Perl facilitent son apprentissage
donc ... ».

presente perl a quelqu'un n'en ayant jamais entendu parlé mais
ayant deja utilisé un ou plusieurs langages mainstream puis
demande lui d'essayer d'en tirer quelque chose, par essais,
echec, modif, essais, ... succes (relatif :) comme le fait
n'importe qui en phase d'apprentissage que ce soit sur une
repl ou pas, fait la meme chose avec un lisp quelconque,
je te laisse envisager/constater le resultat.

Tu parles des « Requests for Implementation » ?

oui.

Si c'est le cas, j'ai du mal à suivre l'analogie.

je comparais python a perl dans le cadre de l'apprentissage du
langage, enleve "+srfi" et reessais (mais ne vient pas me dire
ensuite que ce n'est pas comparable du fait du depouillement
voulu du core scheme comparé a python :).

xavier.