Kielisuuntautunut ohjelmointi (LOP) ( Englanti Language Oriented Programming ), myös Divergent-kehitys ( englanniksi keskimmäinen kehitys ), myös metakielen abstraktio , myös aluekohtaiseen kieleen perustuva kehitys ( englanniksi DSL-pohjainen kehitys ) [1] - ohjelmointiparadigma , joka koostuu ohjelmistokehitysprosessin jakamisesta verkkoaluekohtaisten kielten (DSL) kehitysvaiheeseen ja ongelman varsinaisen ratkaisun kuvaamisesta niitä käyttämällä. Vaiheet voidaan suorittaa peräkkäin tai rinnakkain, kerran tai rekursiivisesti [2] [1] ; DSL:t voidaan toteuttaa peruskielestä riippumattomasti tai itsenäisesti, ja niissä on yksi tai useampi toteutus.
LOP on suunniteltu erottamaan monimutkaisuudet: koodin konesuuntautunut osa (matala toiminnallisuus) ja ihmislähtöinen osa (sovelletun ongelman varsinainen ratkaisu) kehitetään toisistaan riippumatta, mikä eliminoi koodin eksponentiaalisen kasvun. tuloksena on koko projektin kehittämisen monimutkaisuus ja ratkaisee monimutkaisuusongelman perustavanlaatuisena ohjelmointiongelmana [2] , jonka Frederick Brooks kuvasi kuuluisassa esseessä " Ei ole hopealuotia ", minkä vuoksi ohjelmoijien tuottavuuden lisääminen on mahdotonta. jopa suuruusluokkaa yksinkertaisesti parantamalla työvälineitä. Suurin osa muista eduista seuraa suoraan tästä .
Kielten erikoistumisen kaventamisen eduista keskusteltiin jo 1980-luvun puolivälissä [ 3] ja kielten tason nostamisen ansioista paljon aikaisemmin [4] , mutta DSL-suuntautunut kehitys muodostui itsenäiseksi. menetelmä vasta 1990-luvun puoliväliin mennessä .
DSL:n käyttäminen yleiskäyttöisten kielten sijaan lisää huomattavasti koodin abstraktion tasoa, mikä mahdollistaa nopean ja tehokkaan kehittämisen sekä helppolukuisten ja helppohoitoisten ohjelmien luomisen; ja myös mahdollistaa tai yksinkertaistaa merkittävästi monien ohjelmien manipulointiin liittyvien ongelmien ratkaisemista (ohjelmien luominen, ohjelmien tietyn ominaisuuden tutkiminen - oikeellisuus, tehokkuus jne.) [3] [1] [5] [ 6] . Toisaalta uuden kielen kehittäminen ja sen tehokas toteuttaminen on ei-triviaali teoreettisen ja soveltavan informatiikan ongelma .
Muiden ohjelmasuunnittelun lähestymistapojen joukossa LOP erottuu paljon aggressiivisemmasta keskittymisestään tietokoneen tuomiseen lähemmäs ihmistä. LOP-tutkijat ovat sitä mieltä, että tiedeintensiivisissä tehtävissä hyvin suunniteltu ja toteutettu DSL tekee ihmisen ja tietokoneen välisestä kommunikaatiosta paljon mukavampaa ja tuottavampaa kuin graafinen käyttöliittymä . Yleisimmin mainitut esimerkit ovat seuraavat suositut verkkotunnuskohtaiset kielet :
jne.
LOP:n edut näkyvät myös silloin, kun DSL:ää ei ole kehitetty massakäyttöön, vaan yksittäisen tehtävän ratkaisemiseen. Esimerkiksi kehitettäessä järjestelmää ohjelmien automaattiseen ekvivalenttimuunnokseen FermaT siirryttiin Lispin "tasaisesta" ohjelmoinnista rekursiiviseen LOP:iin (WSL toteutettiin Lispissä , MetaWSL toteutettiin siihen ja kohdetoiminto oli jo päällä se) ei vain antanut mahdollisuuden vähentää koodin kokonaismäärää 100:sta 16 tuhanteen riviin, vaan samalla lisäsi koodin kaikkia tärkeimpiä laadullisia ominaisuuksia ja jopa mahdollisti ongelmien ratkaisemisen, joita ei voitu ratkaista muuten [2] .
Työvoimakustannusten kasvun yksinkertaistettu vertailu perinteistä ja kielilähtöistä lähestymistapaa käytettäessä mahdollistaa kaavion [1] . Kuten näette, LOP on tarkoituksenmukainen vain alkaen tietystä määrästä ja kohdejärjestelmän toiminnallisuuden monimutkaisuudesta.
Useimmat LOP-tutkijat luottavat toiminnallisiin kieliin ja metakieliin , mikä johtaa korkeaan pääsykynnykseen kehittäjille. Martin Ward panee merkille mahdollisuuden ottaa DSL käyttöön perinteisillä kielillä, mutta vasta sen lopullisen kehittämisen jälkeen.
Valtavirrassa käytetään usein tulkin upottamista yleiskäyttöiseen kieleen (katso Lähestymistapa ), vaikka tämä ei tapahdu pelkästään vetoamatta LOP:n periaatteisiin, vaan usein myös ymmärtämättä sen käyttöä sellaisenaan. Useimmiten upotettu: säännöllinen lausekekieli ( PCRE- tulkki ), Lua , SQL , XML . Joidenkin LOP-ideoiden yleiskäyttöä varten on kehitetty myös visuaalinen ohjelmoinnin työkalupakki.
Monet tutkijat näkevät LOP:n tavoitteen hämärtää kokonaan matemaattisen mallin ja sen tietokoneella toteutuksen väliset rajat ja mahdollistaa ohjelmistokehityksen aiheen asiantuntijoiden toimesta, joilla ei ole erityistä ohjelmointitietoa [1] [6] :
-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p ‘inRegion‘ r = r p
...
Kaappaamalla tarkasti toimialueen semantiikan, jopa ei-ohjelmoijat pystyvät ymmärtämään suuren osan koodista. Naval Surface Warfare Centerin tilaamassa kokeessa ihmiset, jotka eivät olleet täysin tunteneet Haskellia, ymmärsivät peruskäsitteet lennossa. Jotkut jopa ilmaisivat epäuskonsa siitä, että tämä koodi oli todella suoritettava.
(Huolimatta tämän viimeisen virkkeen olemassaolosta tekstissä, yksi tämän teoksen ensimmäisen luonnoksen arvioijista ilmaisi tyytymättömyytensä siihen tosiasiaan, että " teoksen väitetään olevan diskurssi sekä syntaksista että semantiikasta, mutta sen sisältö on pääasiassa syntaksia (kuten esimerkiksi määritelmä inRegion), eikä matematiikan ja ohjelmoinnin välillä tehdä eroa . Mutta itse asiassa tämä määritelmä inRegionon täysin semanttinen. Lisäksi yhtälöpäättely [7] ... sallii sinun hämärtää matematiikan ja ohjelmoinnin välinen raja: ohjelmia voidaan pitää spesifikaatioina. Tämä on erityistä, koska se laajentaa muodollisten menetelmien käyttöä.)
Lähestymistapa perustuu ajatukseen, että kieli, joka on erityisesti suunniteltu tiettyyn tehtävään, tarjoaa selvästi korkeammat koodin laatuindikaattorit kuin mikään yleiskäyttöinen kieli [1] [6] ja että monimutkaisten teollisten ongelmien ratkaisemiseksi on tehokkaampaa keksiä helpommin ymmärrettävää (ihmissuuntautunutta [8] tai tarkasti kiteyttävää aihetietoa [2] [1] ) sen sijaan, että voitetaan olemassa olevan, jopa teollisuuteen juurtuneen kielen käytön vaikeudet [4] .
Useimmat tutkijat puhuvat LOP:sta koko ohjelmistokehitysteollisuuden siirtymänä 4. ja 5. sukupolven tekstipohjaisten kielten käyttöön [8] , mutta jotkut keskittyvät visuaalisten kielten käyttöön [9] [10 ] ] .
Lähestymistavan pääongelmana on löytää keinoja luoda nopeasti toteutus keksitystä DSL :stä, jotta voidaan alkaa kehittää varsinaista ratkaisua ongelmaan, ja varmistaa DSL :n hyvä laskennallinen suorituskyky .
Verkkoaluekohtaisen kielen, kuten minkä tahansa ohjelmointikielen yleensä, määrittelevät aakkoset , kielioppi , semantiikka ja psyklingvistiikka , mutta riippuen tavasta, jolla DSL on toteutettu, näiden tasojen rooli ja suhde voivat olla epäselviä ja/tai periytyä sen täytäntöönpanon kieli.
Eri kirjoittajat korostavat erilaisia tapoja kehittää toimialuekohtaisia kieliä:
Makrotyökaluja käytettäessä puolestaan tehdään ero mallin metaohjelmoinnin ja monivaiheisen staattisen tulkinnan välillä [13] [17] [18] [5] .
Kolmannella ja neljännellä menetelmällä on perustavanlaatuinen etu kahteen ensimmäiseen verrattuna - DSL ei korvaa, vaan laajentaa yleiskäyttöistä kieltä [14] [1] [19] [20] , käyttämällä uudelleen koko peruskielen työkalupakkia, alkaen jäsentimestä , jonka takia:
Monet kirjoittajat keskittyvät tiettyjen alun perin puuttuvien ominaisuuksien tehokkaaseen (ilman tulkintaa) upottamiseen kieleen sopeuttamiseksi tiettyihin tehtäviin [15] [16] , jotka voivat myöhemmin toimia perustana puhtaalle DSL-upotukselle [21] . Huomattavaa huomiota kiinnitetään jatkojen käyttöön kehitettäessä DSL:itä, joilla on ei-deterministinen semantiikka ( Steel ] , Wend [en , Felleisen , Ramsey , Reppy ja muut).
Tärkeä LOP:n alalaji on User Programming , jonka avulla useat ihmiset, joilla ei ole aavistustakaan tietojenkäsittelytieteestä, voivat ratkaista tehokkaasti monia sovellettavia ongelmia. Tämän LOP-sovelluksen rooli on niin suuri, että ehkä käytännössä yleisin ohjelmointikieli maailmassa on taulukkolaskentatyökalut ( eng. taulukkolaskenta ) [6] .
Riippuen termin " metaohjelmointi " (MP) tulkinnasta ja tavasta, jolla DSL on toteutettu, joko LOP on MT:n kvintessenssi tai MT on yksi tavoista toteuttaa LOP. Jälkimmäinen vaihtoehto soveltuu parhaiten, kun DSL upotetaan yleiskäyttöiseen kieleen jälkimmäisen makroalijoukon kautta [13] . Käytettäessä DSL :n visuaalisia kehitystyökaluja [9] [10] nämä määritelmät ovat synonyymejä, koska visuaalinen ohjelmointi itsessään on MT:n yksinkertaisin muoto. MT:n pitäminen LOP: n omana sovelluksena tarkoittaa:
Riippumattomien kääntäjien kehittämiseen käytetään laajalti lexer- ja jäsennysgeneraattoreita, jotka perustuvat kohde- DSL :n kieliopin määritelmään käyttämällä BNF :ää ja säännöllisiä lausekkeita :
ja muut.
Kun käännetään itsenäistä DSL:ää, natiivikoodia tai jopa kokoajaa valitaan harvoin kohdealustaksi , on parempi (sekä DSL:n käyttöönoton monimutkaisuuden vähentämiseksi että siirrettävyyden lisäämiseksi) käyttää korkeamman tason alustaa:
Seuraavia tekniikoita käytetään DSL:n upottamiseen yleiskäyttöiseen kieleen:
Puhdas upotus ei sisällä lisätyökaluja, mutta asettaa melko ankarat rajoitukset peruskielen valinnalle .
Käytettäessä monivaiheista staattista tulkintaa kohdealusta on sama kuin peruskieli [13] [17] [18] [5] .
Perinteisen ohjelmoinnin puitteissa (Algolilta perityillä kielillä ) joidenkin LOP-ideoiden käyttö mahdollistaa 2000-luvun alkupuoliskolla kehitetyn visuaalisen ohjelmoinnin työkalupakin [9] [10] [27] [ 28] :
Lisp - kieliyhteisössä melkein sen luomishetkestä lähtien harjoitettiin makrotyökalujen käyttöä sopeutumaan ongelman aihealueen vaatimuksiin. Tämä lähestymistapa on erityisesti kuvattu yksityiskohtaisesti kirjassa The Structure and Interpretation of Computer Programs . Samanlaisia ajatuksia on toisinaan sovellettu Forthin kieliyhteisössä . Pohjimmiltaan nämä päätökset olivat luonteeltaan spontaaneja, ja usein ne voidaan luokitella tilapäisiksi päätöksiksi [13] .
1970 - luvun jälkipuoliskolla keksittiin Hindley - Milner - tyyppinen järjestelmä , joka muodosti ML - kielen ( lyhenne sanoista MetaLanguage ) perusta . ML suunniteltiin alun perin DSL : ksi LCF - lauseiden todistamisjärjestelmää varten , mutta pian kävi selväksi, että se voisi olla hyvä yleiskäyttöinen sovellettu kieli – parempi kuin kielet, jotka alun perin suunniteltiin yleiskäyttöisiksi kieliksi. virheenkorjaus yhdessä tietyssä monimutkaisessa ongelmassa [30] [31] . Seurauksena on, että se synnytti koko perheen X-M-tyyppisiä kieliä , jotka ovat saavuttaneet suosiota kielenkehityksen kielinä ( metakielinä ) ja jotka usein määritellään " denotaatiosemantiikan DSL:iksi [ " [1] .
Vuonna 1994 Martin Ward [ 32] antoi yksityiskohtaisen kuvauksen metodologiasta [2] ja ehdotti termejä " kielisuuntautunut ohjelmointi " ja " divergentti kehitys " (tai " kehitys keskustasta reunoille ", keskimmäinen kehitys ). huomauttaa, että lähestymistapaa eri muodoissa on sovellettu useita kertoja aiemmin. Termi " divergentti kehitys " korostaa, että tuloksena olevan järjestelmän keskikerros ( keskikerros ) on kehitetty DSL, toisin kuin aiemmin tunnetut ja edelleen laajalti käytetyt " alhaalta ylös -kehityksen " menetelmät ( bottom up development ). " ylhäältä alas kehitys " ( ylhäältä alas kehitys ) ja " konvergoiva kehitys " ( kehityksen ulkopuolella ), joka yhdistää ne.
Ward ehdotti myös LOP:n käyttöä rekursiivisesti, mikä lisäsi asteittain kehitettävän järjestelmän monimutkaisuutta alhaalta ylöspäin; ja yhdistä LOP nopeaan prototyyppiin kehittämällä ensin yksinkertaisin DSL-prototyyppi (joka voidaan tehdä hyvin nopeasti) ja yksinkertaisin ratkaisu sitä käyttämällä, sitten kielen testauksen, virheiden tunnistamisen ja vaatimusten selventämisen jälkeen hio DSL ja kirjoita ratkaisu uudelleen uusi versio kielestä ja niin edelleen iteratiivisesti.
Paul Hudak ehdotti [1] puhdasta upotusmenetelmää käyttäen tyyppiturvallisia kieliä (mieluiten laiskoja, kuten Haskell , mutta mahdollisesti tiukkoja, kuten ML , vaikka jälkimmäisessä tapauksessa toteutus on hieman hankalampi ja vähemmän luonnollinen ) ja yhtälöpäättely [7] kehittämällä järjestelmää rekursiivisesti ylhäältä alas ja keräämällä uudelleenkäytettävää koodia "DSL:n DSL-kehitykseen" muodossa.
Puhtaalla upotusmenetelmällä syntyi termi "sulautettu verkkotunnuskohtainen kieli" ( eng. Embedded DSL, EDSL ; joskus DSEL ) [1] [8] . Useita Haskellin yli olevia EDSL:itä kehitettiin ohjelmointiin puhtaasti funktionaalisissa interaktiivisissa reaaliaikaisissa sovelluksissa (Fran, Fruit, FRP ja RT-FRP, FAL, Frob, Fvision, Yampa) [33] [19] , jotka muodostivat itsenäisen paradigma - funktionaalinen reaktiivinen ohjelmointi (FRP). Tämä osoittaa, että LOP ei ole erillinen suljettu ohjelmointiparadigma, vaan sitä voidaan päinvastoin käyttää työkaluna uusien paradigmojen kehittämisessä.
Standardi ML , ML :n perusmurre, on ollut kiistanalainen 1990-luvun alusta lähtien makroominaisuuksien puutteesta kielestä [30] . Kriitikot väittivät, että makrojen puute oli haitta, mutta vahvat konekirjoittajat vastustivat, että niiden puuttuminen oli vain etu. Toisessa ML:n murteessa - OCaml - ehdotettiin kompromissiideaa - syntaksin parametrointia purkamalla jäsennys mukautettuun CamlpX -kääntäjämoduuliin, jonka kautta kehitettiin joukko EDSL:itä OCamlille. Myöhemmin ilmestyi laajennus koodin luomiseen ajon aikana - MetaOCaml . 1990-luvun lopulla ajatusta tyyppiturvallisista makroista ehdotettiin työkaluksi tyyppiturvallisten DSL:ien tehokkaaseen toteuttamiseen [34] . Tämä idea otettiin pian käyttöön MetaML- laajennuksina [13] [17] [18] Standard ML : lle ja Template Haskell [35] Haskellille . Ensimmäisessä tapauksessa makrotyökaluja pidetään yksinomaan monivaiheisena staattisena tulkkina; toisessa niitä pidetään sekä samana lähestymistapana että Lisp -kielestä tunnettuna kvasitanauksena ja mallialijärjestelmänä, joka on samanlainen kuin C++-kielessä .
Tutkimus mahdollisuudesta toteuttaa ja soveltaa näitä lähestymistapoja eri kielillä osoitti, että C ++ on erittäin hankala työkalu sulautettujen kielten kehittämiseen [36] . Siitä huolimatta C++ mahdollistaa tämänsuuntaisten ratkaisujen toteuttamisen , joita on viljelty ja virheenkorjattu toiminnallisen ohjelmoinnin [5] [37] alaisuudessa , mikä on harvinainen etu valtavirran kielille [5] .
Vuonna 2012 julkaistu alustava tutkimustieto osoitti, että riippumaton DSL on helpompi käyttää, kun taas EDSL on helpompi toteuttaa [8] .
Minkä tahansa ohjelmistojärjestelmän monimutkaisuuden kasvua rajoittaa pohjimmiltaan se raja, johon asti sitä on vielä mahdollista hallita: jos tämän järjestelmän komponentin ymmärtämiseen tarvittavan tiedon määrä ylittää yhden ihmisen aivojen "kapasiteetin". henkilöä, tätä komponenttia ei ymmärretä täysin. Sen jalostaminen tai virheiden korjaaminen tulee olemaan erittäin vaikeaa, ja jokaisen korjauksen voidaan odottaa tuovan uusia virheitä tämän puutteellisen tiedon vuoksi.
Alkuperäinen teksti (englanniksi)[ näytäpiilottaa] Minkä tahansa ohjelmistojärjestelmän monimutkaisuudella on perustavanlaatuinen raja, jotta se olisi edelleen hallittavissa: jos se vaatii enemmän kuin "yhden aivotäytön" tietoa järjestelmän osan ymmärtämiseksi, sitä komponenttia ei ymmärretä täysin. On erittäin vaikeaa tehdä parannuksia tai korjata virheitä, ja jokainen korjaus aiheuttaa todennäköisesti lisää virheitä tämän puutteellisen tiedon vuoksi. — Martin Ward, "Language Oriented Programming" [2]LOP:lla on monia etuja verrattuna perinteiseen "tasaiseen" kehitykseen [2] :
Kielten toteuttaminen kehittämällä itsenäisiä kääntäjiä on rutiinitehtävä, koska on kertynyt kattava muodollinen pohja ja siihen perustuvat työkalut ( Lex/ Yacc , ANTLR , Parsec [22] ). Esimerkiksi Parsecissä jäsentimien kehittäminen kielille, joilla on yksinkertainen kielioppi (verrattavissa Pascal Wirthin kielioppiin ), tehdään muutamassa työtunnissa [38] [39] .
Kielisuuntautuneella ohjelmoinnilla on kaksi pääasiallista haittaa perinteiseen ohjelmointiin verrattuna, jotka eivät kuitenkaan ole perustavanlaatuisia: korkea kielikehittäjien pääsykynnys (alennettu sillä kustannuksella, että suurimmasta osasta menetelmän eduista luovutaan) ja laskennallisen suorituskyvyn varmistamisen vaikeus. . Molemmat puutteet koskevat vain verkkotunnuskohtaisten kielten kehittäjiä. kielen käyttäjät (sovellusasiantuntijat) saavat nettohyötyä.
RajoituksetUusien kielten kehittäminen edellyttää hyvää teoreettista taustaa ja sujuvuutta semanttisesti erilaisissa kielissä ja niiden laajennuksissa. Martin Ward huomauttaa, että hyvän kielen suunnittelu, jolla on potentiaalia tyydyttää käyttäjiään ja jolla on pitkä elinkaari, on monimutkainen tehtävä, joka vaatii korkeatasoista tietojenkäsittelytieteen lukutaitoa , ja suosittelee, että ohjelmoijat harjoittelevat jatkuvasti kielenkehitystä saadakseen riittävästi käytännön kokemusta. Lisäksi hän huomauttaa, että LOP:n tarkoituksena ei ole alentaa kehittäjien sisäänpääsykynnystä, vaan päinvastoin pätevien kehittäjien työvoiman vahvistaminen ja yksinkertaistaminen - ja tämä johtaa jo tulevaisuudessa sisäänpääsyn laskuun. kynnys järjestelmän käyttäjille, joka on välttämätön sen käytön ja kehittämisen kannalta.
Menetelmät DSL:n upottamiseksi yleiskäyttöiseen kieleen eivät sovellu millään kielellä, koska vaativat tiettyjä peruskielen semantiikan ominaisuuksia erilaisissa yhdistelmissä: aplikatiivinen kutsumalli , todella polymorfinen tyyppijärjestelmä tai dynaaminen tyypitys (katso polymorfismi ), korkeamman asteen funktiot , jatkot , kehittynyt makrolaajennusalijärjestelmä, refleksiivisyys , laiskuus . Nämä ominaisuudet eivät ole aluksi saatavilla (tai ne voidaan ottaa käyttöön kokonaan) millään kielellä. Useimmiten molempia menetelmiä ja niiden yhdistelmiä käytetään kielten murteissa, jotka perustuvat tyypittämättömään ja kirjoitettuun lambda-laskentaan (matemaattinen malli semantiikan kuvaamiseen), joskus standardoimattomilla erityisillä laajennuksilla: Common Lisp , Scheme , Standard ML , MetaML [ 13] , Alice , OCaml , MetaOCaml , Haskell , Malli Haskell , Nemerle . Näitä menetelmiä voidaan soveltaa myös Forth-kielellä , vaikka Forthin kehittäjät käyttävät niitä suhteellisen harvoin. Kaikilla näillä kielillä on korkea pääsykynnys. Jotkut kirjoittajat panevat merkille mahdollisuuden käyttää kolmatta menetelmää valtavirran C++ :ssa , mutta C++:n soveltuvuutta LOP:lle on kritisoitu [36] .
Visuaalisella DSL-kehityksellä [9] [10] on alhainen pääsyn este, mutta se uhraa useita Wardin, Hudakin ja muiden kuvaamia LOP-ominaisuuksia:
"Huolittoman" DSL-toteutuksen laskentateho voi olla alhainen ja hyvä optimointi voi olla kohtuuttoman kallista. Tietenkin joidenkin DSL:ien tarkoituksesta johtuen nopeudella ei ole niille perustavanlaatuista merkitystä ( Τ Ε Χ , AutoLisp ). Muissa tapauksissa se riippuu sekä toteutusmenetelmästä että kohteena olevasta käännösalustasta, ja monissa tapauksissa on mahdollista saavuttaa erittäin hyviä tuloksia. Esimerkiksi Waleed Taha kuvaa [40] FRP-kielen kääntäjän toteutusta imperatiivisen C-koodin generointimenetelmällä , jolla kehitettiin reaaliaikaisia sovelluksia 16-bittiselle PIC16C66-mikro-ohjaimelle [41] . Hudak huomauttaa [1] , että Haskellin monivaiheiset, modulaariset puhtaasti inlining DSL-toteutukset (katso Approach ) ovat erittäin hitaita, koska jokainen abstraktiokerros hidastaa 15-70-kertaista - mutta superkääntämistekniikoiden käytön vuoksi , nopeutta voidaan nostaa takaisin kolmella suuruusluokalla (400 - 2800 kertaa).
On mahdollista kehittää DSL , joka on suunniteltu optimoimaan ylemmän tason logiikassa käytettyjä malleja. Esimerkiksi OL (Operator Language) -kieli [42] kehitettiin kuvaamaan matemaattisia algoritmeja alustasta riippumattomalla tavalla ja yksinkertaistamaan portaamista uusiin matemaattisten kirjastojen arkkitehtuureihin, joilla on korkeat suorituskykyvaatimukset (katso numeromurskain ). Kääntäjä parametroidaan prosessorin arkkitehtuurin tiedoilla (vektoritoimintojen tuki, ytimien lukumäärä jne.), ja joskus se suorittaa automaattisen vertailutestauksen toteutusvaihtoehtojen valinnassa nopeimman. Tämän seurauksena superkorkean tason deklaratiivisen kielen ohjelma tuottaa erittäin tehokkaan (verrattavissa käsinkirjoitettuun) C-koodin, joka toteuttaa algoritmin tehokkaimmalla tavalla tietyssä arkkitehtuurissa. Tällöin syöttötietojen koon kiristämisestä tulee myös tehokkuuden komponentti - esimerkiksi nopea funktio voidaan rakentaa kertomaan 8x8 matriiseja.
Upotettavat DSL :t kielillä, joille on olemassa maailmanlaajuisesti optimoivia kääntäjiä ( kuten Stalin Scheme , MLton ), mahdollistaa kielikohtaisen tehtävien hajotuksen ilman tehokkuuden heikkenemistä muihin suunnittelumenetelmiin verrattuna, mutta saattaa asettaa rajoituksia kehitetylle DSL. Tämä suunta on monien tutkimusten kohteena.
Kaikki nämä ratkaisut ovat yksityisiä, ja jokaisen soveltuvuus riippuu kehitetyn DSL:n luonteesta kaikilla tasoilla tai päinvastoin asettaa sille erityisiä vaatimuksia. Siten projektin arkkitehtuurin korrelaatio sen toteutuksen tehokkuuteen on olennainen osa LOP-ongelmaa. Tämä pätee myös muihin suunnittelumenetelmiin, mutta paljon vähemmässä määrin.