Temat poboczy ale im częściej mówię o Elixir tym częściej to podkreślam. Ma to bardzo ważne dwa aspekty – pozytywny i negatywny. Elixir jako język jest BANALNIE prosty. Jeżeli masz kłopot z opanowaniem C#, nie rozumiesz Java, a JavaScript WAT? Powodują u Ciebie zawroty głowy, to Elixir jest językiem dla Ciebie. Ale to nie oznacza, że będziesz pisał w nim dobre aplikacje. Ten post naświetli problemy jakie każdy programista obiektowy ma wchodząc w elixir.

Jednym z pierwszych problemów jak i największą zaletą Elixir jest sama semantyka języka. Jest ona prosta, banalna, ograniczona do kilku makr. Opanowanie językowej składni to maks kilka minut nauki. Opanowanie możliwości czytania kodu ze zrozumieniem – około dwóch tygodni maks. Język nie wygląda jak język funkcyjny. Wręcz przeciwnie, wygląda jak język obiektowy. O czym ostatnio pisałem.

Plus prostego języka jest to, że łatwo się go nauczyć. Minus? Za łatwo się go nauczyć. A to niesie za sobą oczywiście niebezpieczeństwo wejścia w język osób które ledwo co programować potrafią. Doprowadzając do kolejnego problemu.

Drugim największym problemem jest to, że język umożliwia programowanie prawie jak w języku obiektowym. Dokładnie mówiąc pewne aspekty rozwiązania możemy prawie identycznie zamodelować w Elixir jak w C#. Przez co z miejsca adepci projektowania obiektowego będą wdrażać swoje przyzwyczajenia do języka, który jest językiem funkcyjnym. I prędzej czy później stworzą oni rozwiązanie które nie ma prawa działać wydajnie. Jednym z podstawowych błędów jakie my wykonujemy to jest myślenie strukturami danych. Jeżeli mamy jakąś daną to ona musi zawierać jakiś schemat i ten schemat powinniśmy móc re-wykorzystywać. Nic bardziej mylnego – w przypadku elixir nic jest to aż tak istotne.

Trzecim problemem na jaki ludzie natrafiają a który jest rozwiązaniem dwóch poprzednich, to jest to, że elixir wymaga zmiany sposobu myślenia. Zarówno przy projektowaniu systemu, przy komunikacji, przy przechowywaniu danych przy wszystkim. Wymaga on sposobu myślenia osób programujących w językach funkcyjnych. A to znaczy, myślenia o funkcjach a nie o danych, myśleniu o robieniu a nie o reprezentowaniu.

Jeżeli popełniamy jakikolwiek z wyżej wymienionych problemów to nasze rozwiązanie będzie koślawe. Jedynym sposobem na jego naprawienie jest zarówno zmiana sposobu myślenia jak i patrzenie na język nie jako język obiektowy – niezależnie jak bardzo on go przypomniana. A to oznacza jedynie, że dopiero trzecie rozwiązanie takiego problemu będzie zawierało architekturę zbliżoną do tej którą byśmy chcieli mieć. A to też oznacza, żę jako programiści Elixir powinniśmy przygotować się na masę ALE TO MASĘ refaktoryzacji kodu. I dobrze.