Language design principles
een goed ontworpen domeinspecifieke taal, of een taal in het algemeen, stelt mensen in staat om zowel hun gedachten snel en beknopt uit te drukken als de feedback-respons gemakkelijk te begrijpen. Het is vooral belangrijk om te onderzoeken, omdat het direct van invloed op hoe snel je kunt herhalen-test nieuwe ideeën en begrijpen tussentijdse resultaten. Snelle iteraties maken het mogelijk om een breder scala aan parameters te testen, inclusief parameters die op het eerste gezicht niet zouden moeten werken, zodat u het domein dat u onderzoekt veel beter kunt begrijpen. Zo beïnvloedt het taalontwerp direct niet alleen de totale tijd die nodig is om een probleem op een niet-lineaire manier op te lossen, het is vaak de sleutel om de oplossing te vinden.
een belangrijke vraag rijst-Wat is een goede taal? Zijn er richtlijnen die elke domeinspecifieke taal moet volgen? Wij geloven dat er twee basisprincipes zijn:
- mensen hebben een directe verbinding nodig met wat ze maken
dit principe werd voor het eerst publiekelijk geïntroduceerd door Brett Victor, een mens-computer interactie visionair, tijdens zijn lezing die uit Principe uitvond. Elke schending van dit principe vervreemdt de gebruiker van de werkelijke problemen die hij probeert op te lossen, waardoor het begrip afneemt en het aantal fouten toeneemt. - mensen kunnen niet worden beperkt door het gereedschap dat ze gebruiken
mensen hebben de neiging om elk gereedschap te weigeren dat hun expressiviteit duidelijk beperkt. Dit is precies de reden waarom zoveel WYSIWYG oplossingen, zoals website makers, game makers of visuele programmeertalen, nooit inhalen. Elke DSL die complexer is dan een WYSIWYG-teksteditor kan dit principe gemakkelijk schenden door zijn gebruikers te voorzien van een te beperkte set van vooraf gedefinieerde, high-level componenten. Zelfs als deze componenten kunnen worden uitgebreid door het schrijven van code, de noodzaak om toevlucht te nemen tot een aantal onderliggende programmeertaal bederft het ontwerp en maakt het onbruikbaar voor een minder technisch publiek.
Principeschending
schending van een van deze principes leidt altijd tot een suboptimale oplossing. Laten we het grafisch ontwerp nog eens bekijken. Is het gebruik van Photoshop altijd beter dan het schrijven van HTML, Sass en JavaScript-code? Misschien. Deze oplossingen zijn in strijd met respectievelijk het eerste en het tweede beginsel. Photoshop biedt een WYSIWYG digitaal canvas met een beperkte set van vooraf gedefinieerde, nauwelijks uitschuifbare tools. HTML, Sass en JavaScript, aan de andere kant, bieden een tekst-interface, en dus, vervreemden van de gebruiker van zijn echte creatie, maar geen strakke beperking op de expressiviteit. Laten we twee use cases overwegen:
- een website ontwerp. Er zijn vijf, gelijkmatig gerangschikt items in de menubalk. Als u een nieuw item wilt toevoegen en het kleurenpalet van de website wilt wijzigen, hoeft u alleen maar een enkele regel in HTML en een kleurvariabele in Sass te wijzigen. Hoe complex de website ook is, elk element wordt automatisch bijgewerkt. Hetzelfde doen in Photoshop vereist verschillende ordes van grootte meer tijd-Maak een nieuw menu-item, gebruik een uitlijning tool om de elementen te rangschikken, handmatig veranderen van de kleuren en waarschijnlijk opnieuw toe te passen sommige transformaties en filters in meer complexe website gebieden.
- een artistiek schilderij. Het gebruik van HTML, SVG en Sass binnen een teksteditor om een artistieke visie uit te drukken zou nauwelijks mogelijk zijn. Hoe creatiever en vindbaarder het proces is, hoe belangrijker de WYSIWYG toolset en instant feedback loop worden.
zou het mogelijk zijn om beide benaderingen te fuseren? Het is niet alleen mogelijk, er zijn al oplossingen die in de goede richting gaan. Denk aan Sketch, die is uitgegroeid tot de ultieme design toolkit voor Mac OS. Waarom zoveel mensen het liever dan Photoshop? Het antwoord is verrassend eenvoudig-schets beperkt de gebruiker expressiviteit minder dan Photoshop. Hiermee kunt u herbruikbare ontwerpelementen te maken en vervolgens bulk-update hun parameters, net als Sass, maar in een interactieve, WYSIWYG omgeving. Er zijn vele andere manieren om de ervaring van de ontwerper verder te verbeteren. Bekijk een andere talk van Brett Victor, met dynamische visualisaties, voor verdere inspiratie.
de vloek van DSLs
als we de basisprincipes kennen voor een perfecte domeinspecifieke taal, waarom zijn de beschikbare domeinspecifieke tools er dan nog niet? Waarom leven we niet in een onbeperkte WYSIWYG wereld?
terwijl domeinspecifieke talen een ongeëvenaarde manier bieden om gegevens te manipuleren en te begrijpen, smokkelen ze ook stilletjes verwende softwareontwerppatronen. Het bestaan van vele, kleine DSLs die niet met elkaar kunnen spreken leidt in een lang perspectief tot een disfunctionele, gefragmenteerde softwarewereld.
in de echte wereld is er een constante samenwerking tussen domeinen. Beeldmanipulatie wordt vaak gebruikt voor de behoeften van machine learning en bio-informatica, die op hun beurt steeds meer een belangrijk hulpmiddel voor architectuur en voertuigontwerp worden. De snelle IoT-ontwikkeling resulteert in kleinere en meer autonome apparaten, wat een nieuwe wereld opent voor vroege ziektedetectie, gezondheidsbewakingssystemen of intelligente steden.
Er is echter nauwelijks samenwerking in de softwarewereld. Softwareontwikkelaars schrijven steeds weer dezelfde code, wat leidt tot hoge ontwikkelingskosten en innovatie stagnatie. U kunt niet zomaar een vorm-editor van uw favoriete grafische software, fine-tunen voor uw behoeften, lijm het met machine learning tools en maak een AI-geassisteerde 3D-modellering tool voor de behoeften van 3D-printen. In plaats van uren, heb je momenteel dagen of maanden nodig om een dergelijke taak te volbrengen. Zelfs als je bibliotheken vindt die vergelijkbare functionaliteit implementeren, moet er enorm veel werk worden gedaan voordat het het “no limits” principe zal volgen en een echt flexibele omgeving zal bieden, zodat je gebruikers kunnen fine-tunen hoe het model wordt gebouwd. Als gevolg daarvan, in plaats van het verbeteren van bestaande componenten of het uitvinden van nieuwe manieren om data te manipuleren, ontwikkelaars opnieuw implementeren bekende oplossingen vanaf nul in elke nieuwe toepassing.
Luna, de taal
de richtlijnen voor domeinspecifieke talen om het eerste principe te volgen zijn duidelijk. Om de directe verbinding tussen mensen en hun creatie te bieden, moeten domeinspecifieke talen rijke datavisualisatie en intuã tieve datamanipulatie combineren in een enkele, soepele ervaring. Er is echter geen vuistregel hoe het correct te doen. Het hangt sterk af van het specifieke domein en de voorkeuren van de gebruiker, wat het tweede paradigma, de mogelijkheid om componenten aan te passen, nog belangrijker maakt.
Het tweede principe volgen is echter lastiger. Hoe kunnen we een taal ontwerpen en er zeker van zijn dat het de expressiviteit van mensen niet beperkt? Hoe kunnen we gebruikers toestaan om zowel aangepaste herbruikbare componenten te maken en bestaande grondig te wijzigen, maar de interface eenvoudig te houden en niet te vereisen dat ze programmeurs zijn? Het idee is om de gebruiker in staat te stellen om stapsgewijs het perspectief te veranderen. In plaats van onze toevlucht te nemen tot een onderliggende programmeertaal, kunnen we letterlijk in elk onderdeel duiken en dezelfde (of zeer vergelijkbare) taal gebruiken om te beschrijven hoe de subcomponenten communiceren. Door verder te duiken in geneste componenten kunnen gebruikers geleidelijk overgaan van hoge naar lage niveaus van abstractie op aanvraag.
Dit is precies wat Luna doet. Het werd gebouwd op drie hoofdconcepten:
- data visualisatie en manipulatie omgeving
vanuit het hoogste perspectief, Luna kunt u data visualiseren en manipuleren met behulp van interactieve en uitbreidbare WYSIWYG componenten. Bovendien biedt Luna een manier om eenvoudig nieuwe componenten te definiëren, bestaande te wijzigen en te delen met de gemeenschap. - Data flow graph
U kunt letterlijk uitzoomen om te zien hoe de high-level componenten met elkaar verbonden zijn en een data flow graph vormen. U kunt ze opnieuw bedraden of nieuwe componenten invoegen om te herdefiniëren hoe de grafiek werkt. Luna levert componenten die zich verspreiden over alle niveaus van abstractie, van hoog naar laag. Van het schilderen van een canvas over statistische functies tot bitwise operators - geneste data flow grafieken en code representatie
elke component in Luna is gebouwd uit andere componenten, zonder uitzondering. U kunt altijd helemaal naar beneden duiken naar het gewenste niveau van abstractie en het afstemmen op uw behoeften. U kunt ook verschillende verbonden componenten samenvouwen tot een nieuwe, krachtiger en delen met anderen. Bovendien biedt Luna haar gebruikers een zeer unieke mogelijkheid om te schakelen tussen representaties — van de gegevensstroomgrafiek naar code en vice versa. Het impliceert een zeer belangrijke waarheid — de grafiek is zo krachtig als de code.
Luna is ontworpen als een uniforme omgeving voor het bouwen en hosten van visueel rijke domeinspecifieke talen. Het vervaagt de grenzen tussen domeinen, waardoor tools uit verschillende velden naadloos kunnen communiceren en naast elkaar kunnen bestaan.