Ugrás a fő tartalomra

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ó.

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.

Megjegyzések

Népszerű bejegyzések ezen a blogon

Python kezdőknek

Itt a nyár és mivel lehetne ezt a legjobban megünnepelni, mint egy kígyóról elnevezett programozási nyelv bemutatásával. Következőkben tehát a Python programozási nyelvről lesz szó és annak lehetséges alkalmazásairól.

Miért tartsunk otthon Python-t? Python pályafutása 1991-ben kezdődött el egy Guido van Rossum nevű fejlesztőnek hála, aki egy olyan általános programozási nyelvet akart készíteni, amit nagyon könnyen el lehet sajátítani és használni. Az elmúlt év tizedek alatt a Python nyelv az egyik legjobb és legnépszerűbb általános programozási nyelvé nőtte ki magát, amit bizonyít, hogy számos operációs rendszeren(linux, mac os) alapból megtalálható a nyelv. De nézzük meg, hogy mitől ilyen népszerű: Egyszerűség: A nyelvnek az egyik legnagyobb előnye, hogy nagyon egyszerű és ezért például nagyon sok egyetemen a kezdő programozó legényeket Python segítségével vezetik be a programozás világába.Dinamikus: Mint minden dinamikus nyelvnek úgy Python-nak is van egy beépített REPL-je, ami nagyo…

Amikor érdemes játékmotort késziteni

A mondás
A játékkészítő közösségben van egy mondás, hogy "Készíts játékot, ne játékmotort".
Szerintem ez a mondás nagyon is igaz abból a szempontból, hogy ha tényleg játékot akarsz készíteni, akkor válasz egy jól ismert játékmotort és kezd el a fejlesztést, mivel ezek az eszközök azért vannak, hogy megkönnyítésék a játékkészítést  és ugyebár mi értelme van feltalálni a kereket ismét?
Viszont itt is lehet találni kivételeket, amikor igenis el kell gondolkozni egy saját játékmotor fejlesztésén.

Mikor érdemes tehát belefogni?
 Most csak az én esetemet tudom felhozni, ami nem más mint a saját 2D HTML5 játékmotorom, amit DartRocket- nek hívok. Az én esetemben az ok egyszerű volt. Dart nyelven nem volt egy igazi játékmotor sem és én Dart-ban akartam játékokat készíteni.
Itt találtam is egy kiskaput mivel ha nincs játékmotor, akkor csinálni kell egyet. :D


Hogyan kezdődőt el?
Ha időrendben akarok menni, akkor azt kell mondanom, hogy négy időszak volt, ami meghatározó volt.

Phaser: Ebb…

Javascript kezdő lépések

Ma kis bejegyzésem arról fog szólni ,hogy mit érdemes kezdő lépésenként megtanulni ,illetve ,hogyan érdemes haladni Javascripttel és néhány érdekesség is lesz node.js-sel kapcsolatban.

Tanulás
   Szerencsére olyan világba élünk már ,ahol a web és webes technológiák nagyon gyorsan fejlődnek és ezért ezeknek a tanulása is egy fajta fejlődésen ment keresztül. Már nem könyvből kell tanulni ,hanem vannak olyan oldalak ahol interaktív módon lehet egy nyelvet megtanulni ,ami tökéletes a tanulás szempontjából. Előző cikkemben raktam be anyagokat ahhoz ,hogy mit érdemes elolvasni ,ha a tanuló inkább olvasós fajta és volt bent 2 interaktív.  Én például codecademy segítségével tanultam meg Jquery-t használni. Javascripthez Eloquent és codeacademy-t használtam.

   Mivel a Javascript elég megengedő ezért nagyon sok fajta stílusban kódolnak hozzá és ezek a stílusok  néha teljesen eltérőék. Szóval aki tanult már Java ,c vagy c++-t annak is lehet újdonság ,mivel ezeknél a nyelveknél nagyon szépen megv…