La programmazione scritta ha buoni ideali. Perché pensi che questo non sia mainstream? È perché non è riuscito a fornire?
La programmazione scritta ha buoni ideali. Perché pensi che questo non sia mainstream? È perché non è riuscito a fornire?
L'ho visto per la prima volta in un libro degli scritti di Knuth, e ho pensato che fosse ordinato. Poi ho provato a usare il display di programmazione letteraria per capire 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 questo mi ha sconvolto. 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 sta facendo X quando effettivamente sta facendo Y, e mi sono imbattuto nella mia parte di commenti fuorvianti. Ho sviluppato una passione per la lettura del codice per vedere cosa sta facendo abbastanza presto. La programmazione letteraria è l'antitesi di quello.
Incolperei l'effetto della rete . Affinché altre persone possano modificare il tuo codice e la documentazione, devono essere in grado di capirlo.
Questo allontana le persone da qualcosa come cweb / noweb, perché usarle richiede di imparare TeX e la sintassi specifica del programma in cima al linguaggio di programmazione che si sta utilizzando per il progetto. Questo può essere visto come un enorme spreco di tempo, specialmente se non hanno bisogno di alcuna composizione matematica che sia così grande per TeX in primo luogo. (E per molti programmatori di applicazioni, in realtà non ne hanno bisogno.) Preferiscono invece qualcosa come i commenti XML di Visual Studio, perché è già popolare e consolidato.
I luoghi in cui ho visto decollare la programmazione letterale sono nel calcolo scientifico / statistico, dove la maggior parte dei programmatori ha una formazione significativa (alias PhD) in matematica, CS o statistica, e quindi sono già familiari con LaTeX. La documentazione che scrivono è più probabile che includa molte formule complicate che sono meglio scritte in TeX, ed è più probabile che stiano programmando in R. La proporzione di programmatori R che conoscono SWeave è decisamente molto più alta di, diciamo, proporzione di programmatori C che conoscono il cweb.
Sono rimasto affascinato dal concetto di programmazione letteraria alla fine degli anni '90 mentre studiavo, e sono ancora intrigato dall'approccio di Knuth alla programmazione e alla composizione. Nient'altro che il meglio farà.
Il sistema di programmazione Literate progettato da Knuth ha fatto molto, molto di più di quello che incontra subito, cioè ha superato molte carenze nel linguaggio di programmazione sottostante che lo strumento di generazione del codice generato dal documento sorgente di Knuths, vale a dire Pascal standard.
Per chi è abbastanza fortunato da non aver provato il Pascal standard, ecco alcuni dei punti salienti.
Tutte queste cose in pratica significavano che Knuth aveva bisogno di un linguaggio di programmazione migliore (così ne ha inventato uno) e ha usato Pascal come linguaggio assembly.
La maggior parte delle lingue moderne può fare queste cose senza molto sforzo, quindi rimuovendo una parte GRANDE del lavoro che Literate Programming doveva risolvere.
Anche le lingue moderne sono più espressive e permettono di inserire più pensieri nel codice stesso.
Quindi, cosa rimane? La possibilità di generare una forma composta di documentazione dal codice sorgente e CHE esiste oggi.
Pensa a JavaDoc - l'API di runtime Java è forse il più grande pezzo di programmazione scritta disponibile oggi (eccetto che il codice non è presentato in realtà, ma potrebbe esserlo se Java fosse stato aperto sin dall'inizio). Vedi ad esempio la presentazione del framework delle collezioni su link
Credo che esistano sistemi simili per .NET e altri programmi mainstream.
Una cosa che ho scoperto quando ho avuto la mia passione con la programmazione alfabetica negli anni '90 era che attraeva persone molto appassionate che volevano fare esattamente la cosa giusta - e che implicava scrivere il proprio sistema di programmazione letterale perché nessuno esistente era abbastanza buono per loro. noweb è stato un buon tentativo di escluderlo fornendo un minimo comune denominatore per tutti, anche se, anche allora, ho trascorso la maggior parte del mio tempo sul LP a sviluppare una stampante carina per questo ...
Un altro problema è che è davvero anti-agile. In un certo senso, essere rallentato è un bene perché ti costringe a pensare più in anticipo e fare le cose per bene la prima volta. D'altra parte, documentare meticolosamente mentre vai significa che c'è una grande barriera per il refactoring del tuo codice. E se aspetti che il tuo codice si indurisca prima che tu lo faccia LP, ti ritrovi con un compito 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 di Literate Programming: vogliono risultati più rapidi (piangono solo sulla qualità quando l'app è in produzione). Nella mia esperienza personale, 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 in design-non-sense". Sì, lo so, il mio capo è un ciarlatano.
I codici di scrittura non sono in inglese.
Ai coder non piace scrivere documentazione perché non aiuta l'esecuzione del codice.
I coder non sono bravi a scrivere documentazione perché è un mezzo scarso per esprimere le loro idee.
La programmazione letteraria sembra essere l'idea di portare la documentazione al livello successivo in cui il codice è più di un ripensamento. Forse funzionerebbe, ma per molti programmatori sembra una documentazione odiosa.
Principalmente perché le persone sono MOLTO STUPIDE. Testimonianza ovvia a cui è un'infinita serie di ipotesi e incomprensioni espresse dai giovani sulla natura di questa semplice tecnica.
Le persone considerano LP come: (a) un metodo di documentazione (b) un metodo per scrivere saggi raffinati che richiedono talenti o talenti speciali (c) semplicemente non avere idea - come creatore dell'editor di programmazione Leo, di la sua stessa ammissione ecc. ecc.
LP tuttavia è semplicemente: (1) scrivere programmi in un misto di codice e frasi in un linguaggio umano (= qualsiasi), dove questi ultimi rappresentano altri blocchi di codice e / o frasi incluse. Questo è esattamente ciò che gli autori di innumerevoli libri di programmazione fanno ... e (2) è un semplice preprocessore che espande quelle frasi in umani (che diventano come nomi di subroutine incluse) per svelare il risultato NELL'ORDINE RICHIESTO DAL COMPILATORE (o interprete). Altrimenti si può espandere il testo scritto con un'altra piccola utility per includere i simboli di formattazione per trasformare la "fonte letterale" in un testo leggibile ben formattato.
I giovani non provano mai questa idea estremamente semplice - e fantasticano o immaginano motivi falsi per cui non tenteranno mai di farlo.
Fondamentalmente l'idea principale della programmazione "in pseudocodice" scritta in un linguaggio umano e poi l'espansione con una semplice utility di preprocessore HELPS MANAGE ATTENTION (limitata, una difficoltà principale per qualsiasi programma lungo), più o meno come la piegatura del codice o la divisione di il tuo programma scorre in funzioni / subroutine, necessarie per non perdere te stesso nei dettagli, ma completamente inutile per l'esecuzione della macchina.
Ci sono 2 aspetti della programmazione scritta che I do desiderio sono stati incorporati nella programmazione tradizionale - immagini incorporate (es. diagrammi di progettazione) e puntatori a tentativi precedenti e alternativi (ad esempio, "La ragione è come questo è perché ho provato in questo altro modo e non ha funzionato perché ... "). Entrambi questi aspetti possono essere gestiti con doc-comments e URI.
Perché la logica dei programmi non funziona nello stesso modo in cui parliamo. Un programma ha un flusso, condizioni e loop ben specificati.
Dopo aver codificato molto, PENSO in questi termini. Il mio cervello trasforma i problemi nel dominio di destinazione del codice eseguibile. Ed è molto più efficiente per me scriverlo in un linguaggio di programmazione di solito, piuttosto che dover fare il passaggio di trasformazione extra per rendere i miei programmi più interessanti.
In effetti, credo che i miei programmi siano già alfabetizzati ... identificatori parlanti, nomi di funzioni buone, commenti in cui ho fatto un po 'di hacker che non avrei capito subito dopo alcuni mesi.
Per concludere: il mio codice Java è più alfabetico di per sé come ogni programmazione "alfabetica" vuole essere.
Sono arrivato alla programmazione alfabetica in senso inverso - ho sognato di avere il codice organizzato come mi viene in mente, non come richiede il compilatore. 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 sia necessario che altri nella squadra lo sappiano. Questa caratteristica - "@shadow trees" - è molto promettente, anche se ha ancora un po 'buggy, ha bisogno di più occhi. E risolve anche il problema "oh no, tutto in un file grande" sia organizzando tutto in struttura ad albero sia tramite supporto per 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 inteso principalmente per Python e non avesse il supporto per il linguaggio JSP - Devo dividere manualmente il file su Leo tree!).
Lo vedo come un prezioso strumento didattico, in cui è possibile scrivere una dissertazione sul codice e quindi frammenti di codice funzionante intercalati in esso per istruire i lettori su come, come e perché del codice.
Al di fuori di un ambiente puramente educativo, penso che solo Knuth capisca davvero il modo migliore di usarlo.
È il peggiore di tutti i mondi - devi scrivere un programma per computer molto preciso e altamente specifico in una lingua molto specifica = inglese. Quindi devi scriverlo attentamente usando esattamente le frasi corrette, quindi potresti anche scrivere codice.
Leggi altre domande sui tag programming-practices literate-programming