Che aspetto ha il tuo flusso di lavoro Lisp? [chiuso]

In questo momento sto imparando Lisp, proveniente da una progressione linguistica BASIC locomotiva -> Assemblatore Z80 -> Pascal -> C -> Perl -> C # -> Ruby. Il mio approccio è quello di:

• scrivere un semplice raschietto web usando SBCL, QuickLisp, closing-html e drakma
• guarda le lezioni del SICP

Penso che funzioni bene; Sto sviluppando buoni "occhiali Lisp", in quanto ora posso leggere Lisp abbastanza facilmente. Ho anche un'idea di come funziona l'ecosistema Lisp, ad esempio Quicklisp per le dipendenze.

Quello che sto veramente manca, però, è un senso di come in realtà un lisper condito funziona .

Quando sto programmando per .NET, ho Visual Studio impostato con ReSharper e VisualSVN. Scrivo test, implemento, refactoring, mi impegno. Poi, quando ho fatto abbastanza per completare una storia, scrivo alcuni AUAT. Quindi ho dato il via a una versione di Release su TeamCity per inviare la nuova funzionalità al cliente per testare e spero l'approvazione. Se è un'app che necessita di un programma di installazione, utilizzo WiX o InnoSetup, ovviamente costruendo il programma di installazione tramite il sistema CI.

Quindi, la mia domanda è: come Lisper esperto, che aspetto ha il tuo flusso di lavoro? Lavori principalmente nel REPL o nell'editor? Come si eseguono i test unitari? Integrazione continua? Imballaggio e distribuzione? Quando ti siedi alla tua scrivania, fumando una tazza di caffè da un lato e una foto incorniciata di John McCarthy dall'altro, che cosa fai ?

Attualmente, mi sento come se stessi prendendo confidenza con la codifica Lisp, ma non con lo sviluppo di Lisp ...

La maggior parte delle persone su comp.lang.lisp e sul forum Lisp consigliano una combinazione di Emacs e SLIME, supponendo che non si desideri pagare per un'implementazione commerciale come Allegro o LispWorks. Il video SLIME illustra il processo di lavoro. Uso Emacs e SLIME per lo sviluppo di programmi personali a casa e la combinazione può essere molto efficiente.

SLIME ti offre l'integrazione tra Emacs e REPL. Quello che faccio di solito è caricare tutti i miei file, quindi aprire quello su cui sto lavorando in Emacs. Dopo aver digitato o modificato ciascuna funzione, premo C-x C-e, che esegue la definizione della funzione nella REPL. Quindi posso passare al buffer REPL e provare la funzione. Tutta la cronologia di REPL è disponibile e modificabile usando le sequenze di tasti standard di Emacs, quindi è facile ripetere le chiamate di funzione con parametri diversi.

Lavoro principalmente con Clojure ed ecco la mia configurazione:

1. Eclipse IDE (lo uso come faccio anche molto lavoro Java, a volte nello stesso progetto di Clojure)
2. Plugin antiorario per Clojure (questo include un REPL)
3. Maven per la dipendenza e la gestione delle build
4. Egit per il controllo del codice sorgente

Il flusso di lavoro durante la codifica è generalmente simile a questo:

1. Aprire un REPL, caricando tutti i file di origine correnti
2. Codice e test nel REPL
3. Quando sono soddisfatto di un po 'di codice, copia / incolla di nuovo nel file di origine
4. Occasionalmente riavviare il REPL (o quando ho incasinato uno spazio dei nomi irrevocabilmente, o solo per verificare che tutto funzioni ancora nei file sorgente)
5. Scrivi anche test nei file di origine, che vengono eseguiti automaticamente da ogni build di Maven. A volte i test informali che ho appena fatto al REPL vengono trasformati direttamente in test unitari.
6. Impegnati ecc. A questo punto - praticamente un flusso di lavoro di sviluppo regolare

Nel complesso non è troppo diverso da un normale flusso di lavoro Java / C # a parte l'uso più interattivo di REPL durante lo sviluppo.

Per integrare le altre risposte, faccio una combinazione del tipo di sviluppo "Rifletti attentamente sul problema, poi scrivi la soluzione" e "Inizia con un sostituto e batti il ​​programma in modo iterativo". Di solito è nel mezzo. Quello che faccio è iniziare con un'idea generale di come voglio che appaia il mio programma, quindi inizio a scriverlo, cercando di acquisire nuove conoscenze sul dominio del problema mentre procedo, al fine di rivedere il mio approccio. In pratica ciò significa che faccio molta sperimentazione e scrivo molto codice da buttare via. Provo approcci diversi e posso cambiare direzione molto velocemente. Lisp è buono per questo tipo di sviluppo. Ecco perché non mi piace tanto il TDD, devo sapere prima cosa voglio fare, al fine di TDD in modo efficace.

Un'altra cosa importante che cerco di fare è riflettere maggiormente sul protocollo tra le diverse parti di un programma. A differenza di altri linguaggi OO, In Common Lisp CLOS si concentra maggiormente sul concetto di funzione generica, i metodi IOW vivono al di fuori delle classi e sono al centro dello sviluppo. A volte comincio con una serie di GF che definiscono il protocollo che desidero, scrivo una semplice implementazione e la utilizzo per arricchire il protocollo, prima di scrivere una vera implementazione. Supponiamo che stia scrivendo un livello che memorizza un sacco di post sul blog, potrei avere una serie di GF che definiscono il modo in cui i post sul blog vengono creati, modificati e cercati e scriverei una semplice implementazione che salvi i post del blog in un elenco in memoria e dopo che sono soddisfatto del mio protocollo, scrivo un'implementazione che salva i post del blog in un database o li scrive in file.

Lisp rende così semplice cambiare direzione e adottare un approccio diverso quando sai che la tua soluzione attuale non è ottimale e cerco di massimizzarla.

Anche punto importante: usa il tuo ambiente al massimo, scopri come usare diverse impostazioni di compilazione per compilare il tuo codice con più informazioni di debug, approfitta del fatto che lisp può essere sia compilato che interpretato. Usa le strutture introspettive di lisps, come il MOP, usa le funzioni slime per cercare la documentazione, usa l'ispettore per guardare dentro gli oggetti, consulta regolarmente l'iperspec, tratta il tuo sistema più come un sistema operativo, che un compilatore statico per il tuo codice, è molto di più potente di così.

Per un principiante, lisp non è tanto una vittoria su pitone e rubino, ma man mano che acquisisci maggiore esperienza, ottieni enormi vittorie in ambienti minori.

Ancora più importante, devi divertirti e amare questa lingua, a volte è semplicemente troppo facile scoraggiarsi e usare le lingue blub attualmente popolari. Se rimani con lisp, ti ripagherà.

Tendo a lavorare in un editor che ha una connessione a un REPL (in genere, modifica in emacs e usa SLIME come bridge per un ambiente Common Lisp). Tendo a iniziare sia "in basso" che "in alto", lavorando verso il centro, rivedendo il design mentre procedo.

Per quanto riguarda i test, è per questo che ho un REPL. Trovo che aiuti testare il codice mentre vado. A volte scriverò più test formali o benchmark mentre procedo (di solito una volta che sono nella fase di ottimizzazione). Avere un'implementazione più lenta e nota di una funzionalità, sperimentare (in una finestra dell'editor) un codice per una versione ottimizzata, inviarlo al codice lisp sottostante e verificare che sia più veloce e restituisca gli stessi risultati del più lento codice.

Per quanto riguarda il packaging, ho un codice di utilità che mi aiuta a impacchettare progetti installabili ASDF, a schiaffeggiarli in un repository di download e gestire il controllo delle versioni.