Elixir, můj nový oblíbený programovací jazyk

15.1.2015 20:30 | Přečteno: 4203× | Programování |

Zajímají vás programovací jazyky? Ještě jste neslyšeli o Elixiru? Zkusím vám ho krátce přiblížit.

Co je Elixir?

Elixir je dle Wikipedie jazyk "vícero paradigmat, funkcionální, souběžný (concurrent), orientovaný na procesy a homoikonický". Pokud vám tyto termíny moc neříkají, ale Erlang něco ano, tak vězte, že se jedná o jazyk, který se překládá do Erlang VM (BEAM formát). Odtud si berou ty první čtyři termíny definice. Pátý přijde na řadu za chvíli.

Proč se nespokojit s Erlangem?

Erlang je fajn jazyk. Je vyspělý, takže se vám jen tak nerozsype pod rukama (koukám na tebe, C++11). Je příjemně paralelní a distribuovaný, založený na myšlence nesdílené paměti a posílání zpráv (to řeší spoustu běžných problémů paralelních aplikací, ale přináší některé jiné). Je funkcionální, ale ne pedant (můžete bez problémů napsat printf). Všechno je výraz a má tedy hodnotu. Má pattern matching, který neuvěřitelně zkracuje kód. Má prostředky pro budování robustních aplikací. Jsou v něm psány velké projekty. Na root.cz o něm teď vychází česky psaný seriál.

Bohužel není všechno zlato, co se třpytí. Není zdaleka vhodný na všechny problémy - výše zmíněné projekty mají relativně dost věcí společných. Zároveň je v něm pár nepříjemných vlastností daných návrhem jazyka a jedna velká kategorie je syntax. V Erlangu není vždy příjemné psát. A bohužel ono pověstné "user experience" člověka může dovést k tomu, že se ho snaží vylepšit a občas zajde za hranu (jako já s makry, šablonami a lambda funkcemi v C++11).

Co vylepšuje Elixir?

Elixir je jazyk, který vylepšuje Erlang po stránce organizace kódu. Dosahuje toho trochu jinou syntaxí, jinými možnosti uspořádání kódu a silnými makry. Jako třešničku na dortu přidává vyřešený problém se stringy. Zde je hezké srovnání.

Syntax Erlangu byla inspirována Prologem, Smalltalkem a CSP (jak píše sám autor Erlangu), což bohužel nejsou jazyky, kterým dnešní programátoři úplně rozumí. Pro mnoho z nich proto může být těžko srozumitelný. Krom toho má pár nepraktických vlastností - jako jediné přiřazení do proměnné. Přidat transformaci promenné doprostřed funkce tak znamená najednou přepsat všechna její další použití. Nebo nelze vždy prohodit řádky, neboť poslední musí končit tečkou. Tyto nepříjemnosti člověka štvou, a on si na ně buď zvykne, nebo odejde. A ideálně stvoří něco jako Elixir.

Elixir má syntax inspirovaný především Ruby a Clojure. Tyto jazyky jsou dnes lidem bližší, takže již ze začátku jazyk působí familiárněji. Proměnné je možné přepisovat, řádky prohazovat.

Faktoriál v Erlangu

-module(recursive).
-export([fac/1]).
 
fac(N) when N == 0 -> 1;
fac(N) when N > 0  -> N*fac(N-1).

Zdroj

Ekvivalentní kód v Elixiru

defmodule Recursive do
  def fac(n) when n == 0 do
    1
  end

  def fac(n) when n > 0 do
    n * fac(n - 1)
  end
end

Ale tady nekončí. Oproti Erlangu nabízí polymorfismus fungující na principu protokolů. Přibyl 'pipe' operátor - ten vezme výsledek posledního výrazu a předá ho jako první argument další funkci. Výraz

scale(translate(multiply(matrix1, matrix2), vector), 0.5)

se dá v Elixiru zapsat takto:

matrix1
|> multiply(matrix2)
|> translate(vector)
|> scale(0.5)

Co je pro vás čitelnější?

Co je ta homoikonicita?

Zde zase pomůže Wikipedie: je to jazyk, jehož vnitřní reprezentace (AST) je stejná jako jeho syntax (je mu izomorfní). Díky tomu lze ke kódu přistupovat a transformovat ho jako jakákoliv jiná vstupní data. Tato vlastnost vede k umožňuje velmi silná makra, která jsou přímo v jazyce a jsou "hygienická" (implicitně nekolidují s identifikátory v místě, odkud jsou vyvolána). Je tedy jednoduché a bezpečné makra psát a používat. Tato vlastnost umožňuje elegantně tvořit DSL - Domain specific languages. Toho využívá například testovací framework ExUnit, který je součástí standardní distribuce:

defmodule ProjectTest do
  use ExUnit.Case

  test "the truth" do
    assert 1 + 1 == 2
  end
end

Makro test vytvoří a zaregistruje funkci testu. ExUnit díky tomu ví o všech testech, umí je filtrovat, při chybě ví, o který test se jedná a podle toho vytiskne adekvátní chybovou zprávu. Vše použitelné jedním nově definovaným klíčovým slovem. A implementace bez nutnosti použít cokoliv jiného, než sám jazyk nabízí.

Dalším příkladem je implementace Unicode, která si při kompilaci přečte definici formátu a podle toho vygeneruje nativní kód, který za běhu již nic takového nepotřebuje. Jazyk jde dokonce tak daleko do extrému, že většina základních konstrukcí jsou interně makra.

Co dalšího?

Elixir běží na Erlang VM a lze díky tomu snadno používat všechny jeho existující nástroje a knihovny. Je zde vestavěný build nástroj mix, který spravuje projekty a umí pracovat se závislostmi. Rozvíjí se hex.pm, seznam knihoven, které lze snadno začlenit do vašeho projektu. Zároveň je s otevřeným zdrojovým kódem (Apache licence).

Proč Elixir ne?

V rámci sebereflexe je vhodné uvést pár argumentů proti Elixiru. Je to mladý jazyk (založen 2012), takže není moc známý. Není tolik lidí, co jazyk znají a co v něm programují (a mohli by s vámi spolupracovat). Přestože už došel ke stabilní verzi 1.0, jsou v něm chyby. Není tolik dostupných zdrojů, i když se objevují nové. Je postaven na Erlangu, který je principiálně vhodný jen na určitou sadu problémů (a s tím Elixir nic moc neudělá). Paralelismus je sám o sobě obtížný a přestože metoda posílání zpráv spoustu neduhů řeší, není zdaleka všelékem. Přístup k paralelismu přináší problémy, na které člověk není z jiných jazyků zvyklý (vše se kopíruje, takže velké datové struktury umí být nepříjemně pomalé).

Kde se o Elixiru dozvím více?

Nejlepší je začít na oficiální stránce. Je zde mimo jiné obsáhlý tutoriál. K dispozici je již i pár knih a série screencastů. Krom toho je spousta projektů veřejně dostupných na Githubu a komunita živě diskutuje na IRC a emailových konferencích.

Co v Elixiru píši já?

Pracuji teď na demu projektu, ze kterého bych rád udělal start-up. Toto demo programuji v několika jazycích, ale jeho hlavní část je v Elixiru. Zatím mohu prozradit jen to, že cílovou skupinou jsou programátoři - takže o něm určitě ještě uslyšíte.

Další zajímavé odkazy

• Erlang: What's it good and not good for?
• What Sucks About Erlang
• Why Elixir?

       

Komentáře

[Radek Miček]

BTW ten faktoriál mi přijde přehlednější v Erlangu.

je to jazyk, jehož vnitřní reprezentace (AST) je stejná jako jeho syntax (je mu izomorfní)

Zcela jistě platí, že když je to stejné, tak je to i izomorfní. Naopak už to platit nemusí.

Krom toho bych pochyboval o správnosti slova izomorfní v té definici.

[Ivorne]

Izomorfismus je jasně definovaný pojem a nevidím důvod, proč by tuto vlastnost nemohl programovací jazyk mít.

[Radek Miček]

Protože by tím pojem homoikonicity ztratil smysl. Chcete-li v programovacím jazyce reprezentovat nějaké objekty, tak je celkem přirozené pokusit se o izomorfní reprezentaci. Tudíž nedefinujete nic zajímavého.

Např. aritmetický výraz

a+b*c

může být reprezentován jako

Expr(Plus, Var "a", Expr(Mult, Var "b", Var "c"))

a bude to izomorfní reprezentace. Budete však takový jazyk nazývat homoikonický?

[Ivorne]

No já vlastně slyším pojem homoikonicita prvně, takže spíš píšu, co si tak myslím. Každopádně mezi uvedenými výrazy nevidím velký rozdíl. To první je infixový zápis a to druhé je prefixový zápis. Nevidím problém, proč by to nemohlo být homoikonické - netvrdím, že to je homoikonické, jen mě teď nenapadá, proč by nemohlo.

[Radek Miček]

Každopádně mezi uvedenými výrazy nevidím velký rozdíl.

Tohle ale platí pro většinu programovacích jazyků. Tím pádem to není zajímavé.

Na druhou stranu, pokud budeme chtít skutečně izomorfismus mezi konkrétní syntaxí (co píše programátor) a AST, tak ten nebude skoro nikde – např. různé zápisy téhož se naparsují na 1 AST – konkrétním příkladem může být různý počet mezer na konci programu.

[Ivorne]

Každopádně mezi uvedenými výrazy nevidím velký rozdíl.

Tohle ale platí pro většinu programovacích jazyků. Tím pádem to není zajímavé.

Tak řada jazyků nemá výsledný kód izomorfní se zdrojovým kódem - z kompilovaných jazyků to nemá žádný a například jazyky nad JVM to taky nemají (bytekód je kód zásobníkového počítače). A dokážu si představit, že když si člověk nedá pozor, tak se mohou objevit rozdíly mezi zdrojákem a AST i u čistě interpretovaných jazyků.

Co jiného, než izomorfismus zdrojového a výstupního kódu by mělo být zajímavé?

Na druhou stranu, pokud budeme chtít skutečně izomorfismus mezi konkrétní syntaxí (co píše programátor) a AST, tak ten nebude skoro nikde – např. různé zápisy téhož se naparsují na 1 AST – konkrétním příkladem může být různý počet mezer na konci programu.

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní. Jak to vidím já, tak programy s různým počtem mezer na konci jsou spolu izomorfní.

[Radek Miček]

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní. Jak to vidím já, tak programy s různým počtem mezer na konci jsou spolu izomorfní.

Pokud se dva programy s různým počtem mezer na konci naparsují na stejný AST, tak už parsování nemůže být izomorfismus, neboť nemůže existovat levý inverz.

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní.

Pokud máte na mysli ekvivalentní místo izomorfní, tak ano.

Tak řada jazyků nemá výsledný kód izomorfní se zdrojovým kódem

Myslel jsem, že tu jde o izomorfismus mezi AST a zdrojovým kódem.

[random]

Pokud se dva programy s různým počtem mezer na konci naparsují na stejný AST, tak už parsování nemůže být izomorfismus, neboť nemůže existovat levý inverz.

Homoikonicita se zabývá programem na syntaktické, nikoliv lexikální úrovni.

[Radek Miček]

Co přesně myslíte syntaktickou úrovní?

Mj. bavíme se o definici

je to jazyk, jehož vnitřní reprezentace (AST) je stejná jako jeho syntax (je mu izomorfní)

a já jsem si pod syntaxí představil konkrétní syntax, tj. zdrojový kód. Ještě bych si mohl představit abstraktní syntax, tj. AST, ale to by ta definice pak byla tautologie.

[AsciiWolf]

BTW ten faktoriál mi přijde přehlednější v Erlangu.

+1

[Jan33]

Díky za post, i když to nevyužuju, je dobré o tom vědět. Budu sledovat.

[:::]

z wikipedie:

If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree

Existuji snad jazyky kde tohle neplati? Jaky smysl by melo vytvaret AST ktery nezachycuje strukturu kodu?

[Bystroushaak]

Není také jednou z podmínek, že z toho zdroje máš k tomu AST přístup?

[pavlix]

To není odpověď na položenéé otázky.

[random]

Ale je to důležité. Homoikonicita (jak ji chápu já) znamená, že AST je

1. jednoduchý,
2. přístupný a
3. editovatelný.

Samozřejmě, že skoro každý AST, který přímo vznikne naparsováním zdrojáku (čili bez optimalizací a tak) tomu zdrojáku odpovídá. Ale jak se třeba naparsuje posloupnost příkazů v Céčku?

a();
b = c + d;
e(b);

Vznikne z toho strom, ve kterém kořen odpovídá celému bloku kódu a v jeho synech jsou jednotlivé příkazy, nebo z toho vznikne spoják těch příkazů? Podle toho, co potřebuju, je výhodnější buď to první, nebo to druhé. Zdrojáku pochopitelně odpovídají obě možnosti, záleží na tom, jak se na něj dívám.

[pavlix]

Homoikonicita (jak ji chápu já) znamená, že AST je jednoduchý, přístupný a editovatelný.

To by musel být zcela nevhodně zvolený pojem. Z jeho názvu se zdá, že znamená, že máš více věcí a jsou v něčem stejné, v tomto případě jsem to pochopil tak, že se mají ve struktuře shodovat kód a AST, ale to jsem vždycky považoval za samozřejmost. Jediné, co mě napadá je, že chtějí nějak explicitně vyjádřit absenci preprocessingu, optimalizací a podobných věcí. A protože jim přišlo hloupé se vytahovat absencí funkcionality (byť dobře odůvodněnou), tak tomu chtěli dát nějaký pozitivní název.

Vznikne z toho strom, ve kterém kořen odpovídá celému bloku kódu a v jeho synech jsou jednotlivé příkazy, nebo z toho vznikne spoják těch příkazů?

Když z toho uděláš strom, vznikne z toho kupodivu strom. Zda je ten strom reprezentován v paměti pomocí spojových seznamů, je implementační detail. Žádné dvě možnosti v tom nevidím.

[random]

Když z toho uděláš strom, vznikne z toho kupodivu strom. Zda je ten strom reprezentován v paměti pomocí spojových seznamů, je implementační detail. Žádné dvě možnosti v tom nevidím.

Ano, AST je strom. Bavím se o tom, jak ten strom vypadá. Je plochý (otec s mnoha syny) nebo vysoký (hlava a ocas)?

Bison:

commands: command
        | commands SEMICOLON command
        ;

Z tohohle přímočarým způsobem vyjde ten spoják. Na editaci ale není nic moc, protože ho při každé změně musím procházet.

Implementační detail to není, protože se jedná o rozhraní.

[pavlix]

Obávám se, že se zcela míjíme.

[pavlix]

Samozřejmě, že skoro každý AST, který přímo vznikne naparsováním zdrojáku (čili bez optimalizací a tak) tomu zdrojáku odpovídá.

Ty optimalizace dokonce zmiňuješ, pak je tu ještě ten preprocessing, protože makra jsou třeba v céčku řešena zcela nezávisle na AST. Na druhou stranu bych očekával, že makra pracující s AST projdou preprocesingem a z toho AST během své expanze úplně zmizí, takže by ten výsledný AST taky nemusel vypadat jako původní kód, jen by byl z něj dobře předvídatelný.

[pavlix]

Wikipedia:

If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree (i.e. the AST and the syntax are isomorphic). This allows all code in the language to be accessed and transformed as data, using the same representation.

Mně se zdá spojení mezi těmi dvěma větami úplně vycucané z prstu. To zda můžu vystavět či upravovat kód v AST přece záleží jenom na tom, zda k tomu AST dostanu přístup. Pokud bych měl céčko kompilované do speciálního prostředí, kde budu mít za běhu přístup k AST funkcí a rutiny na manipulaci s ním, pak budu přistupovat ke kódu jako k datům přesně tak jak to píšou. To je ale především vlastnost běhového prostředí, takže jediné, co pro to může udělat jazyk je mít ve specifikaci, že vyžaduje takové běhové prostředí a případně nabízet nějaký ten syntaktický cukr.

[Ivan]

Asi se tim mysli i opacna "konverze". Tzn: z AST muzu zase dostat nazpatek cely zdrojak (az na komentare a mezery). Tohodle napriklad vyuzivaji ruzne udelatory v eclipse pro refactoring.

Souhlasim s tim, ze tohle hlavne runtime toho jazyka a API pro pristup k tomu AST. A asi se s tim da hodne prasit, v porovnani s obycejnou reflexi (jako se to dela v Jave). Tam mate pristup pouze k definicim trid a metod.

[Milan]

No ja radsi primo Erlang.

[kralyk z abclinuxu]

Výraz

scale(translate(multiply(matrix1, matrix2), vector), 0.5)

se dá v Elixiru zapsat takto:

matrix1
|> multiply(matrix2)
|> translate(vector)
|> scale(0.5)

Co je pro vás čitelnější?

Z mého pohledu je pro takovýhle případ nejčitelnější chaining, tzn:

matrix1.multiply(matrix2).translate(vector).scale(0.5)

Ale o Erlangu vim prd, takže nevim, jestli tam je tohle možný...

[JS1]

Rekl bych, ze v tom Elixiru to muze tak napsat taky, akorat misto tecky pises |>.

[pavlix]

Až na to, že ten chaining funguje jen na několik vyjmenovaných operací, které jsou součástí API nějakého objektu.

[kralyk z abclinuxu]

To už záleží na konkrétním jazyce, jinak nechtěl jsem tím říct, že to je ekvivalentní (není)...

[Kaiten]

Haskell -> operátor funkční kompozice, houby objekty

[pavlix]

Context error.

[.]

Mozna to bude znit divne, denne profesionalne programuju v Erlangu i LFE, ale psat cokoliv v Elixiru mi vzdycky z nejakeho duvodu bylo neprijemne. Jako pipe operator je pekny, ale to je asi tak vsechno, co mi na Elixiru prijde zajimave. Mozna to je tim, ze jsem k Erlangu prisel smerem od LISPu a SmallTalku a ne pres Ruby...

Just my $.2

[pavlix]

To je dvacet centů?

[.]

Ano, ale ten zapis s uvedenymi jazyky nijak nesouvisi :)

[hadson]

Ja som na erlang presiel z F# (z krltoreho elixir prebral ten |>) a syntax erlangu mi tiez pride omnoho prehladnejsia. Elixir mi svojou zbytocnou ukecanostou pripomina Basic.