Kompetent programmering

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 11. juli 2015; checks kræver 17 redigeringer .

Literate programmering (GP; English  Litrate Programming ) er et koncept, metodologi for programmering og dokumentation, hvor programmet består af prosa i naturligt sprog afbrudt med makrosubstitutioner og kode i programmeringssprog [1] . Udtrykket og selve konceptet blev foreslået af Donald Knuth i 1981, da han udviklede et computerlayoutsystem Τ Ε Χ .

Literær programmering er som forklaringer i programmeringsforelæsninger ved hjælp af sætninger i " pseudokode " i naturligt sprog. De bringer klarhed til kompleks kode og skjuler mange andre indlejrede abstraktioner og kode i et formelt programmeringssprog under én sætning.

GP er i en vis forstand "programmering i pseudokode" med vilkårlige sætninger, som derefter udvides som makroer ved hjælp af et hjælpeprogram fra en kildefil, der indeholder både dokumenterede tekstmæssige forklaringer af begreber, selve koden og pseudokode.

Essence of approach

Programmet er med andre ord ikke bygget op som et stigende eller faldende hierarki, men som et "indbyrdes afhængigt netværk af begreber" (deraf navnet på det første GP-system - "Web") og er skabt som en "tankestrøm" forbi. gennem dette netværk på en sammenhængende, logisk måde, som udadtil får beskrivelsen til at ligne et litterært essay. Præsentationsrækkefølgen viser sig at være uafhængig af sprogoversætterens krav.

Lad os ændre de traditionelle prioriteter i at skabe programmer: i stedet for at tænke på vores opgave som at skabe instruktioner "Hvad skal man gøre?" for computeren vil vi fokusere på at forklare andre mennesker beskrivelserne af vores vision om, hvad computeren skal gøre under programmets kontrol.

Donald Knuth , http://community.livejournal.com/ru_perl/249441.html

Accept

Det GP-system, som Knuth foreslog som et alternativ til den " strukturerede programmering " i 1970'erne, på trods af positive anmeldelser, blev ikke bredt vedtaget på grund af manglen på værktøjsstøtte og deres integration [2] .

Et andet problem var GPU'ens fokus på batchbehandling , mens programmeringssystemer i stigende grad blev fokuseret på WYSIWYG -værktøjer [2] .

Derudover er spredningen af ​​HP blevet hæmmet af den misforståelse, at "literate programmer" skal være monolitiske, og at HP er det modsatte af hypertekst [2] .

Mange mennesker tror, ​​at GPU'en blot er et dokumentationssystem eller et formateringssystem til almindelige kommentarer. Faktisk kan et program med få eller ingen kommentarer skrives ved hjælp af GP-tilgangen, ligesom detaljerede noter i sig selv ikke skaber en GP-tilgang.

Den mest almindelige misforståelse relaterer sig til makrosystemets rolle, som giver dig mulighed for at bygge vilkårlige abstraktionssystemer over abstraktioner og til at ændre rækkefølgen af ​​brikker fra maskinorienteret til den, der kræver tænkning. Det er således helt forkert at overveje brugen af ​​grænsefladedokumentationssystemer som JavaDoc, doxygen, DOC++, autoduck, POD som GPU-programmering.

En anden misforståelse er, at D. E. Knuth ønskede at rette op på "top-down"-tilgangen i udviklingen af ​​softwaresystemer. Faktisk foreslår han at kombinere top-down og bottom-up tilgange, som følger af et citat i bogen TeX: The program: “ Men forfatteren foreslår, at den bedste måde at forstå dette program på er at følge stort set rækkefølgen af TeX's komponenter, som de optræder i den WEB-beskrivelse, du nu læser, da nærværende bestilling har til formål at kombinere fordelene ved "bottom up" og "top down" tilgange til problemet med at forstå et noget kompliceret system. »

Eksisterende værktøjer

Noter

  1. Nogle gange kaldes metoden billedligt for "litterær programmering"
  2. 1 2 3 Sametinger, 1997 , 18. Litteraturprogrammering.

Litteratur

Links