Perl 6 blir Raku - men vad innebär det?

Nyligen godkände teamet bakom Perl 6 ett namnbyte för språket till Raku. Vi satte oss ner med Edumentaren Jonathan Worthington för att prata om vad det innebär, och vad som händer härnäst.

Börja med att snabbt sammanfatta din roll i projektet så här långt.

Allt började redan när jag var tonåring och mina föräldrar föreslog att jag skulle skaffa nåt litet extraknäck, och jag startade ett webbutvecklingsföretag. Jag tror att de förväntade sig att jag skulle dela ut tidningar eller nåt, men jag hatar morgnar och gillar inte regn speciellt mycket heller. Och jag växte upp i England, där det ofta regnar. I alla fall, Perl var språket man använde för backend-grejer på den tiden, så jag köpte boken Programming Perl. Den var bra, och efterhand lärde jag mig om regexer, objektorientering, stängningar och stötte på automatiserade tester för första gången.

Jonathan som en av talarna under PerlCon i Riga 2019

Snabbspola några år: Jag gick ut universitetet, där jag hade öppnat ett litet webbutvecklingsföretag där jag använde Perl under tiden. På universitetet blev jag intresserad av kompilerare, körtider, typsystem, formell semantik i programmeringsspråk och annat kul. Jag sprang på Perl 6-projektet och tänkte att det hade varit ett trevligt sätt att ge någonting tillbaka till communityt genom att bidra till kompileraren.

Jag föreställde mig att jag skulle göra lite patchningar här och där, men det slutade med att jag ritade om arkitekturen på hela kompileraren. Jag implementerade även metaobjektsystemet, skapade och ledde utvecklingen av en ny virtuell maskin samt antog rollen som concurrency- och parallellprogrammerare. Idag hanterar jag mer allmänna designproblem inom språket i arbetet med nya versioner. Samtidigt arbetar jag med escape analysis-relaterade optimeringar i den virtuella maskinen, vilket borde leda till en del schyssta prestandaförbättringar.

Och namnbytet. Hur kommer det sig?

I början av utvecklingen av Perl 6 gjordes en Request for Comments - det vill säga förslag på hur språket kunde förändras. Det förväntades komma några dussin förslag, men det kom flera hundra. De var så klart väldigt spridda och drog åt olika håll. Ibland var förslagen motstridiga, ibland pekade de på verkliga problem men förslagen på lösningar var inte tillräckliga, och så vidare. Det är ganska självklart att man inte kan skapa ett språk genom att bara blanda en massa människors förslag. Då får man bara en enda röra med inkonsekventa och överspecificerade lösningar, när allt man vill ha är en uppsättning väldefinierade lösningar som fungerar bra ihop.

Därmed inleddes en lång, lång designprocess med språket. Tanken att det skulle bli en avgörande förändring fanns med från början. Efterhand blev det tydligt att om designmålen skulle uppnås, var det mycket som behövde ändras, både när det gällde syntax och semantik. Perl har dessutom alltid tänjt på gränserna för språkdesign och implementering. Larry Wall är en ambitiös språkdesigner, och arbetar efter vad som är möjligt för språkimplementeringen, inte vad som är enkelt. Eller som det skämtsamt hette; "tortera språkimplementeraren för språkanvändarens skull".

Kombinera dessa krafter med att allt görs av en grupp frivilliga, så var det uppenbart att arbetet skulle ta lång tid. En bit in i projektet bestämdes det att, istället för att vara en uppföljare till Perl 5, skulle Perl 6 snarare ses som ett systerspråk. Det innebar att Perl 5 kunde fortsätta utvecklas fritt medan pressen på att få färdigt Perl 6 snabbt minskade och man kunde istället fokusera på kvaliteten på både kompilerare och språk. (Här gällde principen "billigt, snabbt, bra – du kan bara välja två, och "billigt var redan valt för oss). Medan synsättet om "systerspråket" till största del fungerade inom Perl-communityt, fungerade det inte lika bra ute i världen. Det var inte helt otänkbart att anta att det skulle göra det. När t.ex. filmen Terminator 2 kom ut innebar det ju inte att Terminator hade spelat ut sin roll och ingen någonsin skulle se den igen. På samma sätt innebär det ju inte att, bara för att ölen Rochefort 10 finns innebär det ju inte att Rochefort 8 inte fortfarande är lika god och bör övervägas, och lanseringen av Airbus A380 innebär ju inte att flygbolag har slutat köpa A320. Det finns massor av exempel på relaterade produkter med olika nummer. Tyvärr gäller det inte när produkten är ett programmeringsspråk, och till slut var alla rejält trötta på att förklara för folk om kopplingen mellan Perl 5 och 6.

Ett annat problem var varumärket Perl, vilket är väldigt välkänt – vilket är bra – men även bär på en del bagage – vilket är dåligt. En gång var Perl Språket man använde vid backend-utveckling. Detta var under en tid då nätet började spridas, och många utvecklare började skriva en massa Perl. Och mycket av den koden var urusel. Det är egentligen ingens fel, saker som vi tar för givna idag inom arkitekturen av webbapplikationer var det ingen som kände till då. Webbapplikationer som är skrivna i Perl idag – 5 eller 6 – är vanligtvis faktorerade på moderna sätt och är helt okey att arbeta med. Men tyvärr har varumärket "Perl" fått leva med en del ärr från tiden på topp, när de flesta av oss (inklusive jag) som bygger webbapplikationer fortfarande kämpade med att lära oss grunderna.

Förhoppningen var att Perl 5 och Perl 6 tillsammans skulle kunna få tillbaka varumärkets forna glans. Det lades stort arbete på det, och det lyckades till viss del, men man visste att det skulle vara svårt: Människor gillar inte att vara tvungna att ändra åsikt! Såhär i efterhand kan man även se att det försvårades en del av att Perl 5 och Perl 6 kallade sig själv lite annorlunda.

Det har diskuterats ett namnbyte på Perl 6 i omgångar under åren. Frågan har efterhand skiftat från att ett namnbyte är obetydligt till att vara en het fråga som drivits hårt av vissa och slagits ner lika hårt av andra. Slutligen blev namnbytet en fråga som drevs hårt av vissa, tolererades av andra och motsattes av relativt få. Det innebar att en tillräcklig konsensus nåddes om ett namnbyte.

Och hur känner du för resultatet?

Å ena sidan är jag optimistisk. Raku är ett otroligt och modernt språk, men ofta när folk såg ordet "Perl" tittade de åt ett annat håll (eller skämtade om linenoise eller frågade om det är ett dött språk). Det hölls även föreläsningar där språket visades upp under ett annat namn och publiken var mycket entusiastisk – och inte fick reda på förrän i slutet att de faktiskt hade tittat på en föreläsning om Perl 6! Nu kan vi prata om språket utan att först gå igenom och slå hål på en massa förutfattade meningar.

På samma sätt hoppas jag att de som fortsätter att hålla Perl 5 vid liv och utveckla det kommer att märka att uppfattningen av språket åtminstone förbättras lite, tack vare att budskapet blir enklare.

Samtidigt känns det även lite sorgligt. Namnet Perl 6 är betydelsefullt för mig; det är inte bara ett språk, utan även ett community där jag har fått många vänner under årens lopp. Som tur är finns det massor av driv att fortsätta ha gemensamma konferenser, och att fortsätta vara ett gemensamt community med två språk som delar många designvärden, även om språkens syntax och semantik i vissa fall är vitt skilda.

Var kom namnet "Raku" ifrån? Betyder det någonting?

Det betyder "bekvämlighet" eller "lätthet" på japanska, vilket på ett bra sätt reflekterar språkets mål att vara ett bekvämt språk att arbeta med, trots att - som jag sa tidigare, de som implementerar språket ofta får kämpa!

Den populäraste kompileraren för språket heter “Rakudo”, vilket betyder ungefär "kamelens sätt" (kamelen är en symbol som ofta associeras med Perl), och även "paradis". Vi kan alltså se det som ett sätt att "göra" Raku som språk.

Utanför programmeringsvärlden är "raku" associerat med keramiktillverkning – mycket passande faktiskt, då designprocessen för Perl 6 triggades av nån som var frustrerad över svårigheterna med utvecklingen av Perl 5 – och kastade en mugg i väggen!

Testkörning och täckningsfunktion i Comma, the Raku IDE

Edument har ett antal produkter som riktar sig åt Perl 6-utvecklare. Kommer de att byta namn till Raku? Ändras något annat i samband med namnbytet?

Efterhand, ja. Den senaste lanseringen av Comma, vår Raku IDE-produkt är först ut genom att:

• Börja godkänna de nya filändelserna som är associerade med Raku

• Börja känna igen exekverbara Raku-filer

Inget av detta är vanligt bruk än så länge, men det innebär att när folk väl börjar använda dem så är vi redo. Vi ska även, i en framtida uppdatering, gå igenom Comma och ändra alla ställen där gränssnittet refererar till Perl 6 till Raku.

Comma kan identifiera sätt att förenkla koden och automatiskt tillämpa dem

Cro, en uppsättning bibliotek och verktyg som oftast används till att bygga webbapplikationer, kräver väldigt få ändringar. Rakudo-teamet arbetar överlag hårt med att uppgradera kompileraren till en ny version som inte krockar med existerande kod – vilket bland annat innebär att köra testsekvenser för alla publicerade moduler mot lanseringskandidater för att hitta regressioner som inte fångades upp av de språkspecifika testsekvenserna. Språkets namnbyte hanteras på samma sätt. Det kommer till exempel en tid då man börjar använda de nya filändelserna, men de gamla kommer att stödjas i många år framöver. Vi vill i allmänhet minimera krånglet för de som redan använder språket.

Utöver namnbytet så antar jag det finns mycket annat för Raku-programmerare att se fram emot? Kan du berätta lite om vad du och ditt team arbetar med?

Det är massor av spännande saker på väg. Vi kan börja med Comma IDE:t. Det är redan det kraftfullaste utvecklarverktyget för Raku-programmerare, men vi vill fortfarande göra mycket mer!

En animering som visar hur du kan utforska hur tid tillbringas i ett program med inloggning i Comma

Parallellprogrammering och concurrency i Raku har blivit mycket populärt, och även att kunna visualisera vad som händer inuti sådana program ökar förståelsen rejält. Vi utvecklade nyligen ett sätt att annotera program genom loggning av uppgifter, som sedan kan visualiseras live i IDE:t. Vi annoterade även Cro, så att man direkt från början kan visualisera hur HTTP-begäran flödar genom pipelinen, och var de befinner sig och när (i mellanprogram, hos request handlern, etc.). Det är dock inte allt! Vi vill göra det möjligt att även visualisera program utan sådana annotationer, samt ha information om skräpsamling och optimeringsrelaterade händelser på samma diagram, om detta är vad programmeraren vill ha. Vi har även planer på att förbättra avlusningsupplevelsen för parallella program.

Vi har dessutom en massa idéer om profilern, och planen är även att integrera heap snapshot-analys i någon av de kommande uppdateringarna av Comma. Utbudet av programanalyser och transformationer som vi kan erbjuda kommer även att fortsätta växa, vilket kommer att hjälpa människor utveckla korrekta program och effektivare refaktorer. Grammatik – som används för att skriva parsrar – har också visat sig vara en populär Raku-funktion, så vi kommer att titta på hur vi kan förbättra utvecklingsupplevelsen kring att använda dem också, kanske med någon slags live-förhandsvisning.

Cro är redan ett populärt val när det kommer till att skriva webbapplikationer I Raku, men det finns fortfarande mycket kvar att göra. Cro var alltid avsett att vara ett allmänt bibliotek för att skriva distribuerade system, så vi kommer att hitta sätt att skriva pipelines som arbetar mot en meddelandekö snarare än hanterar web requests. Vi vet dock att webbtjänster och webbapplikationer utgör majoriteten av användningen av Cro idag, så det kommer naturligtvis att läggas stort fokus på att göra saker ännu bättre för dem. Faktum är att servicehistorien för närvarande är rejält mycket starkare än applikationshistorien. Vi försökte aldrig vara ett "webbramverk", men har kommit att användas som ett i alla fall. Baserat på det har vi nyligen lagt till ett mallspråk (och har naturligtvis stöd för det i Comma!) och kommer att titta på andra saker vi kan göra för att effektivisera sådan utveckling. Allra först planerar vi att tillhandahålla olika resilience patterns som t.ex. retires och circuit breakers, samt stöd för att enkelt bygga olika typer av proxy.

När det gäller själva Raku, är det massor av människor som gör massor av utmärkt jobb. Jag har fokuserat främst på prestanda och driftsäkerhet de senast åren, och under de kommande månaderna kommer jag att lämna in en stor del av mitt senaste arbete med escape analysis. Perl är väldigt objektorienterat, och optimering som helt kan eliminera, eller åtminstone skjuta upp, allokeringar så att vi kan analysera insidan av objektgränsen, kan innebära en efterlängtad hastighetsökning i många applikationer. Utöver det kommer jag antagligen att titta på effektivare sätt att kompilera och exekvera grammatik.

Ett annat stort block med arbete kommer att handla om makron, vilket i sin tur leder till att skapa ett API till själva språket. Designen har redan provats i ett litet experimentspråk, och nu gäller det att överföra det till Raku. Det ger även en möjlighet att titta på en del av kompilerararens interna delar på nytt, och kanske göra dem ännu effektivare.

Wow, så många planer! Och det är inte bara Raku som ditt team i Prag sysslar med, eller hur?

Det stämmer, vi deltar i flera andra projekt för Eduments kunder. Vi specialiserar oss på kompilerare, körtider, språkdesign och utvecklarverktyg, och vi tar gärna på oss utmaningar inom dessa områden. Vi är glada över att ha fått flera sådana projekt på sistone. Så, vi är upptagna men har roligt samtidigt!

Lycka till med allt, och tack för att du tog dig till att prata med oss!

Varsågoda!

Med Jonathan Worthington