Je partage car j'ai mis du temps à m'en rendre compte: les IDE Common Lisp, notamment Emacs & Slime mais pas que (maintenant SLIMA pour Atom est très bien), font déjà tout ça depuis... des décennies (avec une réserve sur le ré-usinage).
On a en effet: un serveur (Slynk) connecté à l'image Lisp en train de tourner, qu'on modifie à la volée pendant qu'on développe, et un client (Slime) connecté à l'éditeur. Toutes les infos décrites dans la dépêche existent de base dans l'image: les références croisées (qui appelle, qui modifie, qui est appelé par, qui référence qui), la validation est faite à la volée quand on compile notre code (on peut compiler la fonction sur laquelle on travaille, on a donc un retour immédiat avec variables non déclarées, mauvaises inférences de type, code inaccessible etc), la documentation etc.
Le tout de manière très fluide (alors qu'avec mon IDE Python...). Bref, c'est vraiment agréable à l'usage, c'est bon à connaître.
# Ça existait... en Lisp
Posté par dzecniv . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 5.
Je partage car j'ai mis du temps à m'en rendre compte: les IDE Common Lisp, notamment Emacs & Slime mais pas que (maintenant SLIMA pour Atom est très bien), font déjà tout ça depuis... des décennies (avec une réserve sur le ré-usinage).
On a en effet: un serveur (Slynk) connecté à l'image Lisp en train de tourner, qu'on modifie à la volée pendant qu'on développe, et un client (Slime) connecté à l'éditeur. Toutes les infos décrites dans la dépêche existent de base dans l'image: les références croisées (qui appelle, qui modifie, qui est appelé par, qui référence qui), la validation est faite à la volée quand on compile notre code (on peut compiler la fonction sur laquelle on travaille, on a donc un retour immédiat avec variables non déclarées, mauvaises inférences de type, code inaccessible etc), la documentation etc.
Le tout de manière très fluide (alors qu'avec mon IDE Python...). Bref, c'est vraiment agréable à l'usage, c'est bon à connaître.