Literate programmering (GP; English Literate Programming ) är ett koncept, metodik för programmering och dokumentation, där programmet består av prosa på naturligt språk varvat med makrosubstitutioner och kod på programmeringsspråk [1] . Termen och själva konceptet föreslogs av Donald Knuth 1981 när han utvecklade ett datorlayoutsystem Τ Ε Χ .
Läskunnig programmering är som förklaringar i programmeringsföreläsningar med fraser i " pseudokod " på naturligt språk. De ger klarhet till komplex kod och döljer många andra kapslade abstraktioner och kod i ett formellt programmeringsspråk under en fras.
GP är på sätt och vis "programmering i pseudokod" med godtyckliga fraser, som sedan utökas som makron med hjälp av ett verktyg från en källfil som innehåller både dokumenterade textförklaringar av begrepp, själva koden och pseudokod.
Programmet är med andra ord inte byggt som en stigande eller fallande hierarki, utan som ett "sammanhängande nätverk av begrepp" (därav namnet på det första GP-systemet - "Web") och skapas som en "ström av tanke" som passerar genom detta nätverk på ett sammanhängande, logiskt sätt, vilket externt får beskrivningen att se ut som en litterär essä. Presentationsordningen visar sig vara oberoende av språköversättarens krav.
Låt oss ändra de traditionella prioriteringarna för att skapa program: istället för att tänka på vår uppgift som att skapa instruktioner "Vad ska jag göra?" för datorn kommer vi att fokusera på att förklara för andra människor beskrivningarna av vår vision av vad datorn ska göra under kontroll av programmet.
— Donald Knuth , http://community.livejournal.com/ru_perl/249441.htmlDet GP-system som Knuth föreslog som ett alternativ till den " strukturerade programmeringen " på 1970-talet, trots positiva recensioner, antogs inte allmänt på grund av bristen på verktygsstöd och deras integration [2] .
Ett annat problem var GPU:s fokus på batchbearbetning , medan programmeringssystem alltmer fokuserades på WYSIWYG- verktyg [2] .
Dessutom har spridningen av HP hindrats av missuppfattningen att "läskunniga program" borde vara monolitiska och att HP är motsatsen till hypertext [2] .
Många tror att GPU:n bara är ett dokumentationssystem eller ett formateringssystem för vanliga kommentarer. Faktum är att ett program med få eller inga kommentarer kan skrivas med hjälp av GP-metoden, precis som utförliga anteckningar i sig själva inte skapar en GP-metod.
Det vanligaste missförståndet hänför sig till makrosystemets roll, som låter dig bygga godtyckliga system av abstraktioner över abstraktioner, och till att ändra ordningen på bitar från maskinorienterad till den som kräver tänkande. Därför är det helt fel att betrakta användningen av gränssnittsdokumentationssystem som JavaDoc, doxygen, DOC++, autoduck, POD som GPU-programmering.
En annan missuppfattning är att D. E. Knuth ville fixa "top-down"-metoden i utvecklingen av mjukvarusystem. Faktum är att han föreslår att man kombinerar uppifrån och ner och nedifrån och upp-metoder, enligt ett citat i boken TeX: The program: “ But the author suggests that the best way to understand this program is to follow pretty much the order of TeX:s komponenter som de visas i den WEB-beskrivning du nu läser, eftersom den nuvarande beställningen är avsedd att kombinera fördelarna med "bottom up" och "top down" tillvägagångssätt för problemet att förstå ett något komplicerat system. »