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 ...
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme, Lisp, etc... tous ceux que voudrez bien citer encore... cf. fr.emplois.offres )
Les contraintes ne sont pas les mêmes.
Le choix d'un langage se base sur son adaptation à la tâche voulue et aussi à sa diffusion parmi les informaticiens afin d'assurer sa maintenabilité.
Pour l'écriture de scripts, les informaticiens de base connaissent généralement le bash (et assimilé) et c'est tout !
Le Perl est plutôt bien diffusé même si la connaissance de ce langage est déjà un critère sélectif.
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle et dont son usage ne me parait réellement pertinent que dans des domaines bien spécifiques.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon avis, une aberration. Tout simplement car sa connaissance n'est pas assez répandu et qu'il n'apporte pas suffisament de chose par rapport aux langages déjà bien implantés (tel que le Perl par exemple). -- Bruno http://errance.lirano.net (photographies)
Jack Crow <jack.crow@caramail.com> wrote:
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et
pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme,
Lisp, etc... tous ceux que voudrez bien citer encore... cf.
fr.emplois.offres )
Les contraintes ne sont pas les mêmes.
Le choix d'un langage se base sur son adaptation à la tâche voulue et
aussi à sa diffusion parmi les informaticiens afin d'assurer sa
maintenabilité.
Pour l'écriture de scripts, les informaticiens de base connaissent
généralement le bash (et assimilé) et c'est tout !
Le Perl est plutôt bien diffusé même si la connaissance de ce langage
est déjà un critère sélectif.
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle et
dont son usage ne me parait réellement pertinent que dans des domaines
bien spécifiques.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon
avis, une aberration. Tout simplement car sa connaissance n'est pas
assez répandu et qu'il n'apporte pas suffisament de chose par rapport
aux langages déjà bien implantés (tel que le Perl par exemple).
--
Bruno
http://errance.lirano.net (photographies)
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme, Lisp, etc... tous ceux que voudrez bien citer encore... cf. fr.emplois.offres )
Les contraintes ne sont pas les mêmes.
Le choix d'un langage se base sur son adaptation à la tâche voulue et aussi à sa diffusion parmi les informaticiens afin d'assurer sa maintenabilité.
Pour l'écriture de scripts, les informaticiens de base connaissent généralement le bash (et assimilé) et c'est tout !
Le Perl est plutôt bien diffusé même si la connaissance de ce langage est déjà un critère sélectif.
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle et dont son usage ne me parait réellement pertinent que dans des domaines bien spécifiques.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon avis, une aberration. Tout simplement car sa connaissance n'est pas assez répandu et qu'il n'apporte pas suffisament de chose par rapport aux langages déjà bien implantés (tel que le Perl par exemple). -- Bruno http://errance.lirano.net (photographies)
drkm
Thomas Baruchel writes:
Qu'as-tu contre Guile ? C'est un excellent projet, qui outre l'aspect intéressant directement le posteur initial (interpréteur) constitue une bibliothèque de développement largement utilisée, avec notamment une interface C/Scheme d'emploi simple et puissant.
Au regard de la discussion, je pense qu'il est clair que c'est l'un des deux côtés de cette interface qui ne plaît pas trop à Pascal.
--drkm
Thomas Baruchel writes:
Qu'as-tu contre Guile ? C'est un excellent projet, qui outre l'aspect
intéressant directement le posteur initial (interpréteur) constitue
une bibliothèque de développement largement utilisée, avec notamment
une interface C/Scheme d'emploi simple et puissant.
Au regard de la discussion, je pense qu'il est clair que c'est
l'un des deux côtés de cette interface qui ne plaît pas trop à
Pascal.
Qu'as-tu contre Guile ? C'est un excellent projet, qui outre l'aspect intéressant directement le posteur initial (interpréteur) constitue une bibliothèque de développement largement utilisée, avec notamment une interface C/Scheme d'emploi simple et puissant.
Au regard de la discussion, je pense qu'il est clair que c'est l'un des deux côtés de cette interface qui ne plaît pas trop à Pascal.
--drkm
Thomas Baruchel
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme, Lisp, etc... tous ceux que voudrez bien citer encore... cf. fr.emplois.offres )
Il y a d'autres buts aux langages que l'entreprise ; un langage comme le Java permet de rapidement construire des produits finis, il intéresse donc directement les entreprises. Maintenant, les mathématiciens utilisent davantage le Caml (ou dérivé) et le Scheme que le Java (leur but n'est pas d'aboutir à un produit fini utilisable par des centaines de personne, mais d'élaborer des algorithmes, ici l'aspect fonctionnel de ces deux langages les intéresse particulièrement) ; quand je manipule certaines suites mathématiques, je me tourne spontanément vers le Haskell qui en quelques minutes me permettra de manipuler des suites infinies de façon propre. On ne peut juger de la qualité d'un langage aux nombres de personnes qui l'utilisent (à ce compte le visual basic serait meilleur que le lisp, le caml, le scheme et le haskell réunis). Certains se situent au milieu : le Lisp, OCaml, sont de vrais langages de développement (un exemple parmi d'autres: Maxima, un des meilleurs logiciels de calcul formel qui soit a été écrit en Lisp, tandis que la page http://caml.inria.fr/humps/ te donnera une liste de projets écrits en caml, un des plus connus étant Coq). Utilise-t-on ces logiciels ? OUI : les deux logiciels que j'utilise le plus sont Maxima et ledit (le premier écrit en lisp, le second en caml).
Bref, pense aussi aux usages non industriels suivants :
- trouver une solution à un problème donné (caml, scheme, prolog, etc.) - enseigner certaines techniques de programmation (caml, scheme, logo, etc.) - manipuler des données selon des logiques plus ou moins particulières (on oublie souvent le forth, merveilleux langage à pile...) - production automatique de code (je préfère écrire un programme qui écrira du prolog en énumérant des contraintes, du scheme en emboîtant des parenthèses, du forth en énumérant des données "brutes" que du C ou du Java) - etc.
Cordialement,
-- Thomas Baruchel
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et
pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme,
Lisp, etc... tous ceux que voudrez bien citer encore... cf.
fr.emplois.offres )
Il y a d'autres buts aux langages que l'entreprise ; un langage comme
le Java permet de rapidement construire des produits finis, il intéresse
donc directement les entreprises. Maintenant, les mathématiciens
utilisent davantage le Caml (ou dérivé) et le Scheme que le Java
(leur but n'est pas d'aboutir à un produit fini utilisable par des
centaines de personne, mais d'élaborer des algorithmes, ici l'aspect
fonctionnel de ces deux langages les intéresse particulièrement) ; quand
je manipule certaines suites mathématiques, je me tourne spontanément
vers le Haskell qui en quelques minutes me permettra de manipuler
des suites infinies de façon propre. On ne peut juger de la qualité d'un
langage aux nombres de personnes qui l'utilisent (à ce compte le visual
basic serait meilleur que le lisp, le caml, le scheme et le haskell réunis).
Certains se situent au milieu : le Lisp, OCaml, sont de vrais langages
de développement (un exemple parmi d'autres: Maxima, un des meilleurs
logiciels de calcul formel qui soit a été écrit en Lisp, tandis que
la page http://caml.inria.fr/humps/ te donnera une liste de projets
écrits en caml, un des plus connus étant Coq). Utilise-t-on ces logiciels ?
OUI : les deux logiciels que j'utilise le plus sont Maxima et ledit (le premier
écrit en lisp, le second en caml).
Bref, pense aussi aux usages non industriels suivants :
- trouver une solution à un problème donné (caml, scheme, prolog, etc.)
- enseigner certaines techniques de programmation (caml, scheme, logo, etc.)
- manipuler des données selon des logiques plus ou moins particulières
(on oublie souvent le forth, merveilleux langage à pile...)
- production automatique de code (je préfère écrire un programme qui
écrira du prolog en énumérant des contraintes, du scheme en emboîtant
des parenthèses, du forth en énumérant des données "brutes" que
du C ou du Java)
- etc.
pquoi dans ces forums on trouve tjrs des langages extraordinaires, et pourquoi aucun d'entre eux n'est jamais utilisé en entreprise ?
(je pense a tous ceux cités auparavant, et puis Eiffel, Caml, Scheme, Lisp, etc... tous ceux que voudrez bien citer encore... cf. fr.emplois.offres )
Il y a d'autres buts aux langages que l'entreprise ; un langage comme le Java permet de rapidement construire des produits finis, il intéresse donc directement les entreprises. Maintenant, les mathématiciens utilisent davantage le Caml (ou dérivé) et le Scheme que le Java (leur but n'est pas d'aboutir à un produit fini utilisable par des centaines de personne, mais d'élaborer des algorithmes, ici l'aspect fonctionnel de ces deux langages les intéresse particulièrement) ; quand je manipule certaines suites mathématiques, je me tourne spontanément vers le Haskell qui en quelques minutes me permettra de manipuler des suites infinies de façon propre. On ne peut juger de la qualité d'un langage aux nombres de personnes qui l'utilisent (à ce compte le visual basic serait meilleur que le lisp, le caml, le scheme et le haskell réunis). Certains se situent au milieu : le Lisp, OCaml, sont de vrais langages de développement (un exemple parmi d'autres: Maxima, un des meilleurs logiciels de calcul formel qui soit a été écrit en Lisp, tandis que la page http://caml.inria.fr/humps/ te donnera une liste de projets écrits en caml, un des plus connus étant Coq). Utilise-t-on ces logiciels ? OUI : les deux logiciels que j'utilise le plus sont Maxima et ledit (le premier écrit en lisp, le second en caml).
Bref, pense aussi aux usages non industriels suivants :
- trouver une solution à un problème donné (caml, scheme, prolog, etc.) - enseigner certaines techniques de programmation (caml, scheme, logo, etc.) - manipuler des données selon des logiques plus ou moins particulières (on oublie souvent le forth, merveilleux langage à pile...) - production automatique de code (je préfère écrire un programme qui écrira du prolog en énumérant des contraintes, du scheme en emboîtant des parenthèses, du forth en énumérant des données "brutes" que du C ou du Java) - etc.
Cordialement,
-- Thomas Baruchel
drkm
Bruno Jargot writes:
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle
Je suppose que tu voulais dire « qui n'est pas fort répandu » ?
--drkm
Bruno Jargot writes:
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle
Je suppose que tu voulais dire « qui n'est pas fort répandu » ?
Je ne te parle pas du Common Lisp qui a une diffusion confidentielle
Je suppose que tu voulais dire « qui n'est pas fort répandu » ?
Oui, je suis excessif en parlant de diffusion confidentielle.
-- Bruno http://errance.lirano.net (photographies)
Pascal Bourguignon
Thomas Baruchel writes:
Concernant emacs, on a portable hemlock et climacs comme (futures) alternatives. Quand à gimp et autres, si j'avais du temps j'y mettrais ecl à la place de guile...
Qu'as-tu contre Guile ? [...] Comprends bien que je ne cherche pas à alimenter une quelconque querelle de chapelles, mais je voudrais que tu développes ta pensée, car je suppose que tu as de bonnes raisons. Si tu visais moins Guile que le Scheme comme langage, tu dois évidemment avoir aussi tes raisons, mais le Scheme a beaucoup de qualités, j'aimerais donc des précisions de ta part.
Je n'ai rien de particulier contre Guile, si ce n'est que c'est un scheme. Je préfère Common Lisp à scheme.
Il y a des implementations de Common Lisp "embeddable", alors je ne trouve aucune excuse à utiliser guile dans une application quand on peut aussi bien utiliser ecl par exemple.
Sinon, le mouvement ex-emacs est en prévision du passage d'emacs à guile que RMS voudrait implémenter. (Il est vrai que emacs lisp est vieillot et a certains problèmes (pas de lexical scoping par exemple), mais ce n'est pas une raison pour passer à scheme quand il y a Common Lisp).
Le problème avec scheme, je devrais dire avec LES schemes, c'est qu'ils sont trés variables (aussi bien au fil du temps qu'à un moment donné entre implémentations). Comme je ne me suis mis à programmer en lisp que trés progressivement, avec quelques contacts en pointillés espacés pendant une bonne période, à chaque fois c'était avec un scheme différent et tout était à réapprendre (bon, à part la base nil cons car cdr null cond lambda). Par contre, avec Common Lisp, ce que j'ai appris il y a 13 ans je n'ai pas eu à le désapprendre pour utiliser Common Lisp aujourd'hui.
Ceci dit, scheme est un bon langage d'enseignement. Mais pour un professionnel, le bon outil est Common Lisp.
Thomas Baruchel <archaiesteron@laposte.net> writes:
Concernant emacs, on a portable hemlock et climacs comme (futures)
alternatives. Quand à gimp et autres, si j'avais du temps j'y
mettrais ecl à la place de guile...
Qu'as-tu contre Guile ? [...]
Comprends bien que je ne cherche pas à alimenter une quelconque querelle
de chapelles, mais je voudrais que tu développes ta pensée, car je suppose
que tu as de bonnes raisons. Si tu visais moins Guile que le Scheme comme
langage, tu dois évidemment avoir aussi tes raisons, mais le Scheme a
beaucoup de qualités, j'aimerais donc des précisions de ta part.
Je n'ai rien de particulier contre Guile, si ce n'est que c'est un scheme.
Je préfère Common Lisp à scheme.
Il y a des implementations de Common Lisp "embeddable", alors je ne
trouve aucune excuse à utiliser guile dans une application quand on
peut aussi bien utiliser ecl par exemple.
Sinon, le mouvement ex-emacs est en prévision du passage d'emacs à
guile que RMS voudrait implémenter. (Il est vrai que emacs lisp est
vieillot et a certains problèmes (pas de lexical scoping par exemple),
mais ce n'est pas une raison pour passer à scheme quand il y a Common
Lisp).
Le problème avec scheme, je devrais dire avec LES schemes, c'est
qu'ils sont trés variables (aussi bien au fil du temps qu'à un moment
donné entre implémentations). Comme je ne me suis mis à programmer en
lisp que trés progressivement, avec quelques contacts en pointillés
espacés pendant une bonne période, à chaque fois c'était avec un
scheme différent et tout était à réapprendre (bon, à part la base nil
cons car cdr null cond lambda). Par contre, avec Common Lisp, ce que
j'ai appris il y a 13 ans je n'ai pas eu à le désapprendre pour
utiliser Common Lisp aujourd'hui.
Ceci dit, scheme est un bon langage d'enseignement.
Mais pour un professionnel, le bon outil est Common Lisp.
Concernant emacs, on a portable hemlock et climacs comme (futures) alternatives. Quand à gimp et autres, si j'avais du temps j'y mettrais ecl à la place de guile...
Qu'as-tu contre Guile ? [...] Comprends bien que je ne cherche pas à alimenter une quelconque querelle de chapelles, mais je voudrais que tu développes ta pensée, car je suppose que tu as de bonnes raisons. Si tu visais moins Guile que le Scheme comme langage, tu dois évidemment avoir aussi tes raisons, mais le Scheme a beaucoup de qualités, j'aimerais donc des précisions de ta part.
Je n'ai rien de particulier contre Guile, si ce n'est que c'est un scheme. Je préfère Common Lisp à scheme.
Il y a des implementations de Common Lisp "embeddable", alors je ne trouve aucune excuse à utiliser guile dans une application quand on peut aussi bien utiliser ecl par exemple.
Sinon, le mouvement ex-emacs est en prévision du passage d'emacs à guile que RMS voudrait implémenter. (Il est vrai que emacs lisp est vieillot et a certains problèmes (pas de lexical scoping par exemple), mais ce n'est pas une raison pour passer à scheme quand il y a Common Lisp).
Le problème avec scheme, je devrais dire avec LES schemes, c'est qu'ils sont trés variables (aussi bien au fil du temps qu'à un moment donné entre implémentations). Comme je ne me suis mis à programmer en lisp que trés progressivement, avec quelques contacts en pointillés espacés pendant une bonne période, à chaque fois c'était avec un scheme différent et tout était à réapprendre (bon, à part la base nil cons car cdr null cond lambda). Par contre, avec Common Lisp, ce que j'ai appris il y a 13 ans je n'ai pas eu à le désapprendre pour utiliser Common Lisp aujourd'hui.
Ceci dit, scheme est un bon langage d'enseignement. Mais pour un professionnel, le bon outil est Common Lisp.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon avis, une aberration. Tout simplement car sa connaissance n'est pas assez répandu et qu'il n'apporte pas suffisament de chose par rapport aux langages déjà bien implantés (tel que le Perl par exemple).
C'est un problème d'oeuf et de poule. Quand perl fut inventé, il y avait moins de programmeurs connaissant perl que de programmeurs connaissant Common Lisp. Pourquoi les programmeurs de shell ont-ils donc appris perl au lieu d'apprendre Common Lisp?
Parce qu'ils se rendaient bien compte que sh (bash, etc) n'étaient pas adapté à leurs besoins. Mais perl non plus n'est pas adapté à leur besoin, sauf qu'ils ne s'en rendent pas encore compte. Le seul langage qui puisse être adapté à leur besoins, c'est Common Lisp, le langage de programmation programmable.
Deplus, je dirais qu'écrire un petit script isolé en bash, sur son poste de travail, pour un usage plus ou moins individuel et unique, pourquoi pas.
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon
avis, une aberration. Tout simplement car sa connaissance n'est pas
assez répandu et qu'il n'apporte pas suffisament de chose par rapport
aux langages déjà bien implantés (tel que le Perl par exemple).
C'est un problème d'oeuf et de poule. Quand perl fut inventé, il y
avait moins de programmeurs connaissant perl que de programmeurs
connaissant Common Lisp. Pourquoi les programmeurs de shell ont-ils
donc appris perl au lieu d'apprendre Common Lisp?
Parce qu'ils se rendaient bien compte que sh (bash, etc) n'étaient pas
adapté à leurs besoins. Mais perl non plus n'est pas adapté à leur
besoin, sauf qu'ils ne s'en rendent pas encore compte. Le seul
langage qui puisse être adapté à leur besoins, c'est Common Lisp, le
langage de programmation programmable.
Deplus, je dirais qu'écrire un petit script isolé en bash, sur son
poste de travail, pour un usage plus ou moins individuel et unique,
pourquoi pas.
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour
agencer des chaines de production ou pour réaliser d'autres tâches
administratives complexes et essentielles pour l'entreprise, le choix
d'un langage industriel comme Common Lisp sur un langage shell devrait
être évident.
Donc écrire des scripts en Common Lisp dans une entreprise est, à mon avis, une aberration. Tout simplement car sa connaissance n'est pas assez répandu et qu'il n'apporte pas suffisament de chose par rapport aux langages déjà bien implantés (tel que le Perl par exemple).
C'est un problème d'oeuf et de poule. Quand perl fut inventé, il y avait moins de programmeurs connaissant perl que de programmeurs connaissant Common Lisp. Pourquoi les programmeurs de shell ont-ils donc appris perl au lieu d'apprendre Common Lisp?
Parce qu'ils se rendaient bien compte que sh (bash, etc) n'étaient pas adapté à leurs besoins. Mais perl non plus n'est pas adapté à leur besoin, sauf qu'ils ne s'en rendent pas encore compte. Le seul langage qui puisse être adapté à leur besoins, c'est Common Lisp, le langage de programmation programmable.
Deplus, je dirais qu'écrire un petit script isolé en bash, sur son poste de travail, pour un usage plus ou moins individuel et unique, pourquoi pas.
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce langage dans ce contexte. Y a t-il des textes d'évangélisation disponibles sur le net ? -- Bruno http://errance.lirano.net (photographies)
Pascal Bourguignon <spam@mouse-potato.com> wrote:
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour
agencer des chaines de production ou pour réaliser d'autres tâches
administratives complexes et essentielles pour l'entreprise, le choix
d'un langage industriel comme Common Lisp sur un langage shell devrait
être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce
langage dans ce contexte. Y a t-il des textes d'évangélisation
disponibles sur le net ?
--
Bruno
http://errance.lirano.net (photographies)
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce langage dans ce contexte. Y a t-il des textes d'évangélisation disponibles sur le net ? -- Bruno http://errance.lirano.net (photographies)
Pascal Bourguignon
(Bruno Jargot) writes:
Pascal Bourguignon wrote:
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce langage dans ce contexte. Y a t-il des textes d'évangélisation disponibles sur le net ?
This is a signature virus. Add me to your signature and help me to live
see@reply-to.invalid (Bruno Jargot) writes:
Pascal Bourguignon <spam@mouse-potato.com> wrote:
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour
agencer des chaines de production ou pour réaliser d'autres tâches
administratives complexes et essentielles pour l'entreprise, le choix
d'un langage industriel comme Common Lisp sur un langage shell devrait
être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce
langage dans ce contexte. Y a t-il des textes d'évangélisation
disponibles sur le net ?
Mais en entreprise, lorsqu'il s'agit d'écrire des "scripts" pour agencer des chaines de production ou pour réaliser d'autres tâches administratives complexes et essentielles pour l'entreprise, le choix d'un langage industriel comme Common Lisp sur un langage shell devrait être évident.
Je t'avoue que c'est la première fois que je vois quelqu'un défendre ce langage dans ce contexte. Y a t-il des textes d'évangélisation disponibles sur le net ?
