språkdesignprinciper
ett väldesignat domänspecifikt språk, eller ett språk i allmänhet, ger människor möjlighet att både uttrycka sina tankar på ett snabbt och koncist sätt samt förstå feedbacksvaret enkelt. Det är särskilt viktigt att undersöka eftersom det direkt påverkar hur snabbt du kan iterera — testa nya ideer och förstå mellanresultat. Snabba iterationer gör det möjligt att testa ett större antal parametrar inklusive de som inte borde fungera vid första anblicken, så att du kan förstå domänen du undersöker mycket bättre. Således påverkar språkdesignen inte bara den totala tid som behövs för att lösa ett problem på ett icke-linjärt sätt, det är ofta nyckeln till att hitta lösningen alls.
en viktig fråga uppstår-Vad är ett bra Språk? Finns det några riktlinjer som varje domänspecifikt språk bör följa? Vi tror att det finns två grundläggande principer:
- människor behöver en omedelbar anslutning till vad de gör
denna princip infördes först offentligt av Brett Victor, en människa-datorinteraktion visionär, under sitt föredrag uppfinna på princip. Varje överträdelse av denna princip alienerar användaren från de faktiska problemen han försöker lösa, vilket följaktligen minskar förståelsen och ökar antalet misstag. - människor kan inte begränsas av det verktyg de använder
människor tenderar att avvisa något verktyg som uppenbarligen begränsar deras uttrycksfullhet. Detta är den exakta anledningen till att så många WYSIWYG-lösningar, som webbplatsskapare, spelskapare eller visuella programmeringsspråk, aldrig kommer ikapp. Varje DSL som är mer komplex än en WYSIWYG-textredigerare kan enkelt bryta mot denna princip genom att ge sina användare en för begränsad uppsättning fördefinierade komponenter på hög nivå. Även om dessa komponenter kan utökas genom att skriva kod, förstör behovet av att tillgripa något underliggande programmeringsspråk designen och gör den oanvändbar för en mindre teknisk publik.
Principöverträdelse
brott mot någon av dessa principer leder alltid till en suboptimal lösning. Låt oss överväga den grafiska designen igen. Använder Photoshop alltid bättre än att skriva HTML, Sass och JavaScript-kod? Förmodligen. Dessa lösningar bryter mot den första respektive den andra principen. Photoshop ger en WYSIWYG digital canvas med en begränsad uppsättning fördefinierade, knappast utdragbara verktyg. HTML, Sass och JavaScript, å andra sidan, ger ett textgränssnitt och därmed alienerar användaren från dess verkliga skapelse men ställer inte in en stram begränsning av uttrycksförmågan. Låt oss överväga två användningsfall:
- en webbdesign. Det finns fem, jämnt ordnade objekt i menyraden. Om du vill lägga till ett nytt objekt och ändra webbplatsens färgpalett behöver du bara ändra en enda rad i HTML och en färgvariabel i Sass. Oavsett hur komplex webbplatsen är, uppdateras varje element automatiskt. Att göra detsamma i Photoshop kräver flera storleksordningar mer tid-skapa ett nytt menyalternativ, använd ett justeringsverktyg för att ordna elementen, ändra färgerna manuellt och förmodligen tillämpa vissa omvandlingar och filter på mer komplexa webbplatsområden.
- en konstnärlig målning. Att använda HTML, SVG och Sass i en textredigerare för att uttrycka en konstnärlig vision skulle knappast vara möjligt. Ju mer kreativ och upptäckbar processen är, desto viktigare blir WYSIWYG-verktygssatsen och omedelbar återkopplingsslinga.
skulle det vara möjligt att smälta båda tillvägagångssätten? Det är inte bara möjligt, det finns redan lösningar på väg i rätt riktning. Tänk på Sketch, som har blivit den ultimata designverktygslådan för Mac OS. Varför så många föredrar det framför Photoshop? Svaret är förvånansvärt enkelt-Sketch begränsar användarens uttrycksförmåga mindre än Photoshop. Det låter dig skapa återanvändbara designelement och sedan bulk-uppdatera sina parametrar, precis som Sass, men i en interaktiv WYSIWYG-miljö. Det finns många andra sätt att ytterligare förbättra designerns upplevelse. Titta på ett annat föredrag från Brett Victor, Rita dynamiska visualiseringar, för ytterligare inspiration.
Förbannelsen av DSLs
Om vi känner till de mycket grundläggande principerna för ett perfekt domänspecifikt språk, Varför finns inte de tillgängliga domänspecifika verktygen ännu? Varför lever vi inte i en obegränsad WYSIWYG-Värld?
medan domänspecifika språk levererar ett oöverträffat sätt att manipulera och förstå data, smugglar de också tyst bortskämda mjukvarudesignmönster. Förekomsten av många, små DSL som inte kan tala med varandra leder i ett långt perspektiv till en dysfunktionell, fragmenterad mjukvaruvärld.
i den verkliga världen finns det ett ständigt samarbete mellan domäner. Bildmanipulation används ofta för behoven av maskininlärning och bioinformatik, som i sin tur alltmer blir ett viktigt verktyg för arkitektur och fordonsdesign. Den snabba IoT-utvecklingen resulterar i mindre och mer autonoma enheter, vilket öppnar en ny värld för tidig sjukdomsdetektering, hälsoövervakningssystem eller intelligenta städer.
det finns dock knappast något samarbete i mjukvaruvärlden. Mjukvaruutvecklare skriver samma kod om och om igen, vilket leder till höga utvecklingskostnader och innovationsstagnation. Du kan inte bara ta en formredigerare från din favoritgrafikprogramvara, finjustera den efter dina behov, limma den med maskininlärningsverktyg och skapa ett AI-assisterat 3D-modelleringsverktyg för behoven hos 3D-utskrift. Istället för timmar behöver du för närvarande dagar eller månader för att utföra en sådan uppgift. Även om du hittar bibliotek som implementerar liknande funktioner måste en enorm mängd arbete göras innan det följer principen ”inga gränser” och ger en verkligt flexibel miljö, så att dina användare kan finjustera hur modellen är byggd. Som ett resultat, istället för att förbättra befintliga komponenter eller uppfinna nya sätt att manipulera data, implementerar Utvecklare kända lösningar från början i varje ny applikation.
Luna, språket
riktlinjerna för domänspecifika språk för att följa den första principen är tydliga. För att leverera den omedelbara kopplingen mellan människor och deras skapande måste domänspecifika språk kombinera rik datavisualisering och intuitiv datamanipulation i en enda, smidig upplevelse. Det finns dock ingen tumregel hur man gör det korrekt. Det beror starkt på den specifika domänen och användarens preferenser, vilket gör det andra paradigmet, möjligheten att anpassa komponenter, ännu viktigare.
att följa den andra principen är dock svårare. Hur kan vi utforma ett språk och vara säker på att det inte begränsar människors uttrycksfullhet? Hur kan vi tillåta användare att både skapa anpassade återanvändbara komponenter och djupt ändra befintliga men ändå hålla gränssnittet enkelt och inte kräva att de är programmerare? Tanken är att låta användaren stegvis ändra perspektivet. Istället för att tillgripa ett underliggande programmeringsspråk kan vi tillåta att bokstavligen dyka in i varje komponent och använda samma (eller mycket liknande) språk för att beskriva hur delkomponenterna kommunicerar. Dykning längre in i kapslade komponenter gör det möjligt för användare att gradvis gå från höga till låga abstraktionsnivåer på begäran.
det här är precis vad Luna gör. Det byggdes på tre huvudkoncept:
- datavisualisering och manipuleringsmiljö
Luna låter dig visualisera och manipulera data med interaktiva och utbyggbara WYSIWYG-komponenter. Dessutom ger Luna ett sätt att enkelt definiera nya komponenter, ändra befintliga och dela dem med samhället. - dataflödesdiagram
Du kan bokstavligen zooma ut för att se hur högnivåkomponenterna kopplas samman och bildar ett dataflödesdiagram. Du kan koppla om dem eller infoga nya komponenter för att omdefiniera hur grafen fungerar. Luna levererar komponenter som sprids över alla abstraktionsnivåer, från hög till låg. Från att måla en duk över statistiska funktioner till bitvisa operatörer - kapslade dataflödesdiagram och kodrepresentation
varje komponent i Luna är byggd av andra komponenter, utan undantag. Du kan alltid dyka hela vägen ner till önskad abstraktionsnivå och finjustera den efter dina behov. Du kan också kollapsa flera anslutna komponenter till en ny, kraftfullare och dela den med andra. Dessutom ger Luna sina användare en mycket unik förmåga att växla mellan representationer — från dataflödesdiagrammet till kod och vice versa. Det innebär en mycket viktig sanning-grafen är lika kraftfull som koden.
Luna designades som en enhetlig miljö för att bygga och vara värd för visuellt rika domänspecifika språk. Det suddar ut gränserna mellan domäner, vilket gör att Verktyg från olika områden för att sömlöst kommunicera och samexistera.