À quoi ressemble votre flux de travail Lisp? [fermé]

J'apprends actuellement Lisp, issu d'une progression linguistique qui s'appelle Locomotive BASIC -> Z80 Assembler -> Pascal -> C -> Perl -> C # -> Ruby. Mon approche est de simultanément:

• écrire un simple gratte Web en utilisant SBCL, QuickLisp, closing-html et drakma
• regarder les conférences du SICP

Je pense que cela fonctionne bien; Je développe de bonnes "lunettes Lisp", dans la mesure où je peux maintenant lire Lisp assez facilement. Je me familiarise également avec le fonctionnement de l'écosystème Lisp, par exemple Quicklisp pour les dépendances.

Ce que je manque vraiment, cependant, est un sens de la façon dont un Lisper assaisonné réellement fonctionne .

Lorsque je code pour .NET, Visual Studio est configuré avec ReSharper et VisualSVN. J'écris des tests, j'implémente, je refacture, je commets. Puis, quand j'en ai assez fini pour compléter une histoire, j'écris des AUAT. Ensuite, je lance une version basée sur TeamCity afin de transmettre la nouvelle fonctionnalité au client afin que celui-ci soit testé et approuvé. Si c'est une application qui nécessite un programme d'installation, j'utilise WiX ou InnoSetup, en construisant évidemment le programme d'installation via le système CI.

Ma question est donc la suivante: en tant que Lisper expérimenté, à quoi ressemble votre flux de travail? Travaillez-vous principalement dans le REPL ou dans l'éditeur? Comment faites-vous des tests unitaires? Intégration continue? Emballage et déploiement? Lorsque vous vous assoyez à votre bureau, une tasse de café fumante sur le côté et une photo encadrée de John McCarthy à l’autre, que faites - vous ?

Actuellement, j'ai l'impression de maîtriser le codage Lisp, mais pas le développement de Lisp ...

La plupart des utilisateurs de comp.lang.lisp et de Lisp Forum recommandent une combinaison d'Emacs et de SLIME, en supposant que vous ne vouliez pas payer pour une implémentation commerciale comme Allegro ou LispWorks. La vidéo SLIME illustre le processus de travail. J'utilise Emacs et SLIME pour développer des programmes personnels à la maison, et la combinaison peut être très efficace.

SLIME vous donne une intégration entre Emacs et le REPL. Ce que je fais généralement, c'est de charger tous mes fichiers, puis d'ouvrir celui sur lequel je travaille dans Emacs. Après avoir tapé ou modifié chaque fonction, j'appuie sur C-x C-e, ce qui exécute la définition de la fonction dans le REPL. Ensuite, je peux basculer vers le tampon REPL et essayer la fonction. Tout l'historique de REPL est disponible et modifiable à l'aide de séquences de touches standard Emacs. Il est donc facile de refaire des appels de fonction avec différents paramètres.

Je travaille principalement avec Clojure, et voici ma configuration:

1. Eclipse IDE (j'utilise ceci car je fais aussi beaucoup de travail en Java, parfois dans le même projet que Clojure)
2. Plugin dans le sens antihoraire pour Clojure (cela inclut un REPL)
3. Maven pour la gestion des dépendances et des builds
4. Egit pour le contrôle du code source

Le flux de travail pendant le codage est généralement le suivant:

1. Ouvrir un REPL, en chargeant tous les fichiers source actuels
2. Code et test dans le REPL
3. Quand je suis content avec du code, recopier / coller dans le fichier source
4. Redémarrez de temps en temps le REPL (soit quand j'ai bouleversé un espace de noms irrévocablement, soit juste pour vérifier que tout fonctionne toujours dans les fichiers sources)
5. Également écrire des tests dans les fichiers source, qui sont exécutés automatiquement par chaque version de Maven. Parfois, les tests informels que je viens de faire à la REPL sont transformés directement en tests unitaires.
6. Commit, etc. à ce stade - un flux de travail de développement assez régulier

Globalement, ce n'est pas très différent d'un flux de travail Java / C # classique, mis à part l'utilisation plus interactive du REPL pendant le développement.

Pour compléter les autres réponses, je fais une combinaison du type de développement "Pensez sérieusement au problème, puis écrivez la solution" et "Commencez par un remplaçant, et mettez votre programme en forme de manière itérative". C'est généralement au milieu. Ce que je fais, c'est que je commence par une idée générale de ce que je veux que mon programme ressemble, puis je commence à l'écrire, en essayant d'acquérir de nouvelles connaissances sur le domaine du problème au fur et à mesure, afin de réviser mon approche. En pratique, cela signifie que je fais beaucoup d’expérimentation et que j’écris beaucoup de code de trow-away. J'essaie différentes approches et je peux changer de direction très rapidement. Lisp est bon pour ce genre de développement. C'est pourquoi je n'aime pas tellement le TDD, je dois savoir ce que je veux faire en premier pour pouvoir le TDD efficacement.

Une autre chose importante que j'essaie de faire est de réfléchir davantage au protocole entre les différentes parties d’un programme. Contrairement à d'autres langages OO, In Common Lisp CLOS est davantage axé sur le concept de fonction générique. Les méthodes IOW vivent en dehors des classes et sont au centre du développement. Parfois, je commence simplement avec un ensemble de GF définissant le protocole que je veux, j’écris une implémentation simple et l’utilise pour préciser le protocole, avant d’écrire une implémentation réelle. Supposons que je suis en train d'écrire une couche qui stocke de nombreux articles de blog. J'aurais peut-être un ensemble de fichiers GF qui définissent la manière dont les articles de blog sont créés, édités et recherchés, et j'écrirais une implémentation simple qui enregistre les articles de blog dans une liste en mémoire. et, une fois satisfait de mon protocole, j’écris une implémentation qui enregistre les articles de blog dans une base de données ou les enregistre dans des fichiers.

Lisp facilite tellement le changement de direction et l’adoption d’une approche différente lorsque vous savez que votre solution actuelle est sous-optimale que j’essaie d’optimiser.

Autre point important: utilisez au maximum votre environnement, apprenez à utiliser différents paramètres de compilation pour compiler votre code avec davantage d'informations de débogage, profitez du fait que lisp peut être à la fois compilé et interprété. Utilisez les fonctions introspectives de lisps, telles que le MOP, utilisez les fonctionnalités de slimes pour consulter la documentation, utilisez l'inspecteur pour rechercher des objets, consultez l'hyperspec régulièrement, traitez votre système davantage comme un système d'exploitation, qu'un compilateur statique pour votre code, c'est beaucoup plus puissant que cela.

Pour un débutant, lisp n’est pas vraiment une victoire sur le python et le rubis, mais plus vous gagnez en expérience, plus vous remportez d’énormes gains sur des environnements moins importants.

Plus important encore, vous devez vous amuser et aimer cette langue, il est parfois trop facile de se décourager et d’utiliser les langues blub actuellement en vogue. Si vous vous en tenez à Lisp, cela vous remboursera.

J'ai tendance à travailler dans un éditeur connecté à un REPL (généralement, l'édition dans emacs et l'utilisation de SLIME comme passerelle vers un environnement Common Lisp). J'ai tendance à commencer à la fois "en bas" et "en haut", en travaillant vers le milieu, en révisant le dessin au fur et à mesure.

En ce qui concerne les tests, c’est la raison pour laquelle j’ai un REPL. Je trouve que cela aide à tester le code au fur et à mesure. Je vais parfois écrire plus de tests formels ou de points de repère au fur et à mesure (généralement une fois que je suis dans la phase d'optimisation). Avoir une implémentation plus lente et satisfaisante d'une fonctionnalité, expérimenter (dans une fenêtre d'éditeur) avec du code pour une version optimisée, l'envoyer au code lisp sous-jacent et vérifier qu'il est à la fois plus rapide et renvoie les mêmes résultats que ceux de la version la plus lente. code.

En ce qui concerne le packaging, j'ai un code utilitaire qui m'aide à compresser les projets installables ASDF, à les glisser dans un référentiel de téléchargement et à gérer le contrôle de version.