Language design principles
et godt designet domenespesifikt språk, eller et språk generelt, gir folk muligheten til både å uttrykke sine tanker på en rask og konsis måte, samt forstå tilbakemeldingsresponsen enkelt. Det er spesielt viktig å undersøke fordi det direkte påvirker hvor fort du kan iterere — teste nye ideer og forstå mellomresultater. Raske iterasjoner gjør det mulig å teste et bredere spekter av parametere, inkludert de som ikke skal fungere ved første øyekast, slik at du bedre kan forstå domenet du undersøker. Dermed påvirker språkdesignet ikke bare den totale tiden som trengs for å løse et problem på en ikke-lineær måte, det er ofte nøkkelen til å finne løsningen i det hele tatt.
et viktig spørsmål dukker opp — hva er et godt språk? Er det noen retningslinjer hvert domenespesifikt språk bør følge? Vi tror det er to grunnleggende prinsipper:
- Folk trenger en umiddelbar forbindelse til hva de gjør
dette prinsippet ble først offentlig introdusert Av Brett Victor, en menneske-datamaskin interaksjon visjonær, under hans tale Inventing On Principle. Ethvert brudd på dette prinsippet fremmedgjør brukeren fra de faktiske problemene han prøver å løse, noe som dermed reduserer forståelsen og øker antall feil. - Folk kan ikke begrenses av verktøyet de bruker
folk har en tendens til å avvise ethvert verktøy som åpenbart begrenser deres uttrykksevne. Dette er den eksakte grunnen til at så MANGE wysiwyg-løsninger, som nettstedskapere, spillskapere eller visuelle programmeringsspråk, aldri kommer opp. Enhver DSL mer kompleks ENN EN WYSIWYG tekstredigerer kan enkelt bryte dette prinsippet ved å gi brukerne et for begrenset sett med forhåndsdefinerte komponenter på høyt nivå. Selv om disse komponentene kan utvides ved å skrive kode, ødelegger behovet for å ty til noe underliggende programmeringsspråk designet og gjør det ubrukelig for et mindre teknisk publikum.
prinsippbrudd
Brudd på noen av disse prinsippene fører alltid til en suboptimal løsning. La oss vurdere grafisk design igjen. Bruker Photoshop alltid bedre enn å skrive HTML,Sass og JavaScript-kode? Uten tvil. Disse løsningene bryter med henholdsvis det første og det andre prinsippet. Photoshop gir ET wysiwyg digitalt lerret med et begrenset sett med forhåndsdefinerte, knapt utvidbare verktøy. HTML, Sass Og JavaScript, derimot, gir et tekstgrensesnitt, og dermed fremmedgjøre brukeren fra sin virkelige skapelse, men ikke sett en stram begrensning på uttrykksevnen. La oss vurdere to brukstilfeller:
- et webdesign. Det er fem, jevnt arrangert elementer i menylinjen. Hvis du vil legge til et nytt element og endre fargepaletten på nettstedet, er alt du trenger å gjøre, endre en enkelt linje i HTML og en fargevariabel i Sass. Uansett hvor komplisert nettstedet er, oppdateres hvert element automatisk. Å gjøre det samme i Photoshop krever flere størrelsesordener mer tid — opprett et nytt menyelement, bruk et justeringsverktøy for å ordne elementene, endre fargene manuelt og sannsynligvis bruke noen transformasjoner og filtre på mer komplekse nettstedsområder.
- et kunstnerisk maleri. Ved HJELP AV HTML, SVG og Sass i en tekst editor for å uttrykke en kunstnerisk visjon ville neppe være mulig. Jo mer kreativ og oppdagbar prosessen er, desto viktigere BLIR wysiwyg-verktøysettet og øyeblikkelig tilbakemeldingssløyfe.
Ville det være mulig å smelte begge tilnærmingene? Det er ikke bare mulig, det er allerede løsninger på vei i riktig retning. Tenk På Sketch, som har blitt den ultimate design verktøykasse For Mac OS. Hvorfor så mange mennesker foretrekker Det over Photoshop? Svaret er overraskende enkelt-Sketch begrenser brukerens uttrykksevne mindre Enn Photoshop. Den lar deg lage gjenbrukbare designelementer og deretter bulk-oppdatere sine parametere, akkurat Som Sass, men i en interaktiv, WYSIWYG miljø. Det er mange andre måter å ytterligere forbedre designerens opplevelse. Se En annen tale Fra Brett Victor, Tegning Dynamiske Visualiseringer, for ytterligere inspirasjon.
dsls forbannelse
hvis vi kjenner de grunnleggende prinsippene for et perfekt domenespesifikt språk, hvorfor er de tilgjengelige domenespesifikke verktøyene ikke der ennå? Hvorfor lever vi ikke i en ubegrenset WYSIWYG-verden?mens domenespesifikke språk gir en uovertruffen måte å manipulere og forstå data på, smugler de også stille bortskjemte programvaredesignmønstre. Eksistensen av mange, små Dsl-Er som ikke kan snakke med hverandre, fører i et langt perspektiv til en dysfunksjonell, fragmentert programvareverden.
I den virkelige verden er det et konstant samarbeid mellom domener. Bildemanipulering brukes ofte for behovene til maskinlæring og bioinformatikk, som igjen i økende grad blir et viktig verktøy for arkitektur og kjøretøydesign. Den raske IoT-utviklingen resulterer i mindre og mer autonome enheter, noe som åpner en ny verden for tidlig sykdomsdeteksjon, helseovervåkingssystemer eller intelligente byer.
det er imidlertid knapt noe samarbeid i programvareverdenen. Programvareutviklere skriver den samme koden om og om igjen, noe som fører til høye utviklingskostnader og innovasjonsstagnasjon. Du kan ikke bare ta en formredigerer fra din favoritt grafikkprogramvare, finjustere den for dine behov, lim den med maskinlæringsverktøy og lage ET AI-assistert 3d-modelleringsverktøy for behovene TIL 3D-utskrift. I stedet for timer trenger du for øyeblikket dager eller måneder for å utføre en slik oppgave. Selv om du finner biblioteker som implementerer lignende funksjonalitet, må en enorm mengde arbeid gjøres før det vil følge «no limits» – prinsippet og gi et virkelig fleksibelt miljø, slik at brukerne kan finjustere hvordan modellen er bygget. Som et resultat, i stedet for å forbedre eksisterende komponenter eller finne nye måter å manipulere data på, implementerer utviklere kjente løsninger fra bunnen av i hver ny applikasjon.
Luna, språket
retningslinjene for domenespesifikke språk for å følge det første prinsippet er klare. For å levere den umiddelbare forbindelsen mellom mennesker og deres opprettelse, må domenespesifikke språk kombinere rik datavisualisering og intuitiv datamanipulering i en enkelt, jevn opplevelse. Det er imidlertid ingen tommelfingerregel hvordan du gjør det riktig. Det avhenger sterkt av det bestemte domenet og brukerens preferanser, noe som gjør det andre paradigmet, evnen til å tilpasse komponenter, enda viktigere.
Etter det andre prinsippet er det imidlertid vanskeligere. Hvordan kan vi designe et språk og være sikker på at det ikke begrenser folks uttrykksevne? Hvordan kan vi tillate brukere å både lage egendefinerte gjenbrukbare komponenter og dypt endre eksisterende, men hold grensesnittet enkelt og ikke kreve at de skal være programmerere? Tanken er å tillate brukeren å trinnvis endre perspektivet. I stedet for å ty til et underliggende programmeringsspråk, kan vi tillate å bokstavelig talt dykke inn i hver komponent og bruke det samme (eller svært liknende) språket for å beskrive hvordan underkomponentene kommuniserer. Ved å dykke videre inn i nestede komponenter kan brukerne gradvis gå fra høye til lave abstraksjonsnivåer etter behov.
Dette er Akkurat Hva Luna gjør. Den ble bygget på tre hovedkonsepter:
- datavisualisering og manipulasjonsmiljø
Fra det høyeste perspektivet Lar Luna deg visualisere og manipulere data ved hjelp av interaktive OG utvidbare wysiwyg-komponenter. Videre Gir Luna en måte å enkelt definere nye komponenter, endre eksisterende og dele dem med samfunnet.Du kan bokstavelig talt zoome ut for å se hvordan komponentene på høyt nivå er koblet sammen og danner en dataflytgraf. Du kan rewire dem eller sette inn nye komponenter for å omdefinere hvordan grafen fungerer. Luna leverer komponenter som sprer seg over alle abstraksjonsnivåer, fra høy til lav. Fra å male et lerret over statistiske funksjoner til bitvis operatører - Nestede dataflyt grafer og kode representasjon
Hver komponent I Luna er bygget ut av andre komponenter, uten unntak. Du kan alltid dykke helt ned til ønsket abstraksjonsnivå og finjustere det til dine behov. Du kan også kollapse flere tilkoblede komponenter til en ny, kraftigere og dele den med andre. Videre Gir Luna sine brukere en veldig unik evne til å bytte mellom representasjoner – fra dataflyt grafen til kode og vice versa. Det innebærer en svært viktig sannhet — grafen er like kraftig som koden.Luna ble designet som et enhetlig miljø for å bygge og hosting visuelt rike domenespesifikke språk. Det visker ut grensene mellom domener, slik at verktøy fra ulike felt for å sømløst kommunisere og eksistere.