Sprogorienteret programmering (LOP) ( English Language Oriented Programming ), også Divergent udvikling ( engelsk middle out development ), også metalsprogsabstraktion , også Udvikling baseret på et domænespecifikt sprog ( engelsk DSL-Based Development ) [1] - programmeringsparadigme , som består i at opdele softwareudviklingsprocessen i udviklingsstadiet for domænespecifikke sprog (DSL) og beskrive den faktiske løsning af problemet ved at bruge dem. Stadier kan udføres sekventielt eller parallelt, én gang eller rekursivt [2] [1] ; DSL'er kan implementeres afhængigt eller uafhængigt af basissproget og har en eller flere implementeringer.
LOP er designet til at adskille kompleksiteter: den maskinorienterede del af koden (lavt niveau funktionalitet) og den menneskeorienterede del (den faktiske løsning af det anvendte problem) udvikles uafhængigt af hinanden, hvilket eliminerer den eksponentielle vækst af resulterende kompleksitet ved at udvikle hele projektet og løser problemet med kompleksitet som et grundlæggende programmeringsproblem [2] , beskrevet af Frederick Brooks i det berømte essay " Der er ingen sølvkugle ", på grund af hvilket det er umuligt at øge programmørernes produktivitet endda i en størrelsesorden ved blot at forbedre arbejdsredskaberne. De fleste andre fordele følger direkte heraf .
Fordelene ved at indsnævre sprogspecialiseringen blev diskuteret allerede i midten af 1980'erne [3] , og fordelene ved at hæve sprogniveauet meget tidligere [4] , men DSL-orienteret udvikling blev dannet som en selvstændig metode først i midten af 1990'erne .
Brug af DSL'er i stedet for generelle sprog øger niveauet af kodeabstraktion markant, hvilket giver dig mulighed for at udvikle hurtigt og effektivt og skabe programmer, der er nemme at forstå og vedligeholde; og gør det også muligt eller væsentligt forenkler løsningen af mange problemer relateret til manipulation af programmer ( generering af programmer , undersøgelse af en bestemt egenskab ved programmer - korrekthed, effektivitet osv.) [3] [1] [5] [ 6] . På den anden side er udviklingen af et nyt sprog og dets effektive implementering et ikke-trivielt problem for teoretisk og anvendt informatik .
Blandt andre tilgange til programdesign skiller LOP sig ud for sit meget mere aggressive fokus på at bringe computeren tættere på mennesket. Der er en opfattelse blandt LOP-forskere, at i videnskabstunge opgaver gør en veldesignet og implementeret DSL kommunikation mellem mennesker og computere meget mere bekvem og produktiv end en grafisk brugergrænseflade . De mest almindeligt nævnte eksempler er følgende populære domænespecifikke sprog :
og osv.
Fordelene ved LOP viser sig selv i tilfælde, hvor DSL ikke er udviklet til massebrug, men til at løse en enkelt opgave. For eksempel, når man udviklede et system til automatisk ækvivalent konvertering af programmer FermaT , overgangen fra "flad" programmering i Lisp til rekursiv LOP (WSL blev implementeret på Lisp , MetaWSL blev implementeret på det, og målfunktionaliteten var allerede på det) ikke kun tilladt at reducere den samlede mængde kode fra 100 til 16 tusind linjer, men samtidig øget alle de vigtigste kvalitative egenskaber ved koden og endda gjort det muligt at løse problemer, der ikke kunne løses på anden måde [2] .
En forenklet sammenligning af væksten i lønomkostninger ved brug af de traditionelle og sprogorienterede tilgange tillader grafen [1] . Som du kan se, er LOP kun hensigtsmæssigt at starte fra en vis tærskel for volumen og kompleksiteten af funktionaliteten af målsystemet.
De fleste LOP-forskere er afhængige af funktionelle sprog og metasprog , hvilket fører til en høj adgangstærskel for udviklere. Martin Ward bemærker muligheden for at implementere DSL på traditionelle sprog, men først efter den endelige udvikling.
I mainstream bruges ofte indlejring af en tolk i et almen-formålssprog (se tilgang ), selvom dette ikke kun gøres uden at appellere til principperne for LOP, men ofte uden at indse kendsgerningen af dets anvendelse som sådan. Oftest indlejret: regulære udtrykssprog ( PCRE - fortolker ), Lua , SQL , XML . Der er også udviklet et visuelt programmeringsværktøj til almindelig brug af nogle af ideerne fra LOP.
Mange forskere ser målet med LOP som fuldstændig at udviske grænserne mellem en matematisk model og dens implementering på en computer og gøre det muligt at udvikle software af fagspecialister, der ikke har specifik viden inden for programmering [1] [6] :
-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p ‘inRegion‘ r = r p
...
Ved nøjagtigt at fange domænets semantik, er selv ikke-programmører i stand til at forstå meget af koden. I et eksperiment bestilt af Naval Surface Warfare Center forstod folk, der var fuldstændig ukendte med Haskell, de grundlæggende begreber i farten. Nogle udtrykte endda vantro over, at denne kode faktisk var eksekverbar.
(Ja, på trods af tilstedeværelsen af denne sidste sætning i teksten, udtrykte en af anmelderne af det første udkast til dette værk utilfredshed med, at " værket hævdes at være en diskurs om både syntaks og semantik, men dets indhold er hovedsagelig beskæftiger sig med syntaks (som f.eks. definitionen inRegion), og der skelnes ikke mellem matematik og programmering ". Men faktisk er denne definition inRegionfuldstændig semantisk. Desuden giver ligningsræsonnement [7] ... dig mulighed for at sløre grænse mellem matematik og programmering: programmer kan betragtes som specifikationer. Dette er specielt, fordi det udvider brugen af formelle metoder.)
Fremgangsmåden er baseret på ideen om, at et sprog, der er specielt designet til en given opgave, vil give åbenbart højere kodekvalitetsindikatorer end noget almindeligt sprog [1] [6] , og at det til løsning af komplekse industrielle problemer vil være mere effektivt at opfinde mere letforståeligt (menneskeorienteret [8] eller præcist indkapslet fagkundskab [2] [1] ) sprog, frem for at overvinde vanskelighederne ved at bruge et eksisterende, selv et der er forankret i industrien [4] .
De fleste forskere taler om LOP som en overgang af hele softwareudviklingsindustrien til brug af tekstbaserede sprog af 4. og 5. generation [8] , men nogle fokuserer på brugen af visuelle sprog [9] [10 ] .
Hovedproblemerne ved tilgangen er at finde måder til hurtigt at skabe en implementering af den opfundne DSL for at begynde at udvikle den faktiske løsning på problemet, og for at sikre god beregningsmæssig ydeevne af DSL .
Et domænespecifikt sprog, som ethvert programmeringssprog generelt, er defineret af alfabet , grammatik , semantik og psykolingvistik , men afhængigt af den måde DSL er implementeret på, kan rollen og forholdet mellem disse niveauer være sløret og/eller nedarvet fra sproget for dens gennemførelse.
Forskellige forfattere fremhæver forskellige måder at udvikle domænespecifikke sprog på:
Når man bruger makroværktøjer, er der til gengæld en skelnen mellem skabelon-metaprogrammering og flertrins statisk fortolkning [13] [17] [18] [5] .
Den tredje og fjerde metode har en fundamental fordel i forhold til de to første - DSL erstatter ikke, men udvider det generelle sprog [14] [1] [19] [20] , ved at genbruge hele basissprogværktøjssættet, startende med parseren , på grund af hvilket:
Mange forfattere fokuserer på den effektive (uden fortolkning) indlejring i sproget af visse oprindeligt fraværende funktioner til tilpasning til bestemte opgaver [15] [16] , som senere kan tjene som grundlag for ren DSL-indlejring [21] . Der lægges stor vægt på brugen af fortsættelser til at udvikle DSL'er med ikke-deterministisk semantik ( Steel , Wend , Felleisen , Ramsey , Reppy og andre).
En vigtig underart af LOP er brugerprogrammering , som gør det muligt for en række mennesker, der ikke har nogen idé om datalogi, effektivt at løse mange anvendte problemer. Rollen af denne anvendelse af LOP er så stor, at det måske mest almindelige programmeringssprog i verden i praksis er regnearkslayoutværktøjer ( eng. regneark ) [6] .
Afhængigt af fortolkningen af udtrykket " metaprogrammering " (MP) og måden, hvorpå DSL er implementeret, er enten LOP kvintessensen af MT, eller MT er en af måderne at implementere LOP på. Sidstnævnte mulighed er mest anvendelig i tilfælde af indlejring af DSL i et generelt sprog gennem en makro-undergruppe af sidstnævnte [13] . Når du bruger visuelle DSL -udviklingsværktøjer [9] [10] , er disse definitioner synonyme, fordi visuel programmering i sig selv er den enkleste form for MT. At betragte MT som en selvanvendelse af LOP betyder:
For at udvikle uafhængige oversættere bruges lexer- og parser-generatorer i vid udstrækning baseret på definitionen af grammatikken for mål - DSL ved hjælp af BNF og regulære udtryk :
og andre.
Når du kompilerer en uafhængig DSL, vælges indbygget kode eller endda assembler sjældent som målplatformen , det er mere at foretrække (både for at reducere kompleksiteten ved implementering af DSL og for at øge portabiliteten) at bruge en platform på højere niveau:
Følgende teknologier bruges til at integrere DSL i et almindeligt sprog:
Ren indlejring involverer ikke yderligere værktøjer, men pålægger temmelig strenge begrænsninger for valget af grundsproget .
Når du bruger statisk fortolkning i flere trin, er målplatformen den samme som basissproget [13] [17] [18] [5] .
Inden for rammerne af traditionel programmering (på sprog arvet fra Algol ) gør brugen af nogle af ideerne fra LOP det visuelle programmeringsværktøj , udviklet i første halvdel af 2000'erne [9] [10] [27] [ 28] :
I Lisp -sprogsamfundet, næsten fra dets oprettelse, blev det praktiseret at bruge makroværktøjer til at tilpasse sig kravene til emneområdet for problemet. Denne tilgang blev især beskrevet i detaljer i bogen The Structure and Interpretation of Computer Programs . Lignende ideer er til tider blevet anvendt i Forth -sprogsamfundet . Grundlæggende var disse beslutninger af spontan karakter, og ofte kan de klassificeres som ad hoc- beslutninger [13] .
I anden halvdel af 1970'erne blev Hindley -Milner-typesystemet opfundet , som dannede grundlaget for ML-sproget ( en forkortelse for MetaLanguage ) . ML blev oprindeligt designet som en DSL for LCF teorem-bevissystemet , men det blev hurtigt klart, at det kunne være et godt anvendt sprog til generelle formål - bedre end sprog, der oprindeligt var designet til at være almindelige sprog, som fejlrettet på et specifikt komplekst problem [30] [31] . Som en konsekvens affødte det en hel familie af X-M-typede sprog , der har vundet popularitet som sprog til sprogudvikling ( metasprog ) og ofte defineres som " DSL'er for denotationel semantik " [1] .
I 1994 gav Martin Ward [ 32 ] en detaljeret beskrivelse af metoden [2] og foreslog udtrykkene " sprogorienteret programmering " og " divergent udvikling " (eller " udvikling fra centrum til kanterne ", midt ude udvikling ), bemærker, at tilgangen i forskellige former var blevet anvendt mange gange før. Udtrykket " divergent udvikling " understreger, at mellemlaget ( mellemlaget ) i det resulterende system er det udviklede DSL, i modsætning til de tidligere kendte og stadig meget udbredte metoder til " bottom-up- udvikling " ( bottom-up-udvikling ), " top-down-udvikling " ( top-down-udvikling ) og " konvergerende udvikling " ( udenfor i udvikling ), der kombinerer dem.
Ward foreslog også at bruge LOP rekursivt, hvorved kompleksiteten af det system, der udvikles, gradvist blev øget nedefra og op; og kombinere LOP med hurtig prototyping ved først at udvikle den enkleste DSL-prototype (som kan gøres meget hurtigt) og den enkleste løsning ved at bruge den, derefter, efter at have testet sproget, identificeret fejl og afklaret krav, forfine DSL'en og omskrive løsningen i en ny version af sproget, og så videre iterativt.
Paul Hudak foreslog [1] en ren indlejringsmetode vedbrug af typesikre sprog (helst dovne som Haskell , men muligvis strenge som ML , selvom implementeringen i sidstnævnte tilfælde kommer lidt mere besværlig og mindre naturlig ud ) og ligningsræsonnement [7] ved rekursivt at udvikle systemet fra top til bund og akkumulere genbrugelig kode i form af "DSL for DSL-udvikling".
Den rene indlejringsmetode gav anledning til udtrykket "indlejret domænespecifikt sprog" ( eng. Embedded DSL, EDSL ; nogle gange DSEL ) [1] [8] . En række EDSL'er over Haskell blev udviklet til programmering i en ren funktionel stil interaktive realtidsapplikationer (Fran, Fruit, FRP og RT-FRP, FAL, Frob, Fvision, Yampa) [33] [19] , som dannede en uafhængig paradigme - funktionel reaktiv programmering (FRP). Dette viser, at LOP ikke er et separat lukket programmeringsparadigme, men tværtimod kan bruges som et værktøj i udviklingen af nye paradigmer.
Standard ML , grunddialekten for ML , har været genstand for kontroverser siden begyndelsen af 1990'erne vedrørende manglen på makrofunktioner i sproget [30] . Kritikere hævdede, at manglen på makroer var en ulempe, men stærke maskinskrivere indvendte, at deres fravær blot var en fordel. På en anden dialekt af ML - OCaml - blev der foreslået en kompromisidé - syntaksparametrisering ved at udtrække parseren i et brugerdefineret CamlpX compilermodul, hvorigennem et sæt EDSL'er til OCaml blev udviklet. Senere dukkede en udvidelse op til generering af kode ved kørsel - MetaOCaml . I slutningen af 1990'erne blev ideen om typesikre makroer foreslået som et værktøj til effektiv implementering af typesikre DSL'er [34] . Denne idé blev snart implementeret som MetaML- udvidelser [13] [17] [18] til Standard ML og Template Haskell [35] for Haskell . I det første tilfælde betragtes makroværktøjerne udelukkende som en flertrins statisk fortolker; i den anden betragtes de både som den samme tilgang og som den kvasi-citering, der kendes fra Lisp -sproget , og som et skabelonundersystem , svarende til det, der er tilgængeligt i C++-sproget .
En undersøgelse af muligheden for at implementere og anvende disse tilgange på forskellige sprog viste, at C++ er et ekstremt ubelejligt værktøj til at udvikle indlejrede sprog [36] . Ikke desto mindre tillader C++ at implementere løsninger i denne retning, dyrket og fejlrettet i regi af funktionel programmering [5] [37] , hvilket er en sjælden fordel for almindelige sprog [5] .
Foreløbige forskningsdata offentliggjort i 2012 viste, at uafhængig DSL er mere praktisk at bruge, mens EDSL er lettere at implementere [8] .
Væksten i ethvert softwaresystems kompleksitet er fundamentalt begrænset af den grænse, til hvilken det stadig er muligt at bevare kontrol over det: hvis mængden af information, der kræves for at forstå en komponent af dette system, overstiger "kapaciteten" af en hjernes hjerne. person, så vil denne komponent ikke blive fuldt ud forstået. Det vil blive ekstremt vanskeligt at forfine det eller rette fejl, og hver rettelse kan forventes at introducere nye fejl på grund af denne ufuldstændige viden.
Originaltekst (engelsk)[ Visskjule] Der er en grundlæggende grænse for kompleksiteten af ethvert softwaresystem, for at det stadig er overskueligt: hvis det kræver mere end "en hjernefuld" af information for at forstå en komponent af systemet, så vil den komponent ikke blive forstået fuldt ud. Det vil være ekstremt vanskeligt at lave forbedringer eller rette fejl, og hver rettelse vil sandsynligvis introducere yderligere fejl på grund af denne ufuldstændige viden. — Martin Ward, "Sprogorienteret programmering" [2]LOP har mange fordele i forhold til traditionel "flad" udvikling [2] :
Implementeringen af sprog ved at udvikle uafhængige oversættere er en rutineopgave, da en omfattende formel base og værktøjer baseret på det er blevet akkumuleret ( Lex/Yacc , ANTLR , Parsec [22] ). For eksempel på Parsec sker udvikling af parsere til sprog med simpel grammatik (sammenlignelig med Pascal Wirths grammatik ) i løbet af mandetimer [38] [39] .
Sprogorienteret programmering har to hovedulemper i forhold til traditionel programmering, som dog ikke er grundlæggende: en høj adgangstærskel for sprogudviklere (reduceret på bekostning af at give afkald på de fleste fordele ved metoden) og vanskeligheden ved at sikre beregningsmæssig ydeevne . Begge mangler er kun relevante for udviklere af domænespecifikke sprog; brugere af sproget (applikationsspecialister) får en nettofordel.
BegrænsningerUdviklingen af nye sprog kræver en god teoretisk baggrund og flydende sprog i semantisk forskellige sprog og deres udvidelser. Martin Ward bemærker, at det at designe et godt sprog med potentiale til at tilfredsstille sine brugere og have en lang livscyklus er en kompleks opgave, der kræver en høj grad af datalogi færdigheder , og anbefaler, at programmører konstant øver sig i sprogudvikling for at få tilstrækkelig praktisk erfaring. Derudover peger han på, at formålet med LOP ikke er at sænke adgangstærsklen for udviklere, men tværtimod at styrke og forenkle arbejdet for kvalificerede udviklere - og allerede i fremtiden fører det til et fald i adgangen. tærskel for brugere af systemet, hvilket er nødvendigt for dets brug og udvikling.
Metoder til indlejring af en DSL i et almindeligt sprog er langt fra at være anvendelige på noget sprog, siden kræve visse egenskaber af grundsprogets semantik i forskellige kombinationer: en applikativ kaldsmodel , et virkelig polymorfisk typesystem eller dynamisk typning (se polymorfi ), funktioner af højere orden , fortsættelser , et udviklet makroudvidelsesundersystem, refleksivitet , dovenskab . Disse egenskaber er ikke tilgængelige i starten (eller kan implementeres fuldt ud) på ingen måde på noget sprog. Oftest bruges begge metoder og deres kombinationer i dialekter af sprog baseret på utypebestemt og maskinskrevet lambda-regning (en matematisk model til beskrivelse af semantik), nogle gange med ikke-standardiserede specifikke udvidelser: Common Lisp , Scheme , Standard ML , MetaML [ 13] , Alice , OCaml , MetaOCaml , Haskell , Skabelon Haskell , Nemerle . Disse metoder er også anvendelige i Forth-sproget , selvom de relativt sjældent bruges af Forth-udviklere. Alle disse sprog har en høj adgangstærskel. Nogle forfattere bemærker muligheden for at bruge den tredje metode i mainstream C++ , men egnetheden af C++ til LOP er blevet kritiseret [36] .
Visuel DSL-udvikling [9] [10] har en lav adgangsbarriere, men ofrer en række LOP-funktioner beskrevet af Ward, Hudak og andre:
Den beregningsmæssige ydeevne af en "sjusket" DSL-implementering kan være lav, og god optimering kan være urimeligt dyr. På grund af formålet med nogle DSL'er er hastighed naturligvis ikke af fundamental betydning for dem ( Τ Ε Χ , AutoLisp ). I andre tilfælde afhænger det både af implementeringsmetoden og af målkompileringsplatformen, og i mange tilfælde er det muligt at opnå rigtig gode resultater. For eksempel beskriver Waleed Taha [40] implementeringen af FRP-sprogoversætteren ved hjælp af metoden til at generere imperativ C -kode , med hvilken realtidsapplikationer blev udviklet til 16-bit PIC16C66 mikrocontrolleren [41] . Hudak påpeger [1] , at Haskells flertrins, modulære rene inlining DSL-implementeringer (se tilgang ) er ekstremt langsomme, eftersom hvert lag af abstraktion giver en 15-70 gange langsommere nedgang - men på grund af brugen af superkompileringsteknikker , hastigheden kan øges tilbage med tre størrelsesordener (fra 400 til 2800 gange).
Det er muligt at udvikle en DSL designet til at optimere designs, der bruges i logik på højere niveau. For eksempel blev OL (Operator Language) sproget [42] udviklet til at beskrive matematiske algoritmer på en platformsuafhængig måde og for at forenkle portering til nye arkitekturer af matematiske biblioteker med høje ydeevnekrav (se nummerknuser ). Compileren er parametriseret af data på processorarkitekturen (understøttelse af vektoroperationer, antal kerner osv.), og udfører nogle gange automatisk sammenlignende test af implementeringsmuligheder med valg af den hurtigste. Som et resultat genererer et program i et deklarativt sprog på superhøjt niveau meget effektiv (sammenlignelig med håndskrevet) C-kode, der implementerer algoritmen på den mest effektive måde for en given arkitektur. I dette tilfælde bliver stramningen af størrelsen af inputdata også en del af effektiviteten - for eksempel kan der bygges en hurtig funktion til at multiplicere 8x8 matricer.
Brugen af indlejrbare DSL'er i sprog, som der findes globalt optimerende compilere til (såsom Stalin Scheme , MLton ) tillader sprogspecifik opgavenedbrydning uden tab af effektivitet sammenlignet med andre designtilgange, men kan pålægge begrænsninger for de udviklede DSL . Denne retning er genstand for mange undersøgelser.
Alle disse løsninger er private, og anvendeligheden af hver af dem afhænger af arten af den udviklede DSL på alle niveauer, eller omvendt, stiller særlige krav til den. Korrelationen mellem projektets arkitektur og effektiviteten af dets implementering er således en integreret del af LOP-problemet. Dette gælder også for andre designtilgange, men i meget mindre grad.