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 ...
le 04/09/2005 à 14:09, Pascal Bourguignon a écrit dans le message :
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...
Rappelons que l'OP n'a à aucun moment parlé de performances pour ses applications. Les réponses auraient été différentes.
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...
On peut faire dire ce que l'on veut à google : perl introduction -> 3 200 000 "common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
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.
Comme il a été dit, Perl est plus naturel : pour quelqu'un qui connaît la plupart des outils Unix, la syntaxe est proche voir équivalente ; « sed -ne 's/foo/bar/g' » est équivalent à « perl -ne 's/for/bar/g' ». tu retrouves les blocs BEGIN/END de awk, les boucles de contrôle sont proches du C, les commentaires sont les même qu'en shell. Pour quelqu'un qui a déjà un peu d'expérience sous Unix, l'apprentissage de Perl est rapide. Ce n'est pas le cas du lisp (pour moi en tout cas) : entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la seconde expression est quand même plus naturelle -- c'est celle qu'on enseigne à l'école.
-- Benoit Izac
Bonjour,
le 04/09/2005 à 14:09, Pascal Bourguignon a écrit
dans le message <87k6hxrq45.fsf@thalassa.informatimago.com> :
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...
Rappelons que l'OP n'a à aucun moment parlé de performances pour ses
applications. Les réponses auraient été différentes.
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...
On peut faire dire ce que l'on veut à google :
perl introduction -> 3 200 000
"common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
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.
Comme il a été dit, Perl est plus naturel : pour quelqu'un qui connaît
la plupart des outils Unix, la syntaxe est proche voir équivalente ;
« sed -ne 's/foo/bar/g' » est équivalent à « perl -ne 's/for/bar/g' ».
tu retrouves les blocs BEGIN/END de awk, les boucles de contrôle sont
proches du C, les commentaires sont les même qu'en shell. Pour quelqu'un
qui a déjà un peu d'expérience sous Unix, l'apprentissage de Perl est
rapide. Ce n'est pas le cas du lisp (pour moi en tout cas) :
entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la seconde
expression est quand même plus naturelle -- c'est celle qu'on enseigne à
l'école.
le 04/09/2005 à 14:09, Pascal Bourguignon a écrit dans le message :
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...
Rappelons que l'OP n'a à aucun moment parlé de performances pour ses applications. Les réponses auraient été différentes.
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...
On peut faire dire ce que l'on veut à google : perl introduction -> 3 200 000 "common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
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.
Comme il a été dit, Perl est plus naturel : pour quelqu'un qui connaît la plupart des outils Unix, la syntaxe est proche voir équivalente ; « sed -ne 's/foo/bar/g' » est équivalent à « perl -ne 's/for/bar/g' ». tu retrouves les blocs BEGIN/END de awk, les boucles de contrôle sont proches du C, les commentaires sont les même qu'en shell. Pour quelqu'un qui a déjà un peu d'expérience sous Unix, l'apprentissage de Perl est rapide. Ce n'est pas le cas du lisp (pour moi en tout cas) : entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la seconde expression est quand même plus naturelle -- c'est celle qu'on enseigne à l'école.
-- Benoit Izac
Xavier Gachon
Le 04-09-2005, Pascal Bourguignon a écrit :
Xavier Gachon writes:
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...
Mais il n'a pas ete conçu pour etre utilisé de la façon dont sont utilisés la pluspart de ces environnement aujourd'hui, s'il peut effectivement servir de "shell" central pour interragir avec tout les "composants" cela implique de revoir asser profondement des habitudes de travails qui sont bien ancrées dans les esprits, et l'habitude est un tyran.
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 temps passe, le monde change, les imples dans langages evolues, tout ca...
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.
cela impliquerait de leur part des efforts dans le domaine de la programmation que perl leur permet d'eviter (ce qui est sans doute une des principales cause de son succes, avec les consequences qu'on voudra... :) et pour lequel j'ai bien peur qu'ils n'aient en grande majorité aucune motivation.
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...
il y a tout de meme un monde entre utiliser un DSL implementé _sur_ CL et develloper le meme DSL _en_ CL :)
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.
je ne comparais pas specifiquement lisp et perl.
Sujet largement débatu au conclusions connues...
de meme que celui des grosses equipes bossant sur des projets en CL :)
xavier.
-- "more popular lisps ? but hey, they are good secrets weapons!" Lisp is dead, long live the Lisp!
Le 04-09-2005, Pascal Bourguignon <spam@mouse-potato.com> a écrit :
Xavier Gachon <xavier@shagshag.frmug.org> writes:
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...
Mais il n'a pas ete conçu pour etre utilisé de la façon dont
sont utilisés la pluspart de ces environnement aujourd'hui,
s'il peut effectivement servir de "shell" central pour interragir
avec tout les "composants" cela implique de revoir asser profondement
des habitudes de travails qui sont bien ancrées dans les esprits, et
l'habitude est un tyran.
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 temps passe, le monde change, les imples dans langages evolues,
tout ca...
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.
cela impliquerait de leur part des efforts dans le domaine de la
programmation que perl leur permet d'eviter (ce qui est sans doute
une des principales cause de son succes, avec les consequences qu'on
voudra... :) et pour lequel j'ai bien peur qu'ils n'aient en grande
majorité aucune motivation.
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...
il y a tout de meme un monde entre utiliser un DSL implementé _sur_ CL
et develloper le meme DSL _en_ CL :)
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.
je ne comparais pas specifiquement lisp et perl.
Sujet largement débatu au conclusions connues...
de meme que celui des grosses equipes bossant sur des projets en CL :)
xavier.
--
"more popular lisps ? but hey, they are good secrets weapons!"
Lisp is dead, long live the Lisp!
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...
Mais il n'a pas ete conçu pour etre utilisé de la façon dont sont utilisés la pluspart de ces environnement aujourd'hui, s'il peut effectivement servir de "shell" central pour interragir avec tout les "composants" cela implique de revoir asser profondement des habitudes de travails qui sont bien ancrées dans les esprits, et l'habitude est un tyran.
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 temps passe, le monde change, les imples dans langages evolues, tout ca...
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.
cela impliquerait de leur part des efforts dans le domaine de la programmation que perl leur permet d'eviter (ce qui est sans doute une des principales cause de son succes, avec les consequences qu'on voudra... :) et pour lequel j'ai bien peur qu'ils n'aient en grande majorité aucune motivation.
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...
il y a tout de meme un monde entre utiliser un DSL implementé _sur_ CL et develloper le meme DSL _en_ CL :)
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.
je ne comparais pas specifiquement lisp et perl.
Sujet largement débatu au conclusions connues...
de meme que celui des grosses equipes bossant sur des projets en CL :)
xavier.
-- "more popular lisps ? but hey, they are good secrets weapons!" Lisp is dead, long live the Lisp!
Arnaud Launay
Le Sun, 04 Sep 2005 15:43:55 +0200, Benoit Izac écrivit:
entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la seconde expression est quand même plus naturelle -- c'est celle qu'on enseigne à l'école.
Le Sun, 04 Sep 2005 15:43:55 +0200, Benoit Izac écrivit:
entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que
la seconde expression est quand même plus naturelle -- c'est
celle qu'on enseigne à l'école.
Le Sun, 04 Sep 2005 15:43:55 +0200, Benoit Izac écrivit:
entre « (= foo (/ 42 6)) » et « $foo = 42 / 6; », reconnaît que la seconde expression est quand même plus naturelle -- c'est celle qu'on enseigne à l'école.
Le Sun, 04 Sep 2005 14:09:46 +0200, Pascal Bourguignon a écrit :
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
C'est une tarte à la crème. Il y a aussi beaucoup plus de sites sur perl que sur Lisp, et beaucoup plus de ressources dispos sur Perl que sur Lisp. Perl rulez grave... (Lisp aussi, mais Lisp est beaucoup moins répandu et possède moins de bibliothèques).
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Le Sun, 04 Sep 2005 14:09:46 +0200, Pascal Bourguignon a écrit :
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
C'est une tarte à la crème. Il y a aussi beaucoup plus de sites sur perl
que sur Lisp, et beaucoup plus de ressources dispos sur Perl que sur Lisp.
Perl rulez grave... (Lisp aussi, mais Lisp est beaucoup moins répandu et
possède moins de bibliothèques).
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
Le Sun, 04 Sep 2005 14:09:46 +0200, Pascal Bourguignon a écrit :
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
C'est une tarte à la crème. Il y a aussi beaucoup plus de sites sur perl que sur Lisp, et beaucoup plus de ressources dispos sur Perl que sur Lisp. Perl rulez grave... (Lisp aussi, mais Lisp est beaucoup moins répandu et possède moins de bibliothèques).
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Emmanuel Florac
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais tout le monde recommande d'utiliser #!/usr/bin/perl use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au
contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais
tout le monde recommande d'utiliser
#!/usr/bin/perl
use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais tout le monde recommande d'utiliser #!/usr/bin/perl use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
drkm
Benoit Izac writes:
On peut faire dire ce que l'on veut à google : perl introduction -> 3 200 000 "common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
Heu, 115.000 pages ne te suffisent pas ?
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 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.
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.
--drkm
Benoit Izac writes:
On peut faire dire ce que l'on veut à google :
perl introduction -> 3 200 000
"common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
Heu, 115.000 pages ne te suffisent pas ?
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 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.
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.
On peut faire dire ce que l'on veut à google : perl introduction -> 3 200 000 "common lisp" introduction -> 115 000
25 fois moins de documentation disponible pour aborder le langage...
Heu, 115.000 pages ne te suffisent pas ?
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 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.
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.
--drkm
drkm
Emmanuel Florac writes:
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais tout le monde recommande d'utiliser #!/usr/bin/perl use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
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.
--drkm
Emmanuel Florac writes:
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au
contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais
tout le monde recommande d'utiliser
#!/usr/bin/perl
use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
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.
Le Sun, 04 Sep 2005 15:06:01 +0200, drkm a écrit :
Je n'ai jamais nourri de haine envers Perl, mais je pense au contraire que ces libertés nuisent à son apprentissage
C'était le cas il y a quelquees années du temps de Perl 4. Désormais tout le monde recommande d'utiliser #!/usr/bin/perl use strict; use warnings;
Et immédiatemment il y a beaucoup moins de risques.
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.
--drkm
Xavier Gachon
Le 04-09-2005, drkm a écrit :
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. Nous parlons d'un langage qui n'existe pas mais serait implementer en Lisp, sa lisibilité reste donc une inconnue, le concept meme de lisibilité est relativement abstrait, les debat sans fins ni interet sur les sexp, la syntaxe indentée de Python en sont de bons exemples.
[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.
(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 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 :)
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.
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) ?
Il est particulierement adapté et de plus en plus utilisé pour l'apprentissage, le core langage lui meme est infiniment plus abordable que perl. 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 (sans aborder les bibliotheques).
-- "don't interfere in this discussion with your _facts_; how on earth will that help!? facts should only be administered by a qualified troller, usually in the form of a suppository".
Le 04-09-2005, drkm <usenet@fgeorges.org> a écrit :
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. Nous parlons
d'un langage qui n'existe pas mais serait implementer en Lisp, sa
lisibilité reste donc une inconnue, le concept meme de lisibilité
est relativement abstrait, les debat sans fins ni interet sur les
sexp, la syntaxe indentée de Python en sont de bons exemples.
[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.
(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 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 :)
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.
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) ?
Il est particulierement adapté et de plus en plus utilisé pour
l'apprentissage, le core langage lui meme est infiniment plus
abordable que perl. 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 (sans aborder les bibliotheques).
--
"don't interfere in this discussion with your _facts_; how on earth
will that help!? facts should only be administered by a qualified
troller, usually in the form of a suppository".
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. Nous parlons d'un langage qui n'existe pas mais serait implementer en Lisp, sa lisibilité reste donc une inconnue, le concept meme de lisibilité est relativement abstrait, les debat sans fins ni interet sur les sexp, la syntaxe indentée de Python en sont de bons exemples.
[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.
(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 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 :)
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.
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) ?
Il est particulierement adapté et de plus en plus utilisé pour l'apprentissage, le core langage lui meme est infiniment plus abordable que perl. 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 (sans aborder les bibliotheques).
-- "don't interfere in this discussion with your _facts_; how on earth will that help!? facts should only be administered by a qualified troller, usually in the form of a suppository".
Benoit Izac
Bonjour,
le 04/09/2005 à 16:51, drkm a écrit dans le message :
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. 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.
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.
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 ? « y = 2 * x », tu n'as jamais vu ça ? Et ton professeur t'a dit : on affecte « 2 » à « y » et on multiplie par « x » ?
Là ça devient n'importe quoi... -- Benoit Izac
Bonjour,
le 04/09/2005 à 16:51, drkm a écrit
dans le message <uirxg9988.fsf_-_@fgeorges.org> :
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. 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.
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.
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 ?
« y = 2 * x », tu n'as jamais vu ça ? Et ton professeur t'a dit : on
affecte « 2 » à « y » et on multiplie par « x » ?
le 04/09/2005 à 16:51, drkm a écrit dans le message :
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. 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.
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.
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 ? « y = 2 * x », tu n'as jamais vu ça ? Et ton professeur t'a dit : on affecte « 2 » à « y » et on multiplie par « x » ?
Là ça devient n'importe quoi... -- Benoit Izac
Thierry Boudet
On 2005-09-02, R12y wrote:
ou en macros VI.
Au passage, sur quel groupe VI est en charte?
alt.latin.mathematicae ?
-- *troll about Gnome, GTK, gnome-libs et coeur graphique* Non, elle constitue Gnome. Gnome n'a pas de coeur graphique. Gnome n'est que puretée électronique des données glissants le long des cordons fluides des bus logiciels.
On 2005-09-02, R12y <mihamina.rakotomandimby@etu.univ-orleans.fr> wrote:
ou en macros VI.
Au passage, sur quel groupe VI est en charte?
alt.latin.mathematicae ?
--
*troll about Gnome, GTK, gnome-libs et coeur graphique*
Non, elle constitue Gnome. Gnome n'a pas de coeur graphique. Gnome n'est
que puretée électronique des données glissants le long des cordons fluides
des bus logiciels.
-- *troll about Gnome, GTK, gnome-libs et coeur graphique* Non, elle constitue Gnome. Gnome n'a pas de coeur graphique. Gnome n'est que puretée électronique des données glissants le long des cordons fluides des bus logiciels.
