Scalare la programmazione alfabetica?

Question

Saluti. Ho esaminato un po 'la Literate Programming ora e mi piace l'idea alla base: fondamentalmente scrivi un po' di carta sul tuo codice e scrivi quante delle decisioni di progettazione, il codice che probabilmente circonda il modulo, i meccanismi interni di il modulo, i presupposti e le conclusioni risultanti dalle decisioni di progettazione, dalla potenziale estensione, tutto ciò può essere scritto in modo piacevole usando tex. Certo, il primo punto: è documentazione. Deve essere aggiornato, ma non dovrebbe essere così male, perché la modifica dovrebbe avere una giustificazione e puoi scriverla.

Tuttavia, in che modo la programmazione di Literate si scala in misura maggiore? Nel complesso, la programmazione alfabetica è ancora solo testo. Testo leggibile da umani, ovviamente, ma comunque testo, e quindi è difficile seguire sistemi di grandi dimensioni. Ad esempio, ho rielaborato gran parte del mio compilatore per usare > > e un po 'di magia per concatenare i passi di compilazione insieme, perché alcuni " x.register_follower (y); y.register_follower (z); y.register_follower (a); ... " è diventato davvero ingombrante e lo ha cambiato in x > > y > > z > > a reso un po 'meglio, anche se questo è anche al suo punto di rottura.

Quindi, in che modo Literate Programming si adatta a sistemi più grandi? Qualcuno prova a farlo?

Il mio pensiero sarebbe di usare LP per specificare i componenti che comunicano tra loro usando flussi di eventi e li incatenano tutti insieme usando un sottoinsieme di graphviz. Questa sarebbe un'estensione abbastanza naturale di LP, in quanto è possibile estrarre una documentazione - un diagramma del flusso di dati - dalla rete e anche generare codice da essa molto bene. Che ne pensate?

- Tetha.

Answer 1

Ottima domanda. La motivazione per la programmazione alfabetica non sparirà mai, ma penso che dovrebbe essere trattato come fluido. Significa "dare una pausa al lettore ed educarli a ciò che stai cercando di fare". Non credo significhi " rendere il tuo codice davvero prolisso " ;.

Detto questo, il lettore dovrà impegnarsi, a seconda di ciò che già sa. Presumibilmente il codice merita di essere compreso e nulla viene offerto gratuitamente.

Penso anche che significhi molto più che creare semplicemente un codice leggibile. Molto probabilmente il motivo per cui qualcuno sta leggendo il codice è perché devono apportare una modifica. Dovresti anticipare le possibili modifiche che potrebbero essere necessarie e dire loro come farlo, se necessario.

Answer 2

Il libro "Rendering basato fisicamente" (pbrt.org) è il miglior esempio di programmazione alfabetica su larga scala di cui sono a conoscenza. Il libro implementa un sistema di rendering completo e sia il testo del libro che il codice raytracer sono generati dallo stesso "sorgente".

In pratica, ho scoperto che usare semplicemente un sistema come Doxygen e scavare davvero e sfruttare tutte le sue funzionalità è meglio di tutto ciò che è "letterato". programmazione, ad eccezione di cose come questa, ad esempio libri di testo, materiale didattico.

Answer 3

Ho programmato letteralmente con WEB circa 15 anni fa. Più di recente ho provato a estrarre il codice da un wiki e generare documentazione da un ambiente Squeak Smalltalk.

La parte dal basso verso l'alto può essere gestita relativamente bene generando documenti da framework TDD / BDD, ma LP si concentra sulla spiegazione del codice al lettore.

Ci sono alcuni problemi:

• la storia da raccontare è diversa per i diversi stakeholder / lettori;
• la struttura del progetto nella maggior parte degli ambienti non è la struttura necessaria per la narrazione;
• manca il supporto per i successivi perfezionamenti / divulgazioni;
• oltre al supporto del testo per le immagini è necessario;
• dai commenti nel sistema di controllo del codice sorgente si può ricavare come è stato costruito il sistema. La storia dovrebbe essere come il sistema avrebbe potuto essere costruito (con il senno di poi perfetto).

Perché LP funzioni per sistemi più grandi, è necessario un supporto IDE migliore rispetto a un wiki o un browser oggetti.

Answer 4

  

" Nel complesso, la programmazione alfabetica è   ancora solo testo "

False.

I diagrammi vanno bene.

  

Il mio pensiero sarebbe quello di utilizzare LP per specificare i componenti che comunicano tra loro utilizzando flussi di eventi

Questa è solo architettura e va bene.

  

puoi estrarre una documentazione - un diagramma del flusso di dati - dalla rete e anche generare codice da essa molto bene. Cosa ne pensi?

I diagrammi di flusso dei dati non sono poi così utili per la generazione di codice dettagliato. Sono un utile sommario, non una precisa fonte di informazioni.

Un buon strumento di scrittura (come LaTex) può codificare il diagramma nel documento. Probabilmente potresti trovare una via per il diagramma da altre parti della documentazione.

Bottom Line

A lungo termine, è meglio generare il diagramma come riepilogo del testo.

Perché?

I diagrammi elidono intenzionalmente i dettagli. Un diagramma è un riepilogo o una panoramica. Ma come fonte di codice, i diagrammi sono terribili. Al fine di fornire tutti i dettagli, i diagrammi diventano molto disordinati.

Ma una sintesi schematica di alcuni altri markup LP funzionerà bene.

Answer 5

pbrt è un ray tracer basato nello stile letterato per l'educazione dei laureati in informatica ( e me), è un sistema su larga scala moderatamente. Come programmatore non specializzato questo livello di documentazione è piuttosto essenziale per capire cosa fa il programma e perché lo fa.

Ho anche accesso a un renderizzatore di ricerca, in Java, che è ben scritto ma relativamente privo di documenti ma per alcuni documenti SIGGRAPH. Anche questo è relativamente comprensibile, ma ho accesso anche agli autori.

Ho anche usato ImageJ e ho guardato sotto il cappuccio di Java sottostante - è piuttosto difficile da seguire senza un'idea della filosofia sottostante.

Riassumendo, la mia opinione è che la programmazione alfabetica sia fantastica se qualcuno riesce a trovare il tempo per farlo bene e questo è probabilmente in ambito educativo. È difficile vederlo essere fatto nella produzione di codici commerciali. Sono scettico sull'idea che il codice possa essere interamente auto-documentato.

Answer 6

L'idea alla base della programmazione alfabetica è l'enfasi sulla documentazione, con il codice cosparso attraverso la documentazione, piuttosto che i commenti sparsi attraverso il codice.

Questa è una filosofia essenzialmente diversa e differenze come nomi di variabili più lunghi, spazi dei nomi e classi non influiscono sulla filosofia. La programmazione alfabetica sostiene nomi di variabili significativi.

Adatta a sistemi più grandi, perché il rapporto base tra documentazione e codice si ridimensiona linearmente con la dimensione del codice.

Answer 7

La programmazione alfabetica è stata sviluppata in un'era in cui i nomi delle variabili e delle funzioni non erano semplicemente possibili. Per questo motivo, il codice non era davvero leggibile.

Ovviamente sono successe molte cose da allora.

Nel mondo di oggi, il codice stesso è la documentazione, quindi il termine "codice auto-documentante". La realizzazione è che nessun insieme di commenti o documentazione esterna potrà mai rimanere sincronizzato con il codice sottostante. Quindi, l'obiettivo di molti programmatori di oggi è scrivere il codice in modo che sia leggibile dagli altri.

Answer 8

Prova NanoLP - Strumento estensibile LP, supporta molti formati di documenti (Markdown, OpenOffice, Creole, TeX, Asciidoc e altri), importazione di altri programmi LP, template e altro. L'utente può aggiungere i propri comandi / macro (in Python), ad esempio per eseguire un'importazione speciale, ad esempio da VCS ... http://code.google.com/p/nano-lp