Come si presenta il tuo flusso di lavoro Lisp? [chiuso]

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

SLIME ti offre l'integrazione tra Emacs e REPL. Quello che faccio in genere è 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 nel REPL. Quindi posso passare al buffer REPL e provare la funzione. Tutta la cronologia di REPL è disponibile e modificabile utilizzando sequenze di tasti standard di Emacs, quindi è facile ripetere le chiamate di funzione con parametri diversi.

Lavoro principalmente con Clojure, e qui c'è il mio setup:

1. Eclipse IDE (io uso questo dato che anche io lavoro molto su Java, a volte nello stesso progetto di Clojure)
2. Plug-in antiorario per Clojure (questo include un REPL)
3. Maven per dipendenza e gestione build
4. Egit per il controllo del codice sorgente

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

1. Apri un REPL, caricando tutti i file sorgente correnti
2. Codice e prova nella REPL
3. Quando sono soddisfatto di un codice, copia / incolla nuovamente nel file sorgente
4. Di tanto in tanto riavvia il REPL (o quando ho incasinato un namespace in modo irrevocabile, o semplicemente per controllare che tutto funzioni ancora nei file sorgente)
5. Scrivi anche test nei file sorgente, 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. Conferma ecc. a questo punto - praticamente un regolare flusso di lavoro di sviluppo

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

Per completare le altre risposte, faccio una combinazione del tipo "Pensa al problema, quindi annota la soluzione" e inizia con uno stile "repl" e batte il tuo programma in forma iterativa. Di solito è nel mezzo. Quello che faccio è iniziare con un'idea generale di ciò che voglio che il mio programma assomigli, e poi comincio a scriverlo, cercando di acquisire nuove conoscenze sul dominio del problema mentre vado, al fine di rivedere il mio approccio. In pratica ciò significa che faccio molta sperimentazione e scrivo un sacco di codice trowway. Provo approcci diversi e posso cambiare direzione molto velocemente. Lisp è buono per questo tipo di sviluppo. Ecco perché non mi piace così tanto TDD, devo sapere cosa voglio fare per primo, al fine di TDD in modo efficace.

Un'altra cosa importante che cerco di fare è pensare di più al protocollo tra le diverse parti di un programma. A differenza di altri linguaggi OO, In Common Lisp CLOS si concentra maggiormente sul concetto di una funzione generica, i metodi IOW vivono al di fuori delle classi e sono al centro dello sviluppo. A volte inizio con una serie di GF che definiscono il protocollo che voglio, scrivo una semplice implementazione e la uso per dare corpo al protocollo, prima di scrivere una vera implementazione. Diciamo che sto scrivendo un livello che memorizza un gruppo di post del blog, potrei avere una serie di GF che definiscono come i post dei blog vengono creati, modificati e cercati, e vorrei scrivere una semplice implementazione che salva 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ì facile cambiare direzione e fare un approccio diverso quando sai che la tua attuale soluzione è subottimale che cerco di massimizzare.

Un altro punto importante: sfruttare appieno il proprio ambiente, imparare a utilizzare diverse impostazioni di compilazione per compilare il codice con più informazioni di debug, approfittare del fatto che il lisp può essere sia compilato sia interpretato. Usa strutture lisps introspettive, come il MOP, usa le funzioni di slime per cercare la documentazione, usa l'ispettore per guardare gli oggetti, consultare regolarmente l'iperspec, trattare il tuo sistema più come un sistema operativo, piuttosto che un compilatore statico per il tuo codice, è molto di più potente di quello

Per un principiante, il lisp non è tanto una vittoria su Python e Ruby, ma man mano che ne hai più esperienza, ottieni enormi vittorie su ambienti minori.

La cosa più importante è che devi divertirti e amare questo linguaggio, a volte è facile scoraggiarti e usare i blub linguaggi attualmente popolari. Se ti attacchi con la chiarezza, ti ripagherà.

Tendo a lavorare in un editor che ha una connessione a un REPL (in genere, la modifica in emacs e l'utilizzo di SLIME come bridge in un ambiente Common Lisp). Tendo ad avviare sia "in basso" che "in alto", lavorando verso il centro, rivedendo il design mentre procedo.

Per quanto riguarda i test, ecco perché ho una REPL. Trovo che aiuta a testare il codice mentre vado. A volte scriverò test o benchmark più formali (solitamente una volta che sono nella fase di ottimizzazione). Avere un'implementazione più lenta e meglio conosciuta di una funzionalità, sperimentare (in una finestra dell'editor) con il 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 la pacchettizzazione, ho un codice di utilità che mi aiuta a comprimere progetti installabili su ASDF, li schiaffo in un repository di download e gestisco il controllo delle versioni.