Jag har tittat på Elm-programmeringsspråket och Elm-ramverket. De är en typad funktionell programmeringsmetod till frontend som påverkar andra populära tekniker på ett något störande sätt. Den här artikeln är en uppskrivning om vad jag har räknat ut om Elm.
Denna artikel kommer att delas upp i två delar. I den här första delen kommer jag att fokusera på de funktioner som gör Elm till ett intressant alternativ till Javascript.
I den andra delen kommer jag att fokusera på det historiska perspektivet som gör Elm värt en titt; utarbeta språkets två huvuddrag: funktionell renhet och statisk typning; och slutligen, titta på vem som använder Elm i den verkliga världen.
Elm är ett ramverk och typat funktionellt programmeringsspråk som syftar till front-end-utveckling. Det inspirerar sig i ett programmeringsspråk som heter Haskell för att få mer underhållbarhet till Javascript, men hålla sig så enkel och nära Javascript som möjligt. Ramverkets arkitektur liknar Redux, som faktiskt var starkt inspirerad i Elm.
Glöm vad du har hört om funktionell programmering. Snygga ord, konstiga idéer, dåligt verktyg.
- Evan Czaplicki, Elms skapare
Vid utformningen av språket har Elms författare valt att sätta användaren i centrum för sina designval. Om du tittar på hans”Låt oss vara mainstream”, du kommer att märka ett starkt fokus på vem som är användaren (Javascript-programmeraren) och vad han behöver, genom att använda den så kallade Användningsdriven design. Denna filosofi reducerar språkfunktionerna till det väsentliga och gör det ganska lätt att lära sig.
[En] nyligen anställd mjukvarudesigner hade spridit ut källlistor på konferensbordet och försiktigt passerat en kristall som hängde från en lång kedja över källkoden. Då och då markerade designern en cirkel i rött på listan. Senare frågade en av mina kollegor designern vad han hade gjort i konferensrummet. Det nonchalanta svaret: ”Hitta buggarna i mitt program”.
Detta är en sann historia, det hände i mitten av 1980-talet när människor hade stora förhoppningar om dolda krafter i kristaller.
- MIT Press, Introduktion till algoritmer, Arton tryck (1997)
Elms felmeddelanden är extremt vänliga. Å ena sidan kommer detta från det statiska typsystemet, som gör det möjligt för kompilatorn att tydligt känna till och ange skillnaderna mellan de typer av värden som förväntas och de som tillhandahålls till våra funktioner. Å andra sidan, eftersom det inte finns några typklasser, är typen av information som visas i felmeddelanden mycket jordnära:
Förutom denna atypiska tydlighet bestämde språkdesignern att felmeddelanden skulle prioriteras, och förutom att formellt ange vad som är fel med programmen ger kompilatorn också ”tips” om vad som kan ha varit programmerarens avsikter och ger förslag på möjliga korrigeringar, till exempel:
[Haskell är värdelös.]
— Simon Peyton Jones, Stor bidragsgivare till utformningen av programmeringsspråket Haskell.
Det stämmer, det här är nej Haskell - Elms främsta inspirationskälla. Medan man följde den användningsdrivna designprocessen behövdes många av Haskells funktioner inte och lades därför inte till språket. Bland dem var det ökända typklasssystemet.
Det systemet skulle ta med sig allt det pretentiöst klingande matematiska ordförrådet som vanligtvis hörs bland Haskell-programmerare och göra Elm helt olämpligt för den ”vanliga Joe”.
Men behöver vi inte typklasser? De måste tjäna vilket syfte som helst! Varför behöver Haskell dem och Elm inte? - Tja, svaret bygger på problemdomänen som adresseras av vart och ett av dessa språk: Medan Haskell är ett allmänt programmeringsspråk, är Elm inte det. Å ena sidan är Elm helt enkelt ett frontend programmeringsspråk och kan utföra den uppgiften bra utan att tillgripa så mycket komplexitet. Å andra sidan hanteras en del av vad sådan komplexitet syftar till att hantera av och döljs i Elm-körtiden - som tar hand om att hantera biverkningar och mutation på ett domänspecifikt sätt.
Vi har haft noll körtidsfel [...]. Vi har också haft färre buggar, till stor del för att Elms typsystem tvingar dig att modellera din domän mer noggrant. För att sammanfatta det, vår chef har gett mandat att all ny kod ska skrivas i Elm.
— Jeff Schomay, Front-end-specialist på Pivotal Tracker
Elms typsystem är mycket säkert och det finns två konsekvenser av dess design som är värda att notera:
Mitt mål var att se till att all användning av referenser skulle vara helt säker, med kontroll som utförs automatiskt av kompilatorn. Men jag kunde inte motstå frestelsen [...]
Tony Hoare, uppfinnare av nollreferensen
Medan andra programmeringsspråk hanterar fel som en del av språket med mycket specifika funktioner - vanligtvis kallade undantag eller fel - har Elm inga specifika primitiv för att utlösa fel eller hantera dem. Risken för fel modelleras snarare genom de typer av värden som returneras och hanteras av funktioner. Vissa parametriska typer kan användas för att förmedla information om fel, till exempel typerna Kanske; Resultat och Uppgift.
Den Kanske typ är den enklaste av dessa. Det definieras som:
Den en i detta uttryck kan ersättas med någon specifik typ, t.ex. ett värde av typ Kanske sträng kan antingen anta ett värde som Bara ”någon specifik sträng” eller Ingenting.
Således returnerar en funktion ett värde på - till exempel - Kanske sträng kan returnera ett värde Bara ”Jag är den returnerade strängen” när du lyckas eller returnerar Ingenting när man misslyckas. Programmeraren tvingas senare alltid välja vad han ska göra i båda fallen och språket tillåter inte programmet att kompilera om båda möjligheterna inte hanteras.
Det är genom det tidigare visade tillvägagångssättet som språket undviker att ha ett nollvärde. Och därmed bli av med alla de vanliga undefined är inte en funktion fel. Om det kan uppstå ett fel kommer typen uttryckligen att förmedla denna information och kompilatorn tvingar detta fall att hanteras av programmeraren.
Eftersom Elm är ett rent funktionellt språk är syftet med att utvärdera något att få ett värde från det. Således tvingar Elm utvecklaren att tillhandahålla ett returvärde för varje kontrolluttalande. Detta innebär att varje om uttalandet behöver en annars klausul och fall uttalanden måste hantera alla möjliga ingångsvärden.
Låt oss till exempel titta på en abstrakt datatyp TypningDisciplin som kan antas som värde Statisk; Dynamisk eller Gradvis:
och om vi hanterar något värde av denna typ som inmatning av en case-sats (en switch-sats), men glömmer att hantera en av möjligheterna:
kompilatorn kompilerar programmet:
Således när vi ändrar våra typer för att lägga till mer funktionalitet, blir vi meddelade av kompilatorn att det finns någon kod som behöver läggas till för att hantera en ny möjlighet.
Du måste hitta det du älskar.
- Steve Jobs
Alm kort återkopplingsslinga och överskådlig syntax gör det till en mycket trevlig miljö att arbeta med. Låt oss ta en titt på hur dessa saker bidrar till Elms utvecklarglädje.
Undvik framgång till varje pris.
— Simon Peyton Jones, Stor bidragsgivare till utformningen av programmeringsspråket Haskell.
En intressant konsekvens av de tidigare beskrivna säkerhetsfunktionerna är hur de förkortar återkopplingsslingan. Programmeringsaktiviteten består vanligtvis av att iterera genom följande aktiviteter:
Det sista steget är ofta där utvecklarna tillbringar mest tid, och den här tiden spenderas antingen på att skriva automatiserade tester eller interagera med programmet för att bekräfta att det är korrekt. De flesta programmerare skulle säga att denna fas är den minst glada.
Elms säkerhet och brist på körtidsundantag överför en del av Testning fasinsats in i Kompilering fas. När du använder Elm kommer programmeraren att spendera lite mer tid på kompileringsfasen - interagera med kompilatorn tills programmet anses vara korrekt - och mycket mindre tid i testfasen, när det enda som kan misslyckas är om affärskraven är uppfyllda - och inte om programmet kraschar eller inte.
När du använder Elm kommer programmeraren att få feedback om sina misstag tidigare, utan att behöva spendera så mycket tid i den långa testfasen.
Elms syntax är inspirerad av Haskell och minimalistisk. Det finns bara två kontrolluttalanden; och väldigt få reserverade ord.
Mitten för denna syntax är funktionen. Om det mest använda syntaktiska inslaget i något strukturerat programmeringsspråk är funktionsåkallandet, varför använder de flesta språk i Algol-stil så många specialtecken för funktionsåkallande och definition?
För att skriva ovanstående definition och anrop var vi tvungna att skriva 8 specialtecken för funktionsdefinitionen:
och 4 på funktionsåkallandet:
Beroende på tangentbordets språk varierar antalet tryckta modifieringsknappar; irritation och för tidig repetitiv belastningsskada.
Elm rensar upp detta. Om funktionen är så viktig bör den enkelt skrivas och redigeras:
Som du ser behöver denna funktionsdefinition inga specialtecken. Typsignaturer är valfria och härleds automatiskt av kompilatorn, så att vi snabbt kan experimentera utan att behöva ange dem uttryckligen. Ändå är de användbara: ibland är det praktiskt att ha typsignaturen som vägledning när du skriver en mindre uppenbar kod, och de är ofta en användbar form av dokumentation. Således, i Elm, skrivs typsignaturer (valfritt) i en separat rad (vissa redaktörer genererar typsignaturen automatiskt när vi ber om det!) :
En annan egenskap som gör språket ganska roligt att använda är att varje funktion är curried och därmed kan tillämpas på en delmängd av dess argument, vilket returnerar en så kallad partiellt tillämpad funktion som bara väntar på de saknade argumenten. Således följande kod:
motsvarar följande Javascript-kod:
Den största fördelen med den här funktionen är att kod som använder högre ordningsfunktioner blir mycket ren:
Men om vi kedjar dessa operationer börjar vi få ett hav av kapslade parens typiska från a Läspa:
För att undvika detta problem tillhandahåller språket röroperatörerna (<| och |>). De tillåter kedjningsfunktionsapplikation med en syntax som liknar att tråda ett argument genom en pipeline av transformationer:
På liknande sätt; du kan också använda kompositionen (<<) eller omvänd sammansättning (>>) operatörer för att uttrycka detsamma utan att uttryckligen behöva hänvisa till argumentet som gängas:
Denna bekvämt kortfattade syntax, tillsammans med de fina felmeddelandena, gör Elm mycket lämplig för interaktiva experiment, både genom att använda REPL och genom att använda kompilatorn.
När du startar ett Elm-projekt får du omedelbart massor av funktionalitet direkt från lådan:
Och det är värt att utarbeta några andra verktyg:
Detta är en av de saker Redux fick från att implementera Elm-arkitekturen. När vi utvecklar och provar ett program kan vi inspektera de åtgärder som utförs på det gränssnittet och gå fram och tillbaka i tid för att analysera programmets tillstånd vid varje ögonblick av dess körning.
I Redux är denna funktionalitet ganska ömtålig på grund av Javascripts tvingande natur, och för att klara det måste man använda Oföränderlig eller ett annat bibliotek för att undvika att direkt mutera programmets tillstånd. I Elm existerar detta problem helt enkelt inte, eftersom det inte finns något sådant som mutation på språknivå. Språkdesignen i sig skyddar oss från denna typ av problem och från behovet av att använda ytterligare bibliotek.
Dessutom kan du fikla med språket direkt i webbläsaren - utan att behöva installera något. Följande är ett bra exempel på en webbplats som tillhandahåller live-redigeringsfunktionalitet:
När du publicerar en ny paketversion kontrollerar Elm-verktyget om funktionerna som exporteras av våra moduler:
Enligt var och en av dessa möjligheter kommer ändringen att återspeglas på det automatiskt beräknade paketets versionsnummer, vilket gör det klart om ändringarna är stora förändringar; mindre ändringar eller buggfixar; och om det är säkert att uppgradera versionen av ett bibliotek som används.
I del 2 - tillgänglig här - Jag kommer att prata om varför statisk typning och funktionell renhet ges, de nuvarande Javascripts ekosystemtrender. Jag kommer också att prata om vem som använder Elm och hur mogen den är. Håll dig uppdaterad, jag kommer att skriva om det nästa vecka.
Vid Imaginärt moln Vi har ett team av experter på mjukvaruutveckling. Om du tror att du kan behöva lite hjälp med ditt digitala projekt, skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Rails utvecklare med 10+ års erfarenhet av olika tekniker. Jag är intresserad av funktionell programmering.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
