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 ...
Ce n'est jamais que ce que fait un shell. La syntaxe est juste différente.
Hum, oui, c'est vrai.
Pour ce qui est des avantages, il y a le fait que tu peux faire tout ce que tu peux faire en CL. Ce n'est pas à négliger.
Euh, mais comme quoi ? Qu'est-ce qu'on peut faire de "plus" avec CL ? (je mets des guillemets à "plus" : ne tombons pas dans la discussion sur les machines de Turing ;) Peut-être que les avantages se font sentir par rapport à bash, par exemple, sur des programmes un peu conséquents ? Peut-être y a-t-il plus de fonctions intégrées ?
Merci pour ma culture :)
Prenons le cas soulevé par le PO:
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) ...
On veut donc des scripts capables de fonctionner dans différents environnements, avec des comportements variables et configurables.
On peut facilement programmer ce genre de chose avec des objets, en ayant des classes génériques via lesquelles les scripts travaillent, et des sous-classes spécifiques aux outils concrêts.
Par exemple à un bas niveau, un pourrait avoir un objet ARCHIVEUR, avec des sous-classes: tar, gnutar, pax, etc.
Je dirais même plus, avec ces besoins, on a même besoin d'héritage multiple, car une opération peut dépendre non seulement de l'outil utilisé, mais aussi de la plateforme cible. En CLOS (Common Lisp Object System), on peut écrire des multi-méthodes tel que:
(defvar archiver (make-instance 'pax)) ; fait par la configuration. (defvar system (uname))
(dolist (archive (list (make-instance 'local-file :path (make-pathname :directory archdir :name "tools" :type (archiver file-type))) (make-instance 'http-resource :url (make-url :host disthost :path "/distrib/application")))) (unarchive arch system archive)) ; la méthode utilisée dépend des trois arguments!
Pour comparer avec ce qui se fait en shell, shercher shoop: http://www.advogato.org/proj/shoop/ C'est un peu l'usine à gaz...
En passant, un autre lisp orienté "shell": http://lush.sourceforge.net/
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
-- "A TRUE Klingon warrior does not comment his code!"
Ce n'est jamais que ce que fait un shell. La syntaxe est juste
différente.
Hum, oui, c'est vrai.
Pour ce qui est des avantages, il y a le fait que tu peux faire
tout ce que tu peux faire en CL. Ce n'est pas à négliger.
Euh, mais comme quoi ? Qu'est-ce qu'on peut faire de "plus" avec CL ?
(je mets des guillemets à "plus" : ne tombons pas dans la discussion
sur les machines de Turing ;) Peut-être que les avantages se font
sentir par rapport à bash, par exemple, sur des programmes un peu
conséquents ? Peut-être y a-t-il plus de fonctions intégrées ?
Merci pour ma culture :)
Prenons le cas soulevé par le PO:
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) ...
On veut donc des scripts capables de fonctionner dans différents
environnements, avec des comportements variables et configurables.
On peut facilement programmer ce genre de chose avec des objets, en
ayant des classes génériques via lesquelles les scripts travaillent,
et des sous-classes spécifiques aux outils concrêts.
Par exemple à un bas niveau, un pourrait avoir un objet ARCHIVEUR,
avec des sous-classes: tar, gnutar, pax, etc.
Je dirais même plus, avec ces besoins, on a même besoin d'héritage
multiple, car une opération peut dépendre non seulement de l'outil
utilisé, mais aussi de la plateforme cible. En CLOS (Common Lisp
Object System), on peut écrire des multi-méthodes tel que:
(defvar archiver (make-instance 'pax)) ; fait par la configuration.
(defvar system (uname))
(dolist (archive (list (make-instance 'local-file
:path (make-pathname :directory archdir
:name "tools"
:type (archiver file-type)))
(make-instance 'http-resource
:url (make-url :host disthost
:path "/distrib/application"))))
(unarchive arch system archive))
; la méthode utilisée dépend des trois arguments!
Pour comparer avec ce qui se fait en shell, shercher shoop:
http://www.advogato.org/proj/shoop/
C'est un peu l'usine à gaz...
En passant, un autre lisp orienté "shell": http://lush.sourceforge.net/
Mais personnellement, je préfère utiliser Common Lisp pour tous mes
besoins de programmation plutôt que de passer par scheme, lush, emacs,
gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp:
Common Lisp.
--
"A TRUE Klingon warrior does not comment his code!"
Ce n'est jamais que ce que fait un shell. La syntaxe est juste différente.
Hum, oui, c'est vrai.
Pour ce qui est des avantages, il y a le fait que tu peux faire tout ce que tu peux faire en CL. Ce n'est pas à négliger.
Euh, mais comme quoi ? Qu'est-ce qu'on peut faire de "plus" avec CL ? (je mets des guillemets à "plus" : ne tombons pas dans la discussion sur les machines de Turing ;) Peut-être que les avantages se font sentir par rapport à bash, par exemple, sur des programmes un peu conséquents ? Peut-être y a-t-il plus de fonctions intégrées ?
Merci pour ma culture :)
Prenons le cas soulevé par le PO:
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) ...
On veut donc des scripts capables de fonctionner dans différents environnements, avec des comportements variables et configurables.
On peut facilement programmer ce genre de chose avec des objets, en ayant des classes génériques via lesquelles les scripts travaillent, et des sous-classes spécifiques aux outils concrêts.
Par exemple à un bas niveau, un pourrait avoir un objet ARCHIVEUR, avec des sous-classes: tar, gnutar, pax, etc.
Je dirais même plus, avec ces besoins, on a même besoin d'héritage multiple, car une opération peut dépendre non seulement de l'outil utilisé, mais aussi de la plateforme cible. En CLOS (Common Lisp Object System), on peut écrire des multi-méthodes tel que:
(defvar archiver (make-instance 'pax)) ; fait par la configuration. (defvar system (uname))
(dolist (archive (list (make-instance 'local-file :path (make-pathname :directory archdir :name "tools" :type (archiver file-type))) (make-instance 'http-resource :url (make-url :host disthost :path "/distrib/application")))) (unarchive arch system archive)) ; la méthode utilisée dépend des trois arguments!
Pour comparer avec ce qui se fait en shell, shercher shoop: http://www.advogato.org/proj/shoop/ C'est un peu l'usine à gaz...
En passant, un autre lisp orienté "shell": http://lush.sourceforge.net/
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
-- "A TRUE Klingon warrior does not comment his code!"
Christophe Gaubert
Prenons le cas soulevé par le PO:
Merci. En fait, ma question était un peu "stupide". Je n'avais pas cherché plus loin et je n'avais pas vu que c'était orienté-objet (avec garbage collection !), qu'il y avait pas mal de type de données pré-définis, etc. http://clisp.sourceforge.net/propaganda.html C'est sûr que par rapport à bash...
Pour comparer avec ce qui se fait en shell, shercher shoop: http://www.advogato.org/proj/shoop/ C'est un peu l'usine à gaz...
Ça a l'air mort (ce n'est plus référencé chez sourceforge).
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
Prenons le cas soulevé par le PO:
Merci. En fait, ma question était un peu "stupide". Je n'avais pas
cherché plus loin et je n'avais pas vu que c'était orienté-objet (avec
garbage collection !), qu'il y avait pas mal de type de données
pré-définis, etc.
http://clisp.sourceforge.net/propaganda.html
C'est sûr que par rapport à bash...
Pour comparer avec ce qui se fait en shell, shercher shoop:
http://www.advogato.org/proj/shoop/
C'est un peu l'usine à gaz...
Ça a l'air mort (ce n'est plus référencé chez sourceforge).
--
Christophe Gaubert
http://perso.wanadoo.fr/christophe.gaubert
Mail posté depuis un système libre GNU/Linux
Merci. En fait, ma question était un peu "stupide". Je n'avais pas cherché plus loin et je n'avais pas vu que c'était orienté-objet (avec garbage collection !), qu'il y avait pas mal de type de données pré-définis, etc. http://clisp.sourceforge.net/propaganda.html C'est sûr que par rapport à bash...
Pour comparer avec ce qui se fait en shell, shercher shoop: http://www.advogato.org/proj/shoop/ C'est un peu l'usine à gaz...
Ça a l'air mort (ce n'est plus référencé chez sourceforge).
-- Christophe Gaubert http://perso.wanadoo.fr/christophe.gaubert Mail posté depuis un système libre GNU/Linux
drkm
Pascal Bourguignon writes:
(defvar archiver (make-instance 'pax)) ; fait par la configuration. (defvar system (uname))
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit aussi du langage d'extension d'un programme), cela est plus compliqué. Mais il est vrai que lorsque le code est plutôt autonome (s'il ne doit pas trop toucher directement aux buffers, par exemple) et un peu complexe, utiliser un processus externe en CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut faciliter la tâche. Notamment afin de disposer d'un système objet utilisable.
--drkm
Pascal Bourguignon writes:
(defvar archiver (make-instance 'pax)) ; fait par la configuration.
(defvar system (uname))
Mais personnellement, je préfère utiliser Common Lisp pour tous mes
besoins de programmation plutôt que de passer par scheme, lush, emacs,
gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp:
Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit
aussi du langage d'extension d'un programme), cela est plus
compliqué. Mais il est vrai que lorsque le code est plutôt
autonome (s'il ne doit pas trop toucher directement aux buffers,
par exemple) et un peu complexe, utiliser un processus externe en
CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut
faciliter la tâche. Notamment afin de disposer d'un système
objet utilisable.
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit aussi du langage d'extension d'un programme), cela est plus compliqué. Mais il est vrai que lorsque le code est plutôt autonome (s'il ne doit pas trop toucher directement aux buffers, par exemple) et un peu complexe, utiliser un processus externe en CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut faciliter la tâche. Notamment afin de disposer d'un système objet utilisable.
--drkm
Jack Crow
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 )
Pascal Bourguignon wrote:
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais lisp est beaucoup plus expressif!
S'il est plus expressif, cela veut-il dire qu'il existe des algorithmes implémentables en lisp qui ne peuvent pas l'être avec Sed ?
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 )
Pascal Bourguignon wrote:
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais
lisp est beaucoup plus expressif!
S'il est plus expressif, cela veut-il dire qu'il existe des algorithmes
implémentables en lisp qui ne peuvent pas l'être avec Sed ?
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 )
Pascal Bourguignon wrote:
Pas en terme d'expressivité. sed est turing-équivalent à lisp. Mais lisp est beaucoup plus expressif!
S'il est plus expressif, cela veut-il dire qu'il existe des algorithmes implémentables en lisp qui ne peuvent pas l'être avec Sed ?
Pascal Bourguignon
drkm writes:
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit aussi du langage d'extension d'un programme), cela est plus compliqué. Mais il est vrai que lorsque le code est plutôt autonome (s'il ne doit pas trop toucher directement aux buffers, par exemple) et un peu complexe, utiliser un processus externe en CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut faciliter la tâche. Notamment afin de disposer d'un système objet utilisable.
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...
Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY.
drkm <usenet@fgeorges.org> writes:
Mais personnellement, je préfère utiliser Common Lisp pour tous mes
besoins de programmation plutôt que de passer par scheme, lush, emacs,
gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp:
Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit
aussi du langage d'extension d'un programme), cela est plus
compliqué. Mais il est vrai que lorsque le code est plutôt
autonome (s'il ne doit pas trop toucher directement aux buffers,
par exemple) et un peu complexe, utiliser un processus externe en
CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut
faciliter la tâche. Notamment afin de disposer d'un système
objet utilisable.
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...
Mais personnellement, je préfère utiliser Common Lisp pour tous mes besoins de programmation plutôt que de passer par scheme, lush, emacs, gimp, etc: c'est tous des lisp, alors autant prendre le meilleur lisp: Common Lisp.
Pour Emacs (et j'imagine également pour Gimp, puisqu'il s'agit aussi du langage d'extension d'un programme), cela est plus compliqué. Mais il est vrai que lorsque le code est plutôt autonome (s'il ne doit pas trop toucher directement aux buffers, par exemple) et un peu complexe, utiliser un processus externe en CL, couplé à un peu d'Emacs Lisp pour faire le lien, peut faciliter la tâche. Notamment afin de disposer d'un système objet utilisable.
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...
Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon
Jack Crow writes:
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 )
Parce que ce sont les programmeurs qui participent à ces forums, pas les manageurs.
Le but des programmeurs, c'est de réaliser des programmes.
Le but des manageurs, c'est d'avoir des grosses équipes et des gros budgets afin de grimper dans l'échelle de l'entreprise.
Alors, si un langage de programmation permet à un programmeur de faire le travail de 100 autres avec un autre langage, le manageur a vite fait son choix pour le second!
Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY.
Jack Crow <jack.crow@caramail.com> writes:
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 )
Parce que ce sont les programmeurs qui participent à ces forums, pas
les manageurs.
Le but des programmeurs, c'est de réaliser des programmes.
Le but des manageurs, c'est d'avoir des grosses équipes et des gros
budgets afin de grimper dans l'échelle de l'entreprise.
Alors, si un langage de programmation permet à un programmeur de faire
le travail de 100 autres avec un autre langage, le manageur a vite
fait son choix pour le second!
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 )
Parce que ce sont les programmeurs qui participent à ces forums, pas les manageurs.
Le but des programmeurs, c'est de réaliser des programmes.
Le but des manageurs, c'est d'avoir des grosses équipes et des gros budgets afin de grimper dans l'échelle de l'entreprise.
Alors, si un langage de programmation permet à un programmeur de faire le travail de 100 autres avec un autre langage, le manageur a vite fait son choix pour le second!
Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY.
Thomas Baruchel
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 ? 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.
En tant qu'interpréteur Scheme, il n'est pas mauvais : je ne fais pas référence au support plus ou moins complet des spécifications, mais au compromis exhaustivité/rapidité/disponibilité/facilité d'accès, etc. Rappelons qu'il supporte la SLIB, readline après une configuration rapide, les grands entiers par défaut, etc.
Il est utilisé dans des projets reconnus : http://www.gnu.org/software/guile/gnu-guile-projects.html#Applications
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.
Cordialement,
-- Thomas Baruchel
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 ? 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.
En tant qu'interpréteur Scheme, il n'est pas mauvais : je ne fais pas
référence au support plus ou moins complet des spécifications, mais
au compromis exhaustivité/rapidité/disponibilité/facilité d'accès, etc.
Rappelons qu'il supporte la SLIB, readline après une configuration
rapide, les grands entiers par défaut, etc.
Il est utilisé dans des projets reconnus :
http://www.gnu.org/software/guile/gnu-guile-projects.html#Applications
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.
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 ? 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.
En tant qu'interpréteur Scheme, il n'est pas mauvais : je ne fais pas référence au support plus ou moins complet des spécifications, mais au compromis exhaustivité/rapidité/disponibilité/facilité d'accès, etc. Rappelons qu'il supporte la SLIB, readline après une configuration rapide, les grands entiers par défaut, etc.
Il est utilisé dans des projets reconnus : http://www.gnu.org/software/guile/gnu-guile-projects.html#Applications
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.
Cordialement,
-- Thomas Baruchel
drkm
Pascal Bourguignon writes:
Je crosposte et folauweptou fca.emacs.
Concernant emacs, on a portable hemlock et climacs comme (futures) alternatives.
Mais qui ne sont pas encore utilisables, il me semble (ce que tu laisses sous-entendre). Si je me souviens bien, Climacs est un projet de Robert Strandh. Robert, si tu nous entends, quel est l'avancement de Climacs ?
Et puis il faudrait que ces programmes acceptent du code Emacs Lisp, pour pouvoir utiliser le code existant. Sans cela, je ne pense pas qu'ils seront réellement utilisables avant longtemps (et avant que beaucoup de monde s'y investisse). Mais a priori, ça ne devrait pas poser beaucoup de problèmes.
--drkm
Pascal Bourguignon writes:
Je crosposte et folauweptou fca.emacs.
Concernant emacs, on a portable hemlock et climacs comme (futures)
alternatives.
Mais qui ne sont pas encore utilisables, il me semble (ce que
tu laisses sous-entendre). Si je me souviens bien, Climacs est
un projet de Robert Strandh. Robert, si tu nous entends, quel
est l'avancement de Climacs ?
Et puis il faudrait que ces programmes acceptent du code Emacs
Lisp, pour pouvoir utiliser le code existant. Sans cela, je ne
pense pas qu'ils seront réellement utilisables avant longtemps
(et avant que beaucoup de monde s'y investisse). Mais a priori,
ça ne devrait pas poser beaucoup de problèmes.
Concernant emacs, on a portable hemlock et climacs comme (futures) alternatives.
Mais qui ne sont pas encore utilisables, il me semble (ce que tu laisses sous-entendre). Si je me souviens bien, Climacs est un projet de Robert Strandh. Robert, si tu nous entends, quel est l'avancement de Climacs ?
Et puis il faudrait que ces programmes acceptent du code Emacs Lisp, pour pouvoir utiliser le code existant. Sans cela, je ne pense pas qu'ils seront réellement utilisables avant longtemps (et avant que beaucoup de monde s'y investisse). Mais a priori, ça ne devrait pas poser beaucoup de problèmes.
