Jeg har kigget på Elm-programmeringssproget og Elm-rammen. De er en typet funktionel programmeringstilgang til frontend, der påvirker andre populære teknologier på en noget forstyrrende måde. Denne artikel er en opskrivning af, hvad jeg har fundet ud af om Elm.
Denne artikel vil blive opdelt i to dele. I denne første del vil jeg fokusere på de funktioner, der gør Elm til et interessant alternativ til Javascript.
I anden del vil jeg fokusere på det historiske perspektiv, der gør Elm værd at se på; uddybe sprogets to hovedtræk: funktionel renhed og statisk typing; og endelig se på, hvem der bruger Elm i den virkelige verden.
Elm er et framework og typet funktionelt programmeringssprog rettet mod front-end udvikling. Det inspirerer sig selv i et programmeringssprog kaldet Haskell at bringe mere vedligeholdelsesevne til Javascript, selvom det holder sig så enkelt og tæt på Javascript som muligt. Rammens arkitektur ligner Redux, der faktisk var stærkt inspireret i Elm.
Glem hvad du har hørt om funktionel programmering. Fantastiske ord, underlige ideer, dårligt værktøj.
- Evan Czaplicki, Elms skaber
Ved udformningen af sproget har Elms forfatter valgt at sætte brugeren i centrum for sine designvalg. Hvis du kigger på hans“Lad os være mainstream„, vil du bemærke et stærkt fokus på, hvem der er brugeren (Javascript-programmøren), og hvad har han brug for, ved at anvende de såkaldte Brugsdrevet design. Denne filosofi reducerer sprogfunktionerne til det væsentlige og gør det ret nemt at blive lært.
[En] nyligt ansat softwaredesigner havde spredt kildelister på konferencebordet og forsigtigt sendt en krystal hængende fra en lang kæde over kildekoden. Af og til markerede designeren en cirkel i rødt på listen. Senere spurgte en af mine kolleger designeren, hvad (r) han havde lavet i mødelokalet. Det nonchalante svar: „Find fejlene i mit program“.
Dette er en sand historie, det skete i midten af 1980'erne, da folk havde store forhåbninger om skjulte kræfter i krystaller.
- MIT Presse, Introduktion til algoritmer, Atten tryk (1997)
Elms fejlmeddelelser er yderst venlige. På den ene side kommer dette fra det statiske typesystem, der gør det muligt for kompilatoren klart at kende og angive forskellene mellem de typer af værdier, der forventes, og dem, der leveres til vores funktioner. På den anden side, da der ikke er nogen typeklasser, er typen af information, der vises i fejlmeddelelser, meget jordnær:
Ud over denne atypiske klarhed besluttede sprogdesigneren, at fejlmeddelelser skulle være en prioritet, og ud over formelt at angive, hvad der er galt med programmerne, giver kompilatoren også 'tip' om, hvad der kunne have været programmererens intentioner og giver forslag til mulige rettelser, for eksempel:
[Haskell er ubrugelig.]
— Simon Peyton Jones, Stor bidragyder til designet af Haskell programmeringssprog.
Det er rigtigt, dette er nej Haskell - Elms vigtigste inspirationskilde. Mens man fulgte den brugsdrevne designproces, var mange af Haskells funktioner ikke nødvendige og blev derfor ikke føjet til sproget. Blandt dem var det berygtede typeklassesystem.
Dette system ville medbringe alt det prætentiøst klingende matematiske ordforråd, der typisk høres blandt Haskell-programmører, og gøre Elm totalt upassende for den „almindelige Joe“.
Men har vi ikke brug for typeklasser? De skal tjene ethvert formål! Hvorfor har Haskell brug for dem, og Elm har ikke brug for dem? - Nå, svaret afhænger af problemdomænet, der behandles af hvert af disse sprog: Mens Haskell er et programmeringssprog til generelle formål, er Elm ikke det. På den ene side er Elm simpelthen et frontend programmeringssprog og er i stand til at udføre denne opgave godt uden at ty til så meget kompleksitet. På den anden side håndteres en del af, hvad en sådan kompleksitet sigter mod at håndtere, af og skjules i Elm-runtime - som tager sig af håndtering af bivirkninger og mutation på en domænespecifik måde.
Vi har haft nul kørselsfejl [...]. Vi har også haft færre fejl, hovedsageligt fordi Elms typesystem tvinger dig til at modellere dit domæne mere omhyggeligt. For at opsummere det, har vores manager pålagt, at al ny kode skrives i Elm.
— Jeff Schomay, Front end-specialist hos Pivotal Tracker
Elms typesystem er meget sikkert, og der er to konsekvenser af dets design, der er værd at bemærke:
Mit mål var at sikre, at al brug af referencer skulle være helt sikker, med kontrol udført automatisk af kompilatoren. Men jeg kunne ikke modstå fristelsen [...]
Tony Hoare, opfinder af nulreferencen
Mens andre programmeringssprog håndterer fejl som en del af sproget med meget specifikke funktioner - normalt kaldet undtagelser eller fejl - indeholder Elm ingen specifikke primitiver til at udløse fejl eller håndtere dem. Muligheden for fejl er snarere modelleret gennem de typer værdier, der returneres og håndteres af funktioner. Nogle parametriske typer kan bruges til at formidle information om fejl, såsom typerne Måske; Resultat og Opgave.
Den Måske typen er den mest enkle af disse. Det defineres som:
Den a i dette udtryk kan erstattes af en hvilken som helst bestemt type, f.eks. en værdi af typen Måske String kan enten antage en værdi som Bare „en bestemt streng“ eller Ingenting.
Således returnerer en funktion en værdi på - for eksempel - Måske String kan returnere en værdi Bare „Jeg er den returnerede streng“ når det lykkes eller vender tilbage Ingenting når man fejler. Programmøren er senere altid tvunget til at vælge, hvad han skal gøre i begge tilfælde, og sproget tillader ikke programmet at kompilere, hvis begge muligheder ikke håndteres.
Det er gennem den tidligere viste tilgang, at sproget undgår at have en nulværdi. Og dermed slippe af med alle de sædvanlige undefined er ikke en funktion fejl. Hvis der kan være en fejl, vil typen eksplicit formidle disse oplysninger, og kompilatoren vil tvinge denne sag til at blive håndteret af programmøren.
Da Elm er et rent funktionelt sprog, er formålet med at evaluere noget at få en værdi ud af det. Således tvinger Elm udvikleren til at give en returværdi for hver kontrolsætning. Dette indebærer, at hver hvis Udtalelsen har brug for en andet klausul og hylster udsagn skal håndtere alle mulige inputværdier.
Lad os for eksempel tage et kig på en abstrakt datatype TypeDisciplin Det kan antages som værdi Statisk; Dynamisk eller Gradvis:
og hvis vi håndterer en værdi af denne type som input til en case-sætning (en switch-sætning), men glemmer at håndtere en af mulighederne:
kompilatoren kompilerer programmet:
Når vi ændrer vores typer for at tilføje mere funktionalitet, ender vi med at blive underrettet af kompilatoren om, at der er noget kode, der skal tilføjes for at håndtere en ny mulighed.
Du er nødt til at finde det, du elsker.
- Steve Jobs
Elm kort tilbagemeldingssløjfe og ryddig syntaks Gør det til et meget behageligt miljø at arbejde med. Lad os se på, hvordan disse ting bidrager til Elms udviklerglæde.
Undgå succes for enhver pris.
— Simon Peyton Jones, Stor bidragyder til designet af Haskell programmeringssprog.
En interessant konsekvens af de tidligere beskrevne sikkerhedsfunktioner er, hvordan de forkorter feedbacksløjfen. Programmeringsaktiviteten består normalt i at iterere gennem følgende aktiviteter:
Det sidste trin er ofte, hvor udviklerne bruger mest tid, og denne tid bruges enten på at skrive automatiserede tests eller interagere med programmet for at bekræfte, at det er korrekt. De fleste programmører vil sige, at denne fase er den mindst glædelige.
Elms sikkerhed og mangel på runtime-undtagelser overfører en del af Afprøvning faseindsats ind i Kompilering fase. Når du bruger Elm, vil programmøren bruge lidt mere tid på kompileringsfasen - interagere med kompilatoren, indtil programmet betragtes som korrekt - og meget mindre tid i testfasen, når det eneste, der kan mislykkes, er, om forretningskravene er opfyldt - og ikke om programmet går ned eller ej.
Når du bruger Elm, vil programmøren have feedback om sine fejl hurtigere, uden at skulle bruge så meget tid i den lange testfase.
Elms syntaks er inspireret af Haskell og minimalistisk. Der er kun to kontroludsagn; og meget få reserverede ord.
Midten i denne syntaks er funktionen. Hvis det mest anvendte syntaktiske træk ved ethvert struktureret programmeringssprog er funktionsinvokationen, hvorfor tyr de fleste sprog i Algol-stil til så mange specialtegn til funktionsinkaldelse og definition?
For at skrive ovenstående definition og påkaldelse måtte vi skrive 8 specialtegn til funktionsdefinitionen:
og 4 på funktionsinvokationen:
Afhængigt af tastaturets sprog varierer antallet af trykte modificertaster; irritation og for tidlig gentagen belastningsskade.
Elm rydder op i dette. Hvis funktionen er så vigtig, skal den let skrives og redigeres:
Som du ser, behøver denne funktionsdefinition ikke nogen specialtegn. Typesignaturer er valgfrie og udledes automatisk af kompilatoren, så vi hurtigt kan eksperimentere uden at skulle indtaste dem eksplicit. Ikke desto mindre er de nyttige: nogle gange er det praktisk at have typesignaturen som vejledning, mens du skriver et mindre indlysende stykke kode, og de er ofte en nyttig form for dokumentation. I Elm skrives typesignaturer således (valgfrit) i en separat linje (nogle redaktører genererer typesignaturen automatisk, når vi beder om det!) :
En anden funktion, der gør sproget ret sjovt at bruge, er, at hver funktion er kurret og dermed kan anvendes på en delmængde af dens argumenter, hvilket returnerer en såkaldt delvist anvendt funktion, der kun venter på de manglende argumenter. Således følgende kode:
svarer til følgende Javascript-kode:
Den største fordel ved denne funktion er, at kode, der bruger funktioner med højere orden, bliver meget ren:
Men hvis vi kæder disse operationer, begynder vi at få et hav af indlejrede parens, der er typiske fra en læspen:
For at undgå dette problem giver sproget røroperatørerne (<| og |>). De tillader kædefunktionsapplikation med en syntaks svarende til at tråde et argument gennem en pipeline af transformationer:
På en lignende måde; du kan også bruge sammensætningen (<<) eller omvendt sammensætning (>>) operatører til at udtrykke det samme uden eksplicit at skulle henvise til argumentet, der bliver trådt:
Denne bekvemt kortfattede syntaks sammen med de pæne fejlmeddelelser ender med at gøre Elm meget velegnet til interaktiv eksperimentering, både ved at bruge REPL og ved at bruge kompilatoren.
Når du starter et Elm-projekt, får du straks masser af funktionalitet ud af boksen:
Og det er værd at uddybe nogle andre værktøjer:
Dette er en af de ting, Redux fik ved at implementere Elm-arkitekturen. Når vi udvikler og prøver et program, er vi i stand til at inspicere de handlinger, der udføres på denne grænseflade, og gå frem og tilbage i tide for at analysere programmets tilstand på hvert øjeblik af dets udførelse.
I Redux er denne funktionalitet temmelig skrøbelig på grund af Javascripts tvingende karakter, og for at klare det er man forpligtet til at bruge Uforanderlig eller et andet bibliotek for at undgå direkte at mutere applikationens tilstand. I Elm eksisterer dette problem simpelthen ikke, fordi der ikke er sådan noget som mutation på sprogniveau. Selve sprogdesignet beskytter os mod denne form for problemer og fra behovet for at bruge yderligere biblioteker.
Derudover kan du fikle med sproget direkte i webbrowseren - uden at skulle installere noget. Følgende er et godt eksempel på et websted, der leverer live-redigeringsfunktionalitet:
Når du udgiver en ny pakkeversion, kontrollerer Elm-værktøjet, om de funktioner, der eksporteres af vores moduler:
I henhold til hver af disse muligheder vil ændringen blive afspejlet på den automatisk beregnede pakkes versionsnummer, hvilket vil gøre det klart, om ændringerne er større ændringer; mindre ændringer eller fejlrettelser; og om det er sikkert at opgradere den version af et bibliotek, der bruges.
I del 2 - Tilgængelig her - Jeg vil tale om hvorfor statisk typning og funktionel renhed gives, de nuværende Javascripts økosystemtendenser. Jeg vil også tale om, hvem der bruger Elm, og hvor moden den er. Vær venlig at holde øje med det, da jeg skriver om det i næste uge.
Ved Imaginær sky Vi har et team af eksperter inden for softwareudvikling. Hvis du tror, du kunne bruge lidt hjælp til dit digitale projekt, så send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Rails-udvikler med 10+ års erfaring med forskellige teknologier. Jeg er interesseret i funktionel programmering.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
