Språkorienterad programmering (LOP) ( English Language Oriented Programming ), även Divergent utveckling ( engelsk middle out development ), även metallanguage abstraction , även Utveckling baserad på ett domänspecifikt språk ( English DSL-Based Development ) [1] - programmeringsparadigm , som består i att dela upp mjukvaruutvecklingsprocessen i utvecklingsstadiet för domänspecifika språk (DSL) och beskriva den faktiska lösningen av problemet med hjälp av dem. Stadier kan genomföras sekventiellt eller parallellt, en gång eller rekursivt [2] [1] ; DSL:er kan implementeras beroende eller oberoende av och har en eller flera implementeringar.
LOP är utformad för att separera komplexitet: den maskinorienterade delen av koden (lågnivåfunktionalitet) och den mänskligt orienterade delen (den faktiska lösningen av det tillämpade problemet) utvecklas oberoende av varandra, vilket eliminerar den exponentiella tillväxten av resulterande komplexitet för att utveckla hela projektet och löser problemet med komplexitet som ett grundläggande programmeringsproblem [2] , beskrivet av Frederick Brooks i den berömda uppsatsen " Det finns ingen silverkula ", på grund av vilken det är omöjligt att öka produktiviteten hos programmerare även i en storleksordning genom att helt enkelt förbättra arbetsverktygen. De flesta andra fördelar följer direkt av detta .
Fördelarna med att begränsa specialiseringen av språk diskuterades redan i mitten av 1980-talet [3] , och fördelarna med att höja språknivån mycket tidigare [4] , men DSL-orienterad utveckling bildades som en självständig metod först i mitten av 1990-talet [ ⇨ .
Att använda DSL istället för allmänna språk ökar avsevärt nivån av kodabstraktion, vilket gör att du kan utveckla snabbt och effektivt och skapa program som är enkla att förstå och underhålla; och gör det också möjligt eller avsevärt förenklar lösningen av många problem relaterade till manipulation av program ( generering av program , studiet av en viss egenskap hos program - korrekthet, effektivitet, etc.) [3] [1] [5] [ 6] . Å andra sidan är utvecklingen av ett nytt språk och dess effektiva implementering ett icke-trivialt problem inom teoretisk och tillämpad informatik .
Bland andra tillvägagångssätt för programdesign utmärker sig LOP för sitt mycket mer aggressiva fokus på att föra datorn närmare människan. Det finns en åsikt bland LOP-forskare att i vetenskapsintensiva uppgifter gör en väldesignad och implementerad DSL kommunikation mellan människa och dator mycket bekvämare och mer produktiv än ett grafiskt användargränssnitt . De vanligaste exemplen är följande populära domänspecifika språk :
och så vidare.
Fördelarna med LOP visas även i de fall där DSL inte är utvecklad för massanvändning, utan för att lösa en enda uppgift. Till exempel, när man utvecklar ett system för automatisk ekvivalent konvertering av program FermaT , övergången från "platt" programmering i Lisp till rekursiv LOP (WSL implementerades på Lisp , MetaWSL implementerades på den, och målfunktionaliteten var redan på det) tillät inte bara att minska den totala mängden kod från 100 till 16 tusen rader, utan ökade samtidigt alla de viktigaste kvalitativa egenskaperna hos koden och gjorde det till och med möjligt att lösa problem som inte kunde lösas på annat sätt [2] .
En förenklad jämförelse av ökningen av arbetskraftskostnaderna när man använder de traditionella och språkorienterade metoderna tillåter grafen [1] . Som du kan se är LOP lämpligt endast från en viss tröskel för volym och komplexitet för målsystemets funktionalitet.
De flesta LOP-forskare förlitar sig på funktionella språk och metaspråk , vilket leder till en hög ingångströskel för utvecklare. Martin Ward noterar möjligheten att implementera DSL på traditionella språk, men först efter dess slutliga utveckling.
I mainstream används ofta inbäddning av en tolk i ett allmänt språk (se Tillvägagångssätt ), även om detta inte bara görs utan att appellera till principerna för LOP, utan ofta utan att inse faktumet av dess tillämpning som sådan. Oftast inbäddat: språk för reguljära uttryck ( PCRE- tolk ), Lua , SQL , XML . En visuell programmeringsverktygssats har också utvecklats för mainstream- användning av några av LOP:s idéer.
Många forskare ser målet med LOP som att helt sudda ut gränserna mellan en matematisk modell och dess implementering på en dator och göra det möjligt att utveckla programvara av ämnesspecialister som inte har specifik kunskap inom programmering [1] [6] :
-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p ‘inRegion‘ r = r p
...
Genom att korrekt fånga domänens semantik kan även icke-programmerare förstå mycket av koden. I ett experiment beställt av Naval Surface Warfare Center förstod personer som var helt obekanta med Haskell de grundläggande begreppen i farten. Vissa uttryckte till och med misstro att den här koden faktiskt var körbar.
(Trots närvaron av denna sista mening i texten uttryckte faktiskt en av recensenterna av det första utkastet till detta verk missnöje med det faktum att " verket påstås vara en diskurs om både syntax och semantik, men dess innehåll är handlar huvudsakligen om syntax (som till exempel definitionen inRegion), och ingen skillnad görs mellan matematik och programmering ". Men i själva verket är denna definition inRegionhelt semantisk. Dessutom tillåter ekvationellt resonemang [7] ... dig att sudda ut linje mellan matematik och programmering: program kan betraktas som specifikationer. Detta är speciellt eftersom det utökar användningen av formella metoder.)
Tillvägagångssättet bygger på idén att ett språk som är speciellt utformat för en given uppgift kommer att ge uppenbarligen högre kodkvalitetsindikatorer än något allmänspråkigt [1] [6] , och att det för att lösa komplexa industriella problem kommer att vara mer effektivt att uppfinna mer lättförståeligt (mänskligt orienterat [8] eller korrekt inkapslande ämneskunskap [2] [1] ) språk, snarare än att övervinna svårigheterna med att använda ett befintligt, även ett som är förankrat i industrin [4] .
De flesta forskare talar om LOP som en övergång av hela mjukvaruutvecklingsindustrin till användning av textbaserade språk av 4:e och 5:e generationen [8] , men vissa fokuserar på användningen av visuella språk [9] [10 ] .
Huvudproblemen med tillvägagångssättet är att hitta sätt att snabbt skapa en implementering av den uppfunna DSL för att börja utveckla den faktiska lösningen på problemet, och att säkerställa god beräkningsprestanda för DSL .
Ett domänspecifikt språk, som alla programmeringsspråk i allmänhet, definieras av alfabet , grammatik , semantik och psykolingvistik , men beroende på hur DSL implementeras kan rollen och förhållandet mellan dessa nivåer vara suddiga och/eller ärvda från språket för dess genomförande.
Olika författare betonar olika sätt att utveckla domänspecifika språk:
När man använder makroverktyg finns det i sin tur en skillnad mellan mallmetaprogrammering och flerstegs statisk tolkning [13] [17] [18] [5] .
Den tredje och fjärde metoden har en fundamental fördel jämfört med de två första - DSL ersätter inte, utan utökar det allmänna språket [14] [1] [19] [20] , genom att återanvända hela basspråkets verktygslåda, med början med parsern , på grund av vilket:
Många författare fokuserar på effektiv (utan tolkning) inbäddning i språket av vissa initialt frånvarande funktioner för anpassning till vissa uppgifter [15] [16] , vilket senare kan tjäna som grund för ren DSL-inbäddning [21] . Stor uppmärksamhet ägnas åt användningen av fortsättningar för att utveckla DSL:er med icke-deterministisk semantik ( Steel , Wend , Felleisen , Ramsey , Reppy och andra).
En viktig underart av LOP är användarprogrammering , som gör att en mängd människor som inte har någon aning om datavetenskap kan effektivt lösa många tillämpade problem. Rollen för denna tillämpning av LOP är så stor att det kanske vanligaste programmeringsspråket i världen i praktiken är kalkylbladslayoutverktyg ( eng. spreadsheets ) [6] .
Beroende på tolkningen av termen " metaprogrammering " (MP) och hur DSL implementeras, är antingen LOP kvintessensen av MT eller så är MT ett av sätten att implementera LOP. Det senare alternativet är mest tillämpligt i fallet med inbäddning av DSL i ett allmänt språk genom en makroundergrupp av det senare [13] . När du använder visuella utvecklingsverktyg för DSL [9] [10] är dessa definitioner synonyma, eftersom visuell programmering i sig är den enklaste formen av MT. Att betrakta MT som en egentillämpning av LOP betyder:
För att utveckla oberoende översättare används lexer- och parsergeneratorer i stor utsträckning baserat på definitionen av grammatiken för mål- DSL med BNF och reguljära uttryck :
och andra.
När man kompilerar en oberoende DSL, väljs inbyggd kod eller till och med assembler sällan som målplattform , det är mer att föredra (både för att minska komplexiteten i implementeringen av DSL och för att öka portabiliteten) att använda en plattform på högre nivå:
Följande tekniker används för att bädda in DSL på ett allmänt språk:
Ren inbäddning involverar inga ytterligare verktyg, men lägger ganska stränga begränsningar på valet av .
När man använder statisk tolkning i flera steg är målplattformen densamma som basspråket [13] [17] [18] [5] .
Inom ramen för traditionell programmering (på språk som ärvts från Algol ) möjliggör användningen av några av idéerna från LOP den visuella programmeringsverktygssatsen , utvecklad under första hälften av 2000 -talet [9] [10] [27] [ 28] :
I Lisp -språkgemenskapen, nästan från det ögonblick då det skapades, övades det att använda makroverktyg för att anpassa sig till kraven i ämnesområdet för problemet. Detta tillvägagångssätt, i synnerhet, beskrevs i detalj i boken The Structure and Interpretation of Computer Programs . Liknande idéer har ibland använts i Forth -språkgemenskapen . I grund och botten var dessa beslut spontana till sin natur, och ofta kan de klassificeras som ad hoc- beslut [13] .
Under andra hälften av 1970 -talet uppfanns Hindley -Milner-typsystemet , som utgjorde grunden för ML-språket ( en förkortning för MetaLanguage ) . ML designades ursprungligen som en DSL för LCF -satsbevissystemet , men det stod snart klart att det kunde vara ett bra allmänt applicerat språk - bättre än språk som ursprungligen utformades för att vara allmänna ändamål, som felsökt på ett specifikt komplext problem [30] [31] . Som en konsekvens av detta skapade det en hel familj av X-M-typade språk som har vunnit popularitet som språk för språkutveckling ( metaspråk ) och som ofta definieras som " DSLs for denotational semantics " [1] .
1994 gav Martin Ward [ 32] en detaljerad beskrivning av metodiken [2] och föreslog termerna " språkorienterad programmering " och " divergent utveckling " (eller " utveckling från centrum till kanterna ", mitten ut utveckling ), noterar att tillvägagångssättet, i olika former, hade tillämpats många gånger tidigare. Termen " divergent utveckling " understryker att mellanskiktet ( mellanskiktet ) i det resulterande systemet är det utvecklade DSL, i motsats till de tidigare kända och fortfarande allmänt använda metoderna för " nedifrån och upp utveckling " ( nedifrån och upp utveckling ), " top-down-utveckling " ( top-down-utveckling ) och " konvergerande utveckling " ( utanför i utveckling ) som kombinerar dem.
Ward föreslog också att använda LOP rekursivt, vilket stegvis ökade komplexiteten i systemet som utvecklas från botten och upp; och kombinera LOP med rapid prototyping genom att först utveckla den enklaste DSL-prototypen (vilket kan göras mycket snabbt) och den enklaste lösningen med den, och sedan, efter att ha testat språket, identifierat brister och förtydligat krav, förfina DSL och skriva om lösningen i en ny version av språket och så vidare iterativt.
Paul Hudak föreslog [1] en ren inbäddningsmetod medtypsäkra språk (helst lata som Haskell , men möjligen strikta som ML , även om implementeringen i det senare fallet blir lite mer besvärlig och mindre naturlig ) och ekvationsresonemang [7] genom att rekursivt utveckla systemet från topp till botten och ackumulera återanvändbar kod i form av "DSL för DSL-utveckling".
Den rena inbäddningsmetoden gav upphov till termen "inbäddat domänspecifikt språk" ( eng. Embedded DSL, EDSL ; ibland DSEL ) [1] [8] . Ett antal EDSL:er över Haskell utvecklades för programmering i en ren funktionell stil interaktiva realtidsapplikationer (Fran, Fruit, FRP och RT-FRP, FAL, Frob, Fvision, Yampa) [33] [19] , som bildade en oberoende paradigm - funktionell reaktiv programmering (FRP). Detta visar att LOP inte är ett separat slutet programmeringsparadigm, utan tvärtom kan användas som ett verktyg i utvecklingen av nya paradigm.
Standard ML , basdialekten för ML , har varit föremål för kontroverser sedan början av 1990 -talet angående bristen på makrofunktioner i språket [30] . Kritiker menade att avsaknaden av makron var en nackdel, men starka maskinskrivare invände att deras frånvaro bara var en fördel. På en annan dialekt av ML - OCaml - föreslogs en kompromissidé - syntaxparametrisering genom att extrahera parsern till en anpassad CamlpX kompilatormodul, genom vilken en uppsättning EDSL:er för OCaml utvecklades. Senare dök ett tillägg för att generera kod vid körning upp - MetaOCaml . I slutet av 1990 -talet föreslogs idén om typsäkra makron som ett verktyg för effektiv implementering av typsäkra DSL:er [34] . Denna idé implementerades snart som MetaML- tillägg [13] [17] [18] för Standard ML och Template Haskell [35] för Haskell . I det första fallet betraktas makroverktygen enbart som en statisk tolk i flera steg; i det andra betraktas de både som samma tillvägagångssätt och som det kvasi-citat som är känt från Lisp -språket och som ett mallundersystem , liknande det som finns tillgängligt i C++-språket .
En studie av möjligheten att implementera och tillämpa dessa metoder på olika språk visade att C++ är ett extremt obekvämt verktyg för att utveckla inbäddade språk [36] . Ändå tillåter C++ att implementera lösningar i denna riktning, odlade och felsökta under överinseende av funktionell programmering [5] [37] , vilket är en sällsynt fördel för vanliga språk [5] .
Preliminära forskningsdata publicerade 2012 visade att oberoende DSL är bekvämare att använda, medan EDSL är lättare att implementera [8] .
Tillväxten av komplexiteten hos vilket mjukvarusystem som helst begränsas i grunden av den gräns till vilken det fortfarande är möjligt att behålla kontroll över det: om mängden information som krävs för att förstå en komponent i detta system överstiger "kapaciteten" hos en hjärna. person, kommer denna komponent inte att förstås helt. Det kommer att bli extremt svårt att förfina den eller rätta till fel, och varje korrigering kan förväntas introducera nya fel på grund av denna ofullständiga kunskap.
Originaltext (engelska)[ visaDölj] Det finns en grundläggande gräns för komplexiteten hos ett programvarusystem för att det fortfarande ska vara hanterbart: om det kräver mer än "en hjärnafull" information för att förstå en komponent i systemet, kommer den komponenten inte att förstås fullt ut. Det kommer att vara extremt svårt att göra förbättringar eller fixa buggar, och varje korrigering kommer sannolikt att introducera ytterligare fel på grund av denna ofullständiga kunskap. — Martin Ward, "Språkorienterad programmering" [2]LOP har många fördelar jämfört med traditionell "platt" utveckling [2] :
Implementeringen av språk genom att utveckla oberoende översättare är en rutinuppgift, eftersom en omfattande formell bas och verktyg baserade på den har ackumulerats ( Lex/Yacc , ANTLR , Parsec [22] ). Till exempel, på Parsec, görs utvecklingen av parsers för språk med enkel grammatik (jämförbar med Pascal Wirths grammatik ) på några mantimmar [38] [39] .
Språkorienterad programmering har två huvudsakliga nackdelar jämfört med traditionell programmering, som dock inte är grundläggande: en hög ingångströskel för språkutvecklare (minskad till priset av att ge upp de flesta fördelarna med metodiken) och svårigheten att säkerställa beräkningsprestanda . Båda bristerna är endast relevanta för utvecklare av domänspecifika språk; användare av språket (applikationsspecialister) får en nettofördel.
BegränsningarUtvecklingen av nya språk kräver en god teoretisk bakgrund och flyt i semantiskt olika språk och deras tillägg. Martin Ward noterar att att designa ett bra språk med potential att tillfredsställa sina användare och ha en lång livscykel är en komplex uppgift som kräver en hög grad av datavetenskaplig läskunnighet , och rekommenderar att programmerare ständigt tränar språkutveckling för att få tillräcklig praktisk erfarenhet. Dessutom påpekar han att syftet med LOP inte är att sänka inträdeströskeln för utvecklare, utan tvärtom att stärka och förenkla arbetet för kvalificerade utvecklare – och redan i framtiden leder detta till att inträdet minskar. tröskel för användare av systemet, vilket är nödvändigt för dess användning och utveckling.
Metoder för att bädda in en DSL i ett allmänt språk är långt ifrån tillämpliga på något språk, eftersom kräver vissa egenskaper hos basspråkets semantik i olika kombinationer: en applikativ anropsmodell , ett verkligt polymorft typsystem eller dynamisk typning (se polymorfism ), funktioner av högre ordning , fortsättningar , ett utvecklat makroextensionsundersystem, reflexivitet , lättja . Dessa egenskaper är inte tillgängliga initialt (eller kan implementeras helt) på inget sätt på något språk. Oftast används båda metoderna och deras kombinationer i dialekter av språk baserade på otypad och maskinskriven lambdakalkyl (en matematisk modell för att beskriva semantik), ibland med icke-standardiserade specifika tillägg: Common Lisp , Scheme , Standard ML , MetaML [ 13] , Alice , OCaml , MetaOCaml , Haskell , Template Haskell , Nemerle . Dessa metoder är också tillämpliga i Forth-språket , även om de relativt sällan används av Forth-utvecklare. Alla dessa språk har en hög inträdesgräns. Vissa författare noterar möjligheten att använda den tredje metoden i vanliga C++ , men lämpligheten av C++ för LOP har kritiserats [36] .
Visuell DSL-utveckling [9] [10] har en låg inträdesbarriär, men offrar ett antal LOP-funktioner som beskrivs av Ward, Hudak och andra:
Beräkningsprestandan för en "slarvig" DSL-implementering kan vara låg, och bra optimering kan bli orimligt dyrt. Naturligtvis, på grund av syftet med vissa DSL:er, är hastigheten inte av grundläggande betydelse för dem ( Τ Ε Χ , AutoLisp ). I andra fall beror det både på implementeringsmetoden och på målsammanställningsplattformen och i många fall går det att uppnå mycket goda resultat. Till exempel beskriver Waleed Taha [40] implementeringen av FRP-språköversättaren genom metoden att generera imperativ C -kod , med vilken realtidsapplikationer utvecklades för 16-bitars PIC16C66 mikrokontroller [41] . Hudak påpekar [1] att Haskells flerstegs, modulära rena inlining DSL-implementationer (se Approach ) är extremt långsamma, eftersom varje lager av abstraktion ger en 15-70-faldig avmattning - men på grund av användningen av superkompileringstekniker , hastigheten kan ökas tillbaka med tre storleksordningar (från 400 till 2800 gånger).
Det är möjligt att utveckla en DSL utformad för att optimera design som används inom logik på högre nivå. Exempelvis utvecklades språket OL (Operator Language) [42] för att beskriva matematiska algoritmer på ett plattformsoberoende sätt och för att förenkla portering till nya arkitekturer av matematiska bibliotek med höga prestandakrav (se nummerkrossare ). Kompilatorn parametriseras av data på processorarkitekturen (stöd för vektoroperationer, antal kärnor, etc.), och utför ibland automatiska jämförande tester av implementeringsalternativ med valet av den snabbaste. Som ett resultat genererar ett program i ett deklarativt språk på superhög nivå mycket effektiv (jämförbar med handskriven) C-kod som implementerar algoritmen på det mest effektiva sättet för en given arkitektur. I det här fallet blir skärpningen av storleken på indata också en komponent av effektiviteten - till exempel kan en snabb funktion byggas för att multiplicera 8x8 matriser.
Användningen av inbäddningsbara DSL:er i språk för vilka det finns globalt optimerande kompilatorer (som Stalin Scheme , MLton ) tillåter språkspecifik uppgiftsuppdelning utan förlust av effektivitet jämfört med andra designmetoder, men kan införa begränsningar för de utvecklade DSL . Denna riktning är föremål för många studier.
Alla dessa lösningar är privata, och tillämpligheten av var och en av dem beror på arten av den utvecklade DSL på alla nivåer, eller vice versa, ställer särskilda krav på den. Således är korrelationen mellan projektets arkitektur och effektiviteten av dess genomförande en integrerad del av LOP-problemet. Detta gäller även för andra designmetoder, men i mycket mindre utsträckning.