Programmazione scritta, buona / cattiva metodologia di progettazione

10

Recentemente ho trovato il concetto di programmazione alfabetica . E l'ho trovato piuttosto intrigante. Tuttavia non sono stato incontrato con affermazioni che sia un cattivo modo di strutturare un programma. Sembra non coperto molti posti. Nemmeno qui potrei trovare alcuna domanda in merito.

La mia domanda è non sui suoi difetti o sulle modalità di gestione della documentazione. Considero la documentazione un effetto collaterale di ciò che significherebbe per il flusso della programmazione alfabetica. So che il progetto era originariamente concepito per una facile documentazione e il concetto di flusso di programmazione forward .

Il concetto di dividere il problema in piccoli problemi basati su frasi sembra essere un'idea brillante. Così faciliterà la comprensione del flusso del programma.

Una conseguenza del metodo di progettazione letterale è anche che il numero di funzioni richieste sarà limitato all'immaginazione del programmatore. Invece di definire una funzione per un determinato compito, potrebbe essere creata come scrap nel metodo literate. Ciò consentirebbe l'inserimento automatico del codice, invece di una compilazione di una funzione separata e il successivo requisito di una fase di ottimizzazione della compilazione inter-procedurale per ottenere la velocità equivalente. Infatti il primo tentativo di Donald E. Knuth ha mostrato un tempo di esecuzione inferiore, proprio per questo fatto. So che i compilatori possono fare molto di questo, tuttavia non è un mio problema.

Quindi mi piacerebbe avere un riscontro sul perché si dovrebbe considerare questa una metodologia di progettazione cattiva / buona?

    
posta zeroth 31.01.2012 - 21:06
fonte

4 risposte

9

This would yield automatic insertion of the code, instead of a separate function compilation and subsequent requirement of an inter-procedural compilation optimization step to obtain the equivalent speed

Questo è irrilevante. È stato per decenni. Puoi rimuoverlo dalla domanda, poiché non ha senso con i moderni compilatori sovvertire i loro ottimizzatori.

So I would like to get feedback of why one should consider this a bad/good design methodology?

Non c'è nessun svantaggio nella programmazione alfabetica. (Mi aspetto dozzine di voti -1 per quel sentimento.) Come praticante, non ho mai visto alcun problema.

Ci sono alcuni argomenti contro i quali tutto ammonta a "programmare in un linguaggio di livello superiore è essere sovvertito modificando il codice risultante." Destra. Nello stesso modo in cui la programmazione in C ++ viene sovvertita modificando il file .o che viene prodotto. È vero, ma irrilevante.

Scrivere programmi alfabetici significa semplicemente combinare design di alto livello e dettagliato (a livello di codice) in un unico documento, scritto con un set di strumenti adeguato che produce file compatibili con il compilatore e file compatibili con le persone.

Quando Knuth ha inventato la programmazione alfabetica, i linguaggi OO mainstream non esistevano. Pertanto una grande quantità degli strumenti originali di web e weave gli ha permesso di creare definizioni classiche per tipi di dati astratti.

Gran parte di questo è irrilevante al giorno d'oggi. Gli strumenti di programmazione letterale possono essere abbastanza semplici se si concentrano su linguaggi di programmazione moderni (o funzionali) di alto livello. C'è meno bisogno di elaborate soluzioni alternative a causa delle limitazioni di C (o Pascal o Assembler).

L'approccio alla scrittura di programmi scritti non è diverso dall'approccio alla scrittura di programmi analfabeti. Richiede ancora un'attenta progettazione, test delle unità e una codifica precisa. L'unico lavoro extra è la scrittura di spiegazioni oltre alla scrittura del codice.

Solo per questo motivo - la necessità di scrivere spiegazioni coerenti - la programmazione alfabetica è difficile per alcuni programmatori. C'è un buon numero di programmatori che hanno successo (il loro codice supera tutti i test unitari, è pulito e facile da capire) ma non sembra che possa scrivere una frase coerente nella loro lingua madre. Non so perché questo è vero.

Ci sono un numero molto grande di programmatori che sembrano avere un successo marginale e solo per sbaglio. (Ci sono abbastanza brutte domande in Stack Overflow che indicano che molti programmatori fanno fatica a cogliere anche i fondamenti.) Per i programmatori che fanno domande di overflow dello stack incoerenti, sappiamo che non possono davvero fare un buon lavoro di programmazione alfabetica, perché possono fare un buon lavoro di programmazione.

    
risposta data 31.01.2012 - 21:36
fonte
3

L'aspetto più importante della programmazione alfabetica (o anche solo un buon commento) per me non è tanto che fornisce documentazione, ma piuttosto afferma l'intento del programmatore. Conoscendo l'intento dichiarato, puoi immediatamente giudicare se il codice che segue lo fa davvero o no. Senza l'intento, devi iniziare dal presupposto che il codice sia corretto e quindi provarlo correttamente o erroneamente per induzione - che è più estenuante e dispendioso in termini di tempo, poiché spesso richiede anche familiarità con tutto il codice circostante.

L'intento così dichiarato spesso consente ad altri non familiari con il codice di entrare rapidamente e trovare errori senza dover conoscere il contesto più ampio che lo circonda.

Ovviamente, ti aiuta anche a imparare il flusso e il design di base del codice più velocemente, poiché l'inglese semplice è spesso più intuitivo dell'aritmetica dei puntatori per la maggior parte delle persone.

    
risposta data 31.01.2012 - 23:37
fonte
1

Pur essendo alquanto nuovo rispetto al concetto di programmazione della figliata (ed è quindi probabile che mi manchi completamente la barca), sembra che si allinei molto al concetto di DSL .

L'idea alla base di una DSL è quella di distillare un dominio di problemi in una semplice grammatica orientata alla lingua naturale che può essere utilizzata per costruire algoritmi per risolvere tali problemi.

Per me, la stessa idea, o almeno il fondamento di base, è la stessa o almeno strettamente connessa alla programmazione degli alfabeti.

Nel mondo groovy, ad esempio, c'è una strong spinta per usare le DSL più regolarmente e per creare nuove DSL per risolvere problemi comuni. Questa spinta arriva da entrambi gli strumenti all'interno del linguaggio (semplici builder), così come dalle librerie di base che supportano un'API basata su DSL.

Dato che la tendenza, almeno in quell'angolo del mondo, è verso programmazione alfabetica, direi che è una buona metodologia per cui lottare.

Sfortunatamente, il livello di pensiero necessario per creare un buon dsl è spesso al di là della maggior parte dei programmatori, da quello che ho visto. So che personalmente lotto con alcuni dei concetti necessari di volta in volta. Può essere questa difficoltà che ha impedito a tali tecniche di ottenere un'adozione più ampia.

È il tuo caso classico quando utilizzare lo strumento è una cosa, ma la sua creazione è su un livello completamente diverso.

Per espandere un po 'il mio punto di vista, non è tanto che i DSL sono la stessa cosa della programmazione alfabetica, ma piuttosto che rendono la programmazione molto più possibile . In particolare quando sono DSL in linguaggio naturale .

Nella versione 1.8 di groovy, la capacità di DSL del linguaggio naturale era sostanzialmente migliorata con l'aggiunta di catene di comando più potenti.

Ad esempio, le seguenti righe di codice sono programming , non solo pseudo-frasi:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Nota: l'esempio di codice proviene da Guillaume Il blog di Laforge

L'idea alla base della programmazione scritta è che il linguaggio naturale è più comprensibile per gli esseri umani e questo è ciò che conta. Le capacità di DSL del linguaggio naturale di Groovy rendono questa realtà molto più vicina, secondo me. Soprattutto quando questi DSL vengono utilizzati per creare regole di business per un'applicazione.

Essere in grado di "codificare" i componenti critici di un sistema usando il linguaggio naturale è l'essenza stessa della programmazione alfabetica. Dover interspondere il linguaggio naturale con pezzi di codice è una forma bastardata di programmazione alfabetica. Anche se utile, credo che i DSL in linguaggio naturale che ti consentono di utilizzare il linguaggio naturale come il codice stesso sono un enorme balzo in avanti.

Espandere la capacità di programmare in generale è il prossimo passo nel processo, ma in larga misura gli strumenti per farlo sono già in atto. Sì, non esiste ancora un DSL "generale", ma per domini più piccoli, la capacità è lì.

Per ulteriori esempi di questo in azione (in nessun ordine particolare):

risposta data 31.01.2012 - 22:26
fonte
-2

Penso che sia sbagliato pensare che l'LP sia una specie di DSL. Perché LP è - journal (con diagrammi, schemi, frammenti di pseudo-codice, cioè blocchi) del programma sviluppato, è architettura e così via ... È assolutamente analogo al taccuino di carta - molti sviluppatori lo usano ma dopo aver finito il programma - lascia i tuoi quaderni, documenti ...

Molto tempo fa ogni fisico, astonomo, chimico / alchimista, matematico ha i propri quaderni, manoscritti con molti schemi, informazioni necessarie, tabelle e senza di loro si può capire o ripetere la loro esperienza di successo, i suoi risultati. E sempre tra questi popoli esistono manuscreept / taccuini a caccia.

Oggi molti programmatori scrivono codice e talvolta aggiungono commenti! Il programma Byt non è solo codice - è pensieri, idee, immaginazione, concetti e quando il nuovo sviluppatore eredita il codice alieno - rompe spesso idee e concetti, crea "scappatoie" e "backdoor" diversi, spero che tu mi capisca:)

Quindi, il requisito principale per LP (come strumento!) è anche consentire tutti questi con una sintassi semplice, leggera e leggibile. Ho provato molti strumenti LP, ma oggi sto sviluppando il proprio - NanoLP ( link ) che ha lo scopo di compiacere questa richiesta.

    
risposta data 15.02.2013 - 12:20
fonte