Perché non è mainstream la programmazione alfabetizzata? [chiuso]

La programmazione alfabetica ha buoni ideali. Perché pensi che questo non sia mainstream? È perché non è riuscito a consegnare?

L'ho visto per la prima volta in un libro degli scritti di Knuth e ho pensato che fosse pulito. Quindi ho provato a usare il display di programmazione letteraria per comprendere cosa stava succedendo nel programma e l'ho trovato più difficile di quanto sembrasse. Potrebbe essere stato che ero troppo abituato a consultare gli elenchi dei programmi, ma sembrava confuso.

Poi ho guardato il codice sorgente e quello mi ha spento e poi lì. Dovrei imparare a scrivere programmi in un modo completamente nuovo, con meno corrispondenza tra il testo del programma e ciò che il compilatore ha visto, e non ho visto alcun beneficio corrispondente.

Inoltre, le persone possono scrivere argomenti lunghi e convincenti sul fatto che il codice stia facendo X quando in realtà sta facendo Y, e ho incontrato la mia parte di commenti fuorvianti. Ho sviluppato una passione per la lettura del codice per vedere cosa sta facendo abbastanza presto. La programmazione alfabetica ne è l'antitesi.

Darei la colpa all'effetto rete . Per consentire ad altre persone di modificare il codice e la documentazione, devono essere in grado di capirlo.

Questo allontana le persone da qualcosa come cweb / noweb, perché usarli richiederebbe di imparare TeX e la sintassi specifica del programma in aggiunta al linguaggio di programmazione che stai usando per il progetto. Questo può essere visto come un'enorme perdita di tempo, soprattutto se non hanno bisogno di alcun tipo di composizione matematica che è un grande richiamo per TeX in primo luogo. (E per molti programmatori di applicazioni, non ne avranno davvero bisogno.) Invece preferiscono qualcosa come i commenti XML di Visual Studio, perché è già popolare e consolidato.

I posti in cui ho visto decollare la programmazione letteraria sono nel calcolo scientifico / statistico, dove la maggior parte dei programmatori ha una formazione significativa (alias PhD) in matematica, CS o statistica, e quindi ha già familiarità con LaTeX. La documentazione che scrivono è più probabile che includa molte formule complicate che sono meglio scritte in TeX e che hanno maggiori probabilità di programmare in R. La percentuale di programmatori R che conoscono SWeave è decisamente molto più alta di, diciamo, proporzione di programmatori C che conoscono cweb.

Sono rimasto affascinato dal concetto di programmazione letteraria alla fine degli anni '90 mentre studiavo e sono ancora incuriosito dall'approccio di Knuths alla programmazione e alla composizione. Nient'altro che il meglio farà.

Il sistema di programmazione letteraria progettato da Knuth ha fatto molto, molto di più di quanto non sembri immediatamente, superando molte carenze nel linguaggio di programmazione sottostante che lo strumento di generazione del codice ha generato dal documento sorgente di Knuths, ovvero lo standard Pascal.

Per quelli abbastanza fortunati da non aver provato lo Standard Pascal, ecco alcuni dei punti salienti.

• Per rendere più semplice avere un compilatore single-pass, le specifiche del linguaggio dicevano che tutte le dichiarazioni dovevano arrivare in un certo ordine. Dalla pagina di Wikipedia: "Ogni procedura o funzione può avere le proprie dichiarazioni di goto etichette, costanti, tipi, variabili e altre procedure e funzioni, che devono essere tutte in questo ordine." Questo significava che non potevi raggruppare le tue cose logicamente insieme nel file sorgente.
• La gestione delle stringhe era più noiosa che nella pianura C.
• Gli identificatori non potevano avere una lunghezza arbitraria.
• Molte altre cose che non ricordo più.

Tutte queste cose sostanzialmente significavano che Knuth aveva bisogno di un linguaggio di programmazione migliore (così ne inventò uno) e usava Pascal come linguaggio di assemblaggio.

La maggior parte dei linguaggi moderni può fare queste cose senza troppi sforzi, quindi rimuovendo una GRANDE parte del lavoro che la Programmazione Letterata avrebbe dovuto risolvere.

Anche i linguaggi moderni sono più espressivi e consentono di inserire più codice nel codice stesso.

Quindi, cosa rimane? La capacità di generare una forma composta di documentazione dal codice sorgente e CHE esiste oggi.

Basti pensare a JavaDoc: l'API Java runtime è forse il più grande pezzo di Literate Programming disponibile oggi (tranne per il fatto che il codice non è effettivamente presentato, ma POTREBBE essere stato se Java fosse open source dall'inizio). Vedi ad esempio la presentazione del framework delle collezioni su http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Credo che esistano sistemi simili per .NET e altri programmi tradizionali.

Una cosa che ho scoperto quando ho avuto la mia avventura con la programmazione letterata negli anni '90 è che ha attratto persone molto appassionate che volevano fare esattamente The Right Thing - e ciò ha comportato la scrittura del proprio sistema di programmazione letterato perché nessuno esistente era abbastanza buono per loro. noweb è stato un buon tentativo di interromperlo fornendo un minimo comune denominatore abbastanza buono per tutti, anche se anche allora ho trascorso la maggior parte del mio tempo LP a sviluppare una bella stampante per questo ...

Un altro problema è che è davvero anti-agile. In un certo senso, essere rallentati è positivo perché ti costringe a pensare più in anticipo e fare le cose bene la prima volta. D'altra parte, documentare meticolosamente mentre procedi significa che c'è un grande ostacolo al refactoring del tuo codice. E se aspetti fino a quando il tuo codice non sarà indurito prima di LP-ify, finirai con un'attività di documentazione di più giorni, che può davvero fermarti nelle tue tracce.

Secondo le mie modeste opinioni, molte aziende hanno una cultura che è l'opposto degli obiettivi della programmazione alfabetica: vogliono risultati più rapidi (piangono solo sulla qualità quando l'app è in produzione). Nella mia esperienza, i miei capi si sono rifiutati di capire che risultati più rapidi non significano "un programma eseguibile il giorno dopo averlo chiesto". Per loro, se uno sviluppatore non è impegnato a digitare sulla tastiera, non sta lavorando, "sta sprecando il suo tempo nel design senza senso". Sì, lo so, il mio capo è un buco del culo.

I programmatori scrivono codice non in inglese.

Ai programmatori non piace scrivere la documentazione perché non aiuta l'esecuzione del codice.

I programmatori non sono bravi a scrivere documentazione perché è un mezzo mediocre per esprimere le loro idee.

La programmazione alfabetica sembra essere l'idea di portare la documentazione al livello successivo in cui il codice è più un ripensamento. Forse funzionerebbe, ma per la maggior parte dei programmatori sembra una documentazione odiosa.

Principalmente perché le persone sono MOLTO stupide. Un'evidente testimonianza a cui è un flusso infinito di ipotesi e incomprensioni espresse dai giovani sulla natura di questa semplice tecnica.

La gente considera LP come: (a) un metodo di documentazione (b) un metodo per scrivere alcuni saggi raffinati che richiedono alcune abilità o talenti speciali (c) semplicemente non hanno idea - come il creatore dell'editor di programmazione Leo, per sua stessa ammissione ecc. ecc. ecc.

LP è semplicemente: (1) scrivere programmi in una combinazione di codice e frasi in un (= qualsiasi) linguaggio umano, dove quest'ultimo rappresenta altri pezzi di codice e / o frasi incluse. Questo è esattamente ciò che fanno gli autori di innumerevoli libri di programmazione. interprete). Altrimenti si può espandere il testo scritto con un'altra piccola utility per includere simboli di formattazione per trasformare la "fonte letterata" in un bel testo ben formattato.

I giovani non provano mai questa idea estremamente semplice - e nemmeno fantasticare o immaginare falsi motivi per cui non proveranno mai a farlo.

Fondamentalmente l'idea principale di programmare "in pseudocodice" scritto in un linguaggio umano e poi di espanderlo con una semplice utility di preprocessore AIUTA GESTIONE ATTENZIONE (limitata, una difficoltà principale per qualsiasi programma longish), praticamente come la piegatura del codice o la divisione del flusso del programma in funzioni / subroutine, necessarie per non perdersi nei dettagli, ma del tutto inutili per l'esecuzione della macchina.

Ci sono 2 aspetti di programmazione letterata che io faccio desiderio sono stati inseriti nella programmazione principale - immagini incorporato (ad esempio, schemi di progettazione) e puntatori ai tentativi precedenti e alternativi (ad esempio, "La ragione è che questo è perché ho provato questo altro modo e non ha funzionato perché ... "). Entrambi questi aspetti possono essere gestiti con commenti doc e URI.

Perché la logica dei programmi non funziona allo stesso modo in cui parliamo. Un programma ha un flusso ben specificato, condizioni e loop.

Dopo aver programmato molto, PENSO in questi termini. Il mio cervello trasforma i problemi nel dominio target del codice eseguibile. Ed è molto più efficiente per me scrivere questo in un linguaggio di programmazione solitamente, piuttosto che dover fare il passo di trasformazione extra per rendere i miei programmi letterati.

In effetti, credo che i miei programmi siano già alfabetizzati ... parlando di identificatori, nomi di buone funzioni, commenti in cui ho fatto un po 'di hacker che non avrei capito immediatamente dopo alcuni mesi.

Per concludere: il mio codice Java è più alfabetizzato da solo come ogni programmazione "alfabetizzata" vuole essere.

Ho imparato a programmare al contrario: ho sognato di organizzare il codice secondo le mie esigenze, non come il compilatore lo richiede. Ho trovato Leo quasi ideale per questo scopo. Supporta anche il monitoraggio dei file modificati all'esterno. Questi file non devono contenere alcun markup speciale, quindi posso usare Leo per me stesso senza che gli altri membri del team lo sappiano. Questa funzione - "@shadow trees" - è molto promettente, anche se ancora buggy, ha bisogno di più bulbi oculari. E risolve anche il problema "oh no, tutto in un unico grande file" sia organizzando tutto in struttura ad albero che supportando i file esterni.

Per me, contrariamente al nome, la "programmazione alfabetica" non riguarda affatto la documentazione. Non ho più documentazione di prima. Si tratta di avere una struttura che mi aiuta a non perdersi . Lo giuro soprattutto quando gestisco i file JSP di behemoth (e che nonostante Leo fosse originariamente destinato principalmente a Python e non abbia il supporto per il linguaggio JSP, devo dividere il file nell'albero di Leo manualmente!).

Lo vedo come un prezioso strumento di insegnamento, in cui è possibile scrivere una tesi sul codice, e quindi frammenti di codice funzionante interlacciati in esso per istruire i lettori su come, cosa e perché del codice.

Al di fuori di un ambiente puramente educativo, penso che solo Knuth capisca davvero come utilizzarlo al meglio.

È il peggiore di tutti i mondi: devi scrivere un programma per computer altamente corretto e altamente specifico in una lingua non specifica = inglese. Quindi devi scriverlo con cura usando esattamente le frasi corrette, quindi potresti anche semplicemente scrivere codice.