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.
Fajny, krótki i treściwi wpis. Chociaż nie zgodzę się z początkiem. Nauka składni to nie będzie kilka minut.
W szkole i na studiach uczyłem się Pascala, C, C++, C# i nawet Javy. Żadnego z tych języków nie znam dobrze, ale przejście z jednego do drugiego to chwila. Zawodowo piszę w Python, który moim zdaniem zaskoczył mi najszybciej.
Elixir wygląda zwięźle, ale dopiero po czasie. Jestem po prawie tygodniowej przeprawie z tym językiem i kilka kwestii na początku strasznie mnie irytowało. Nie pozwalały mi też zrozumieć dlaczego coś jest nie tak. Największym problemem było to, że czasem trzeba dawać przecinki, a czasem nie. Często zapominałem o dwukropku po ‘do’, albo gubiłem ‘end’. Do tego kilka różnych strzałek: ->, =>, <-.
Po czasie stało się to w miarę naturalne, ale przez pierwsze dwa dni dalej nie potrafiłem z głowy powiedzieć co i kiedy użyć. Dlatego, to kilka minut to lekka przesada, ale poza tym podpisuję się pod tym rękoma i nogami, zwłaszcza o podejściu obiektowym ;)
PS. Sam prowadzę bloga o Python i taki Elixir to fajny powiew świeżości :)
Comments are closed.