Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.
J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,...). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.
Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.
Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,...).
Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 4.
Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.
J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,...). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.
Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.
Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,...).
Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).