Mik a Haskell előnyei más nyelvekkel szemben?

Pont, mint minden más nyelvnél vannak előnyei és hátrányai is a többi nyelvvel szemben, de sohasem általános előnyökről beszélünk.

A programozó is a feladathoz választ eszközt. A funkcionális nyelveket a hozzájuk passzoló feladatokhoz válassza.

A Haskell előnye: könnyen tanulható vele a funkcionális paradigma, szemben pl. a smalltalk-kal.

De, nagyon jól leírta #1-es. Gyakorlatban, könnyen tanulható vele a funkcionális paradigma, ezért is oktatják annyi helyen.

Ha azt kérdezed hogy mit lehet megcsinálni benne amit C++-ban nem, akkor azt mondom semmit. De visszakérdezek: mit lehet megcsinálni C++-ban amit Haskell-ben nem lehet? Csak két különböző nyelv, két különböző paradigma. Nem a végeredmény az ami számít, hanem a fejlesztési folyamat.

A funkcionális paradigma előnye az állapotmentesség, jó párhuzamosíthatóság, könnyű unit tesztelés. Nincsenek mellékhatások, csak gyors és stabil alkalmazás.

Napjainkban a scala talán a legnépszerűbb. Használatos:

- Nagy méretű adatfeldolgozásra (big data)

- Gépi tanulás, neurális hálózatok

- Modern web és mobilalkalmazás fejlesztés

- Stress tesztelési frameworkök

- Analízis és szimulációk

- Stb..

* "Ez gyakorlati alkalmazás szempontjából nem sokat jelent."

Pont annyit jelent amennyit kell annak jelentenie. Ugyan nem annak tervezték (és talán sokan megsértődnek ha ezt mondom) de szükség van oktató nyelvekre is. Ez igaz minden paradigmára. Ne próbáljunk már egy Pascal-t összehasonlítani egy JavaEE-vel a versenyszférában, mert nem lehet. Másra használatosak.

* "Ezért kérdeztem úgy, hogy: "C++-ban nem VAGY NEHEZEBB""

És ezért írtam le lentebb hogy főleg mire használják a funkcionális nyelveket, és milyen előnyei vannak. Ezek a területek azok, ahol jobban helytáll egy Haskell vagy bármilyen másik funkcionális nyelv. Próbáltál már C++-ban egy nagy kódbázisal rendelkező, sokszálas alkalmazást menedzselni (ha sebesség is szempont)? Ha igen akkor talán tudod hogy mennyi fejfájással tud járni az és ha sikerül is, egyszerűen nem tudod kihozni tesztekkel a bugokat, hiszen sokszor teljesen véletlenszerű hogy éppen két szál mikor olvassa ugyan azt az erőforrást, (főleg ha sokfelhasználós az alkalmazás), illetve ha lockokat használsz akkor mikor éheztethetik ki egymást a szálak, milyen terhelés mellett omlik össze az alkalmazás, hány szálat tudsz futtatni, van e benne deadlock, és bizonyos váratlan eseményeknek milyen mellékhatásai lehetnek.

De tekintsünk el a multithreadingtől mert ez csak egy példa a sok közül annak, hogy miért jó az állapotmentes alkalmazás. Ezekkel egyáltalán nem kell foglalkozni mert egyszerűen minden működik stabil, és gyors.

* "Nem kötelező osztályokat használni C++-ban sem. De itt szerintem már csak arról szól a dolog, hogy milyen paradigma szerint akarjuk átláthatóbbá tenni a programot."

Ennek semmi köze az osztályokhoz. Osztályok nélkül is vannak állapotok az imperatív nyelvekben, sőt, kb. lehetetlen állapotmentes alkalmazást készíteni, hiszen a stack mérte korlátos.

* "Szerintem az objektumosítással többet nyerünk átláthatóság és biztonság szempontjából, mint amennyi vesztünk az állapotmentességgel és a párhuzamosíthatósággal. Mondjuk az utóbbi szerintem nem szükségszerű, hogy probléma legyen osztályokkal sem."

Mi alapján mondod ezt? Mit nyersz objektumosítással és mitől lenne biztonságosabb egy objektum orientált kód? Pontosan az inkonzisztens állapotok idézik elő a biztonsági hibákat. Egyébként nem lesz sokkal átláthatóbb az objektum orientáltságtól a program. Annyi a különbség hogy OOP-ben az egységeket főnevekkel definiáljuk és osztályoknak nevezzük, funkcionális nyelvekben az egységek igék és függvények.

Ha leesik az alma a fáról akkor az OOP definiál egy almát aminek van egy lesés metódusa, az FP definiál egy leesést ami kaphat almát paraméterként. Ha bővítjük, akkor FP-ben a függvények átadunk egy másik függvényt ami átad egy almát, OOP-ben pedig egy másik osztály mezője, esetleg leszármazottja lesz az alma. Csak nézőpont kérése. Más gondolkodást igényel. Ez lehet előny is amelett hogy pontosan ezért nem lterjedt. Matekos problémákat szerintem könnyebb implementálni funkcionálisan hiszen ott is függvényekről és rekurzióról beszélünk.

* "De lehet jobb ha így kérdezem: Tegyük fel C++-ban programozok. Milyen feladattal kell szembesülnöm ahhoz, hogy azt mondjam "Azt hiszem ezt érdemesebb lenne haskell-ben leprogramoznom ezért meg ezért!"."

Azt hiszem pontosan erre próbáltam választ adni. Egyszerűen a fentebb felsorolt feladatokat egyszerűbb ellátni FP programozással. Meg lehet csinálni máshogy, de az esetek nagy százalékában az olyan is lesz. Nehéz elmondani valakinek aki talán soha nem dolgozott nagyobb FP és OOP projekteken. Még úgy is hogy kellett egy betanulási időszak a csapatomnak, minden gyorsabban és gördülékenyebben ment FP esetén és az eredmény is jobb lett.

Megjegyezném hogy az OOP programozási nyelvek is elmentek FP irányba. Java 8-ban már senki nem használ ciklusokat, ott van a Stream API és a lambda függvények, és ugyan ez igaz C#-ra is, C++11 is nagyot váltott ilyen irányba, Python pedig alapból tartalmaz minden ilyet már a megjelentése óta (lambda, generators, map, reduce, filter, list comprehension, parameter extension, stbstb)