Miért érdemes Ocaml/ReasonML-t használni?
Ebben a kis bejegyzésben arról lesz szó, hogy miért is érdemes megismerkedni az Ocaml programozási nyelvvel. Azért írom ezt a bejegyzést, mivel sajnos Ocaml egyáltalán nem tartozik a jól ismert nyelvek sorában, annak ellenére hogy egy nagyon praktikus es érdekes programozási nyelvről van szó.
Az ilyen multiparadigmális nyelveknél azért észben kell tartani, hogy az adott nyelvnél mi a fő paradigma, amivel érdemes az adott nyelvet használni. Attól még hogy egy kicsit jobban van támogatva egy másik paradigma, az nem azt jelenti, hogy mostantól csak azt használja az ember, hanem azt hogy az ember megtalálja azt az arany utat, ahol a fő paradigmát az esetek nagy részében tudja használja(80%) es a többi kiegészítő paradigmát csak ott, ahol annak van értelme(20%).
Ha az a előbb említett "szabályt" megszeged vagy maga a programozási nyelv nem tartja be az említett szabályt, akkor egy adott nyelven olyan kódbázis es kódolási stílus különbségekhez tudsz jutni, ami már komolyan képes megakadályozni, hogy mások a kód bázisodat könnyen megértse.
Sajnos a világban nagyon kevés programozási nyelv használ Ocaml-hez hasonló paradigma arányokat, ami azért sajnálatos, mivel tényleg úgy érzem, hogy ez a fajta stílus egyfajta aranymetszete a mostanság népszerű paradigmáknak.
Persze nem mindig élhetünk ebben a szép funkcionális világban, mert vannak olyan problémák, amikor imperatív paradigma adja a jobb megoldást. A második ok amiért Ocaml szerethető az a nyelvnek a praktikussága, mivel a nyelv tervezői megadták azt a flexibilitás, hogy képesek vagyunk a nyelvben imperatívan programozni, de közben egyértelművé van téve a felhasználója számára, hogy általánosságban mégis próbálja a problémáit funkcionális programozás keretein belül megoldani.
Ezek a más nyelvi elemek az module, a higher order module és a functor. Ha az olvasó esetleg olvasta a Python írásomat, akkor tudhatja, hogy Python-ban a module egy fájl-lal egyelő és Ocaml esetében is ez a helyzet. A module-ok gyakorlatilag a Singelton tervezési mintának felel meg nagyjából, ami vicces módon az egyik legfontosabb tervezési minta, amit egyik mainstream OOP nyelv sem támogat nyelvi szinten.
A második nyelvi elem a higher order module, ami gyakorlatilag csak azt jelenti, hogy a module-t tudjuk adatként kezelni, ami azért fontos, mert ezáltal tudjuk kiváltani az objektum orientált világból ismert interface-eket könnyedén. Mivel így függvények bemeneténél megadhatjuk, hogy milyen fajta module-t(interface-t) várunk el bemenetként.
Az utolsó nyelvi elem a functor, ami egy olyan függvény aminek a bemenete egy module és a kimenetet is egy module. Vagyis maga a functor module átalakításért/kibővítésért felelős. Functor pedig azért fontos mivel OOP világból ismert implementálást és öröklődést lehet vele kiváltani.
Ezekből remélem az olvasó is látja valamennyire, hogy az objektum orientált paradigma nem feltétlenül egy szükséges paradigma, mivel ki lehet váltani azt más megoldásokkal.
Típus biztonságnak három nagy károkozója van mainstream nyelvekben.
Ocaml úgy kerüli ki a null pointer hibát, hogy a nyelvben nincsen null és helyette az Optional monad van használva, amit már elég sok népszerű nyelv használ. Viszont sajnos ezekben a nyelvekben a null is megtalálható és ezért ezek a nyelvek Optional használata esetén sem lehetnek típus biztosak, mivel null az ami alapvetően lehetetlené teszi egy nyelv típus biztonságát.
A bátor jelenezők előtt két út áll, hogy belépjenek ebbe a mesés világba.
A könyv elolvasása és az alapok elsajátítása után tudom ajánlani az esy nevű eszközt, ami a backend fejlesztést hivatott leegyszerűsíteni. Ezek mellé még tudom ajánlani a vscode-reasonml plugint ha arra adjátok a fejeteket, hogy vscode-ot használjátok fejlesztéshez. Viszont ha esetleg mást használnátok, akkor érdemes merlin oldalán elolvasni a lehetőségeket.
Mielőtt elfelejtem van még egy másik kicsit barátságosabb könyv az Ocaml-hez, ami nem más mint a Cornell egyetem Ocaml kurzusához tartozó kurzus könyv. Mostanság kezdtem elolvasni és nagyon lenyűgözött a könyv.
Azért ajánlom, a frontendeseknek Reason-t, mivel maga a React megalkotója kezdte a nyelvet megalkotni azzal a céllal, hogy Ocaml-nek adjon egy barátságosabb(javascript-esebb) kinézetet és hogy ezzel a nyelvel lehesen használni a React framework-jét. Ezt azért csinálta, mivel a React prototípusát StandardML nyelvben készítette el, ami gyakorlatilag az Ocaml-nek az ükapukájának tekinthető. Ezért érdemes ránézni a React Reason verziójára ami a ReasonReact.
Most pedig egy kis future funk-kal búcsúzom el a bejegyzésem végén.
Multiparadigma veszélyei
Általánosan elmondható, hogy nagyon kevés tisztán egy paradigmát megvalósító programozási nyelv van, mivel általában a praktikusság szempontjából nem biztos, hogy megéri csak egy paradigmát megvalósítani. Gondoljunk csak bele, hogy menyi ma is jól ismert programozási nyelv kezdett el funkcionális paradigmából származó eszközöket magukba pakolni.Az ilyen multiparadigmális nyelveknél azért észben kell tartani, hogy az adott nyelvnél mi a fő paradigma, amivel érdemes az adott nyelvet használni. Attól még hogy egy kicsit jobban van támogatva egy másik paradigma, az nem azt jelenti, hogy mostantól csak azt használja az ember, hanem azt hogy az ember megtalálja azt az arany utat, ahol a fő paradigmát az esetek nagy részében tudja használja(80%) es a többi kiegészítő paradigmát csak ott, ahol annak van értelme(20%).
Ha az a előbb említett "szabályt" megszeged vagy maga a programozási nyelv nem tartja be az említett szabályt, akkor egy adott nyelven olyan kódbázis es kódolási stílus különbségekhez tudsz jutni, ami már komolyan képes megakadályozni, hogy mások a kód bázisodat könnyen megértse.
Ocaml paradigmái
Paradigmák arányai
Az első ok, amiért Ocaml nagyon érdekes és szerethető, hogy tisztán kijelöli, hogy milyen paradigmák építik fel. Az első a funkcionális paradigma, amit az esetek 80%-ba fogsz használni, mivel az esetek többségében minél egyszerűbb/tisztább kódot akarsz gyártani. Ezek után van az imperatív paradigma, amit az esetek 18%-ban használsz, mivel vannak olyan esetek, amikor a legegyszerűbb megoldást ebben a paradigmában lehet elérni. Végül az utolsó 2%-ban pedig objektum orientált paradigmát találhatod meg, mivel az esetek nagyobb százalékában nincs szükség a paradigma képességeire.Sajnos a világban nagyon kevés programozási nyelv használ Ocaml-hez hasonló paradigma arányokat, ami azért sajnálatos, mivel tényleg úgy érzem, hogy ez a fajta stílus egyfajta aranymetszete a mostanság népszerű paradigmáknak.
Paradigmák használata
Számomra az egyik legfontosabb tulajdonsága a nyelvnek, hogy elsődlegesen funkcionális. Ami azért jó, mert így a nyelv már lekorlátoz engem egy olyan paradigmára, ami híres arról, hogy könnyű benne tiszta kódot írni, mivel ösztönözz arra, hogy tiszta(pure) és egyszerű függvényeket használjunk komplex side effect-el teli függvények helyett.Persze nem mindig élhetünk ebben a szép funkcionális világban, mert vannak olyan problémák, amikor imperatív paradigma adja a jobb megoldást. A második ok amiért Ocaml szerethető az a nyelvnek a praktikussága, mivel a nyelv tervezői megadták azt a flexibilitás, hogy képesek vagyunk a nyelvben imperatívan programozni, de közben egyértelművé van téve a felhasználója számára, hogy általánosságban mégis próbálja a problémáit funkcionális programozás keretein belül megoldani.
Miért nem fontos az objektum orientált paradigma?
Az olvasóban felvetődhet a kérdés, hogy az objektum orientált paradigma miért ennyire mellőzőt a nyelvbe. Amire a válasz az, hogy az esetek többségében nincs rá szükség, mivel az Ocaml-ben vannak olyan más nyelvi elemek, amik ezt tökéletesen tudják helyettesíteni.Ezek a más nyelvi elemek az module, a higher order module és a functor. Ha az olvasó esetleg olvasta a Python írásomat, akkor tudhatja, hogy Python-ban a module egy fájl-lal egyelő és Ocaml esetében is ez a helyzet. A module-ok gyakorlatilag a Singelton tervezési mintának felel meg nagyjából, ami vicces módon az egyik legfontosabb tervezési minta, amit egyik mainstream OOP nyelv sem támogat nyelvi szinten.
A második nyelvi elem a higher order module, ami gyakorlatilag csak azt jelenti, hogy a module-t tudjuk adatként kezelni, ami azért fontos, mert ezáltal tudjuk kiváltani az objektum orientált világból ismert interface-eket könnyedén. Mivel így függvények bemeneténél megadhatjuk, hogy milyen fajta module-t(interface-t) várunk el bemenetként.
Az utolsó nyelvi elem a functor, ami egy olyan függvény aminek a bemenete egy module és a kimenetet is egy module. Vagyis maga a functor module átalakításért/kibővítésért felelős. Functor pedig azért fontos mivel OOP világból ismert implementálást és öröklődést lehet vele kiváltani.
Ezekből remélem az olvasó is látja valamennyire, hogy az objektum orientált paradigma nem feltétlenül egy szükséges paradigma, mivel ki lehet váltani azt más megoldásokkal.
Típus biztonság
A harmadik és utolsó fontos ok, amiért érdemes használni Ocaml-t, az a nyelvnek a típus biztonsága, ami azt jelenti, hogy a programozási nyelv gátolja a típus hibák létrejöttét a lefordított programban. Ami azt jelenti gyakorlatban, hogy a programban kevés lesz lehetséges runtime hibák száma és hogyha valami lefordul az le is fog tudni futni általában, habár itt megjegyezném, hogy attól, hogy valami típus biztos nem jelenti azt, hogy mentes a logikai hibáktól.Típus biztonságnak három nagy károkozója van mainstream nyelvekben.
NPE
Az első ilyen hiba az úgy nevezett null pointer hiba, amit okkal neveznek az iparágban az egymilliárd dolláros hibának, mivel rengeteg programozási hibának a fő okozója és mivel ennek is meg van az a rossz szokása, hogy runtime hiba és hogy a compiler nem tudja kiszűrni, ha a nyelv tartalmazza a null nyelvi elemet.Ocaml úgy kerüli ki a null pointer hibát, hogy a nyelvben nincsen null és helyette az Optional monad van használva, amit már elég sok népszerű nyelv használ. Viszont sajnos ezekben a nyelvekben a null is megtalálható és ezért ezek a nyelvek Optional használata esetén sem lehetnek típus biztosak, mivel null az ami alapvetően lehetetlené teszi egy nyelv típus biztonságát.
Típus cast-olás
A második ok amit gátolja egy nyelv típus biztosságát az a típus cast-olás, mivel a használatukkal azt üzenjük a fordítónak, hogy ne aggódjon és bízzon meg bennünk, mint programozókban, mert mi tudjunk az adott objektum típusát. Általánosságba a típus biztonsági hibák ilyenkor következnek be, amikor programozónak okosabbnak kell lennie a fordítóprogramnál.Reflection
Ezt személy szerint én a második egymilliárd dolláros hibának tartom, mivel nagyon elterjedt és minden esetben runtime hibát okoz rossz működés esetben. Nem is beszélve, hogy reflection hibák debuggolása hihetetlenül nehéz, mivel mégis csak olyan kódban kell keresni a hibát ami futásidőben kódot generál. Aki már látott reflection-t használó kódot az valószínűleg soha többet nem akar olya kódot látni egész életében.
Hol érdemes neki kezdeni?
Manapság Ocaml népszerűsége minden nap egy kicsivel nő, mivel az emberek újra felfedezik ezt a nyelvet, mivel az alkalmazásokban egyre fontosabb és kritikusabb követelmény, hogy jól működjenek és ebben nagyon sokat tud nekik segíteni az Ocaml nyelv erős típus biztonsága.A bátor jelenezők előtt két út áll, hogy belépjenek ebbe a mesés világba.
Backend búvárok
Aki ténylegesen a backend-en szeretné a nyelvet használni annak tudom ajánlani a Real World Ocaml könyvet, mivel egy teljes bevezetést jelent az Ocaml nyelvben. A könyv fontos tulajdonsága, hogy friss, mivel a könyv szerző párosa egy évvel ezelőtt elhatározta, hogy a könyvüket frissítik, mivel ez volt a de-facto belépési pont Ocaml fejlesztőknek.A könyv elolvasása és az alapok elsajátítása után tudom ajánlani az esy nevű eszközt, ami a backend fejlesztést hivatott leegyszerűsíteni. Ezek mellé még tudom ajánlani a vscode-reasonml plugint ha arra adjátok a fejeteket, hogy vscode-ot használjátok fejlesztéshez. Viszont ha esetleg mást használnátok, akkor érdemes merlin oldalán elolvasni a lehetőségeket.
Mielőtt elfelejtem van még egy másik kicsit barátságosabb könyv az Ocaml-hez, ami nem más mint a Cornell egyetem Ocaml kurzusához tartozó kurzus könyv. Mostanság kezdtem elolvasni és nagyon lenyűgözött a könyv.
Frontend varázslók
A frontendeseknek is érdemes elolvasni a könyvet, de nekik igazából a ReasonML nyelvnek a honlapját tudom ajánlani. Persze kérdezhetnétek, hogy miért ajánlok egy másik nyelvet egy Ocaml-es bejegyzésnél. Erre azt tudom, mondani, hogy ReasonML gyakorlatilag Ocaml csak más a syntaxis-a. Ez kb olyan mint amikor két különböző márkájú autót is ugyanaz a típusú motor hajtja meg.Azért ajánlom, a frontendeseknek Reason-t, mivel maga a React megalkotója kezdte a nyelvet megalkotni azzal a céllal, hogy Ocaml-nek adjon egy barátságosabb(javascript-esebb) kinézetet és hogy ezzel a nyelvel lehesen használni a React framework-jét. Ezt azért csinálta, mivel a React prototípusát StandardML nyelvben készítette el, ami gyakorlatilag az Ocaml-nek az ükapukájának tekinthető. Ezért érdemes ránézni a React Reason verziójára ami a ReasonReact.
Összegzés
Összességében ebben a bejegyzésben azt szeretem volna átadni, hogy azért érdemes Ocaml-t kipróbálni, mivel egy nagyon kiegyensúlyozott és praktikus programozási nyelv, ami azzal teszi számunkra a legnagyobb szívességet, hogy a típus biztonságágának köszönthetően nem enged meg olyan veszélyes dolgokat, amiket más nyelvek simán megengednek.Most pedig egy kis future funk-kal búcsúzom el a bejegyzésem végén.