Modifier des programmes "pendant qu'ils sont en cours d'exécution" ? Pourquoi ?

Question

Je me suis intéressé de plus près aux langages Lisp et Lispy ces derniers temps, et je les trouve assez puissants.

Une chose que j'ai lue un peu partout sur le net, c'est qu'un des avantages d'écrire en Lisp, Clojure, etc., est que vous pouvez modifier votre programme "pendant qu'il est en cours d'exécution".

Peut-être que quelque chose m'échappe, mais quel est l'intérêt ?

Bien sûr, cela peut faire gagner quelques secondes, mais est-ce tout ? Chaque fois que j'apporte une modification à mon programme, je l'arrête puis le relance, et cela fonctionne parfaitement depuis des décennies.

Il doit y avoir une raison autre que le simple gain de temps - quelle est-elle ?

Quelqu'un peut-il me donner une bonne étude de cas qui me fera saliver sur cette fonctionnalité ? :)

J'ai hâte de baver !

Answer 1

Il doit y avoir une raison autre que le simple gain de temps - quelle est-elle ?

Non, il n'y en a pas. Je veux dire, il y a jamais est : le raison entière d'utiliser un ordinateur est de gagner du temps. Il n'y a rien qu'un ordinateur puisse faire que vous ne puissiez faire à la main. Cela prend juste un peu plus de temps.

Dans ce cas, je ne rejetterais pas "quelques secondes", étant donné que c'est l'une des choses que je fais le plus souvent, toute la journée, pendant toute ma carrière de programmeur. Quelques secondes pour recompiler, quelques secondes pour ré-exécuter, plusieurs secondes pour recréer l'état que mon programme avait la fois précédente -- même sur une station de travail rapide, cela peut facilement prendre une minute entre les itérations. (C'était bien pire avant, mais l'accélération du matériel n'a fait que le rendre moins horrible, pas bon. Les recompilations de fichiers entiers ou pires sont liées aux E/S, et peuvent ne jamais* égaler la vitesse d'une compilation plus granulaire).

En Lisp, la recompilation d'une seule fonction dans un processus déjà en cours d'exécution est presque instantanée (je ne l'ai jamais vue même 0,1 sec, même sur mon ordinateur portable de 5 ans), et les redémarrages signifient que je n'ai pas à recréer mon état, même lorsque quelque chose se signale.

Voici un outil qui me permet d'accélérer de plus de 100 fois l'une des tâches les plus lentes et les plus courantes que je fais en tant que programmeur. Je ne sais pas de quoi d'autre vous auriez besoin. Nous pouvons probablement inventer des raisons, mais si ce n'est pas une raison suffisante, je ne sais pas ce qui le serait. Hum, c'est aussi plutôt cool ? :-)

(* Chaque fois que quelqu'un dit "jamais" à propos d'un sujet impliquant la technologie, cette personne finit invariablement par passer pour un crétin complet 2 ans plus tard, et malgré la longévité de Lisp, je suis sûr de ne pas faire exception).

Answer 2

Il existe des cas d'utilisation extrêmement intéressants. J'ai pu le constater en développant une application graphique en temps réel, alors qu'elle s'exécutait à côté de mon Emacs : J'ai ajouté le code d'un nouveau bouton et j'ai tapé "C-c C-c" pour compiler cette seule fonction, et le bouton a juste est apparu dans la fenêtre ! Je n'ai pas eu à fermer et rouvrir l'application. J'ai ensuite commencé à modifier les widgets et à manipuler la mise en page, et la fenêtre ouverte se réorganisait instantanément - les boutons se déplaçaient, de nouveaux champs de texte apparaissaient, etc. dès que j'exécutais chaque petite modification que j'avais apportée.

Un autre exemple est un excellent screencast sur la bibliothèque Clojure OpenGL "Penumbra" où le programmeur crée un jeu de tétris en 3D en temps réel. Il commence avec une fenêtre OpenGL vide à côté de son emacs. Il définit un objet cube - C-M-x - et il est à l'écran. Il lance une commande pour le faire tourner, il commence immédiatement à tourner. Il exécute une boucle définissant 5 autres cubes à différents endroits, pop-pop-pop-pop-pop ils apparaissent. Tout est immédiatement réactif, avec toute la boîte à outils OpenGL à portée de main. Ajoutez une nouvelle texture de surface à votre cube et voyez-la apparaître immédiatement. Il devient un monde 3D malléable - le code modifie dynamiquement le monde existant au lieu de fermer et rouvrir le canevas 3D à chaque changement.

Screencast sur le Livecoding de Penumbra - Téléchargez la version HD pour une meilleure expérience.

Il y a également une excellente présentation/diffusion d'écran sur la bibliothèque audio "Overtone" pour Clojure. Cette bibliothèque est une boîte à outils de synthétiseur dans laquelle vous disposez d'un ensemble de fonctions de synthèse pour manipuler l'onde sonore. Pendant la présentation, le développeur écrit un bout de code qui lance la lecture d'un son. Il passe ensuite dix secondes à écrire une boucle qui joue ce son 10 fois mais en augmentant la fréquence à chaque fois, et encore C-M-x et vous l'entendez, des notes qui montent plus haut. En l'espace de 20 minutes en temps réel, il crée une chanson. On dirait que c'est très amusant.

Lien vers la présentation de l'Overtone

D'autres utilisations seraient, par exemple : Exploration du Web/exploitation des données - développez et affinez des algorithmes pour extraire des informations en temps réel, en voyant les données renvoyées à chaque étape ; Programmation robotique - envoyez des commandes à un robot pendant qu'il est en direct ; Reconnaissance faciale/image - avec une bibliothèque comme OpenCV, regardez vos modifications mettre instantanément à jour ce que la bibliothèque reconnaît dans une image/vidéo pendant que vous développez le code ; Travail mathématique (Clojure a " Incanter " pour les statistiques) ; et tout environnement où vous voulez voir immédiatement l'effet de vos modifications sur les données avec lesquelles vous travaillez.

C'est donc l'aspect le plus amusant d'avoir un REPL en face de soi. Des choses qui n'étaient pas tangibles, malléables, interactives, commencent à l'être. La conception d'interfaces graphiques, les graphiques 3D, la production programmatique de sons, l'extraction et la transformation de données, ces choses ont normalement été faites à distance. Mais avec Clojure (et dans une certaine mesure avec d'autres langages dynamiques aussi), c'est rendu vraiment tangible et immédiat ; vous voyez chaque changement dès que vous écrivez le code, et si quelque chose ne fonctionne pas ou si vous n'obtenez pas le résultat attendu, vous changez simplement ce qui vous a échappé et vous réexécutez immédiatement.

Clojure est très orienté dans ce sens. Le plus fou, c'est qu'il est possible d'utiliser les bibliothèques Java en temps réel de la même manière, bien que Java lui-même ne le puisse pas ! Ainsi, Overtone utilise une bibliothèque de synthétiseurs Java en temps réel alors que Java ne le permet pas, Penumbra utilise les liaisons OpenGL de Java, etc. C'est parce que Rich Hickey a conçu Clojure de manière à ce qu'il puisse compiler en bytecode JVM à la volée. C'est un langage étonnant - Clojure a apporté une énorme contribution à la manière dont la programmation peut être incroyablement amusante et productive.

Answer 3

Il existe un slogan marketing pour Lisp :

Avec Lisp, et sa méthode de développement incrémental, le coût d'une modification d'un système logiciel dépend de la taille de la modification, et non de la taille de l'ensemble du logiciel.

Même si nous avons un grand système logiciel, le coût (temps, ...) d'un changement reste en relation avec la taille du changement. Si nous ajoutons une nouvelle méthode ou si nous modifions une nouvelle méthode, l'effort reste lié à l'effort d'édition de la méthode, de compilation incrémentale de la méthode et de chargement incrémental de la méthode.

Dans de nombreux environnements logiciels traditionnels, le changement d'une méthode peut nécessiter une recompilation partielle, un nouvel exécutable lié, un redémarrage, un rechargement, etc. Plus le logiciel est volumineux, plus cela prend du temps.

Pour un être humain, cela signifie que nous pouvons éventuellement sortir d'un état de fluidité . Cela fait partie de la productivité des bons environnements Lisp : on peut apporter beaucoup de changements à un système logiciel en peu de temps, une fois que le programmeur se sent à l'aise et qu'il entre dans ce système. état de fluidité . Je suppose que beaucoup ont vécu cette expérience, où le travail est effectué en peu de temps - contrairement aux moments où l'on est assis devant un système qui ne répond pas et où nous sommes confrontés à des temps d'attente.

Il y a aussi peu distance cognitive entre nous et le programme sur lequel nous travaillons. Par exemple, si vous modifiez une classe dans un environnement batch, vous devez imaginer l'effet des modifications. En Lisp, vous éditez une classe et modifiez en même temps les objets eux-mêmes. Cela signifie que vous modifiez directement le comportement des objets - et non une nouvelle version d'eux après un cycle batch d'édition-compilation-liaison-exécution-test.

Dans un système Lisp, vous modifiez une classe dans un système de CAO et elle peut alors être immédiatement active. Lorsque les gens demandent si Lisp fonctionne pour les grandes équipes de logiciels, la réponse peut être que la grande équipe de logiciels n'est pas nécessaire, si vous travaillez de manière incrémentielle. Le problème à l'époque était/est que les développeurs de logiciels vraiment compétents et familiarisés avec le développement incrémental étaient (sont ?) rares.

Dans de nombreuses applications, il existe une langage de script parfois pour les développeurs originaux (et non pour les utilisateurs). En Lisp, ce n'est pas nécessaire, Lisp est son propre langage d'extension .

Answer 4

Dans le monde réel, cette fonctionnalité est principalement utilisée pour le développement et, comme beaucoup d'autres, elle ne vaut la peine d'être utilisée que dans le bon contexte.

1. programmeur personnel illumination félicité*
2. un véritable déploiement continu.
3. des accords de niveau de service sans temps d'arrêt planifié.
4. déboguer les serveurs de production.

*ne constitue pas une garantie.

---

pour moi, et je soupçonne d'autres personnes ici, le véritable avantage de ce Développement piloté par REPL est qu'il peut être indescriptiblement amusant. même addictif. Il peut parfois vraiment donner un sentiment de code artisanal. Essayez-le... Allez, essayez-le, le premier REPL est toujours gratuit :)

---

le grand attrait de ces jours-ci est un déploiement continu.

Actuellement, l'idée du déploiement continu est de modifier une chose, de tout construire (ou plutôt de tout empaqueter) puis de déployer. Avec le modèle lisp, il est en fait possible de modifier une boîte déployée (généralement une boîte qui reçoit un miroir des sessions réelles des clients) pendant qu'elle est en cours de déploiement.

juste une note pédante. vous n'éditez pas réellement les classes en cours d'exécution. vous compilez une nouvelle copie de la classe et la laissez dans un emplacement connu (une var) puis la prochaine fois qu'elle est utilisée, la nouvelle copie est trouvée et utilisée. ce n'est pas vraiment édition en cours d'exécution et plus comme le nouveau code prend effet immédiatement cela réduit la portée du processus de développement des programmes aux expressions (typiquement les fonctions).

---

un autre point qui fait saliver est l'idée d'obtenir le bénéfice de des corrections de sécurité sans avoir à déclarer de temps d'arrêt . vous pouvez effectuer une mise à niveau sans que cela ne coûte à votre ANS une partie de votre précieux "temps d'arrêt planifié". Si vous devez programmer un temps d'arrêt planifié six mois à l'avance et que vous n'en avez que deux heures, alors (pour ces pauvres âmes) cela pourrait vraiment les faire baver.

Si vous avez accès à l'application en cours d'exécution au moment de son déploiement (potentiellement (avec autorisation) sur le site d'un client), vous pouvez vous connecter à l'application en cours d'exécution et effectuer des tests sur le code existant. dans le contexte actuel sans avoir à arrêter et à connecter un débogueur. Vous n'aurez pas non plus de perte de vitesse avec un débogueur. Il est possible de faire cela sans REPL, bien que lorsque vous obtenez le repl à l'intérieur, vous pouvez alors créer du nouveau code facilement (certains diront que l'injection de chargeurs de classe dynamiques à travers le débogueur est facile) et ensuite corriger les choses. Ainsi, vous pouvez vous connecter à un serveur en cours d'exécution, découvrir qu'une fonction n'a pas réussi à se reconnecter à une base de données après une courte coupure et la reconnecter sur-le-champ.

---

comme pour toutes les constructions de programmation, il existe il n'y aura jamais de solution miracle et ce déploiement/développement continu a un inconvénient intéressant : votre programme peut être correct en mémoire et erroné sur le disque. si vous compilez une fonction, puis la cassez et enregistrez, la seule copie fonctionnelle du code est celle qui s'exécute. Il est utile d'en être conscient et de réévaluer les fichiers juste après les avoir enregistrés.

Cela peut paraître fantaisiste, alors allez vérifier comment Intégrer un REPL Clojure dans votre application de production

Answer 5

Je me souviens que quelqu'un de la NASA a décrit son expérience. Son équipe a mis en œuvre le soft utilisé dans un vaisseau spatial dans les années 70. Et ils ont effectivement modifié leur logiciel à distance à la volée lorsque certains bogues ont été découverts.

Ou imaginez que vous avez un long processus qui prend des jours pour s'exécuter et qu'à la fin il ne peut pas écrire les résultats à cause des permissions ou d'un autre petit problème.

Encore un autre exemple. Vous êtes en phase d'intégration et vous devez effectuer de nombreux petits changements. Et encore beaucoup de changements. Je rêve d'une telle possibilité en Java car actuellement il me faut 30-40 min pour reconstruire et réinstaller mon application (pour la reconstruire à nouveau en 10 min).