[solved] Elsore melyik funkcionalis nyelvet miert?

Egyéb: Assembly, Ada...

Sziasztok,

Ha most kezdenetek el megtanulni az elso funkcionalis nyelvet, akkor melyik lenne az, es miert? Pl: x mert konnyu elso funcionalis nyelvnek, y mert elterjedt, z mert hasznos/piackepes etc...

Update:

Latom, vagy rosszul fogalmaztam, vagy a szovegertes nem megy:
Tisztan funkcionalis vagy hibrid nyelvekre lennek kivancsi, pl: Scala, Haskell, Erlang, etc.

( BlinTux v | 2015. 01. 05., h – 23:43 )

PHP: könnyű, elterjedt, piacképes!

Mondjuk az egy dolog, hogy meg mindig fingod nincs, hogy mibe szolsz bele, azert egy-ket dolgot eloszlatnek:

- " sokkal gyorsabban fejlődtem vele.": ugy erted fassagok halmozasaban.
- "fordítgatni": cserebe nem is jon ki egy-ket syntax error, mig le nem futtatod es kulon buli, mikor verziorol verziora valtoznak a dolgok.
- "típusokkal foglalkozni": Mar hogy ne kellene. Cserebe pluszba szopat, hogy csak sejtesed lehet, hogy mi micsoda, rakas plusz ellenorzest kell berakni a kodba es sok esetben 0 IDE tamogatas van hozza. Plusz refactoring kuka, normalis code complete kuka, stb.
- "jó tutoriálok voltak hozzá": jo tutorialok voltak ahhoz, hogy hogyan csinalj szart.
- "weboldalt hamar használhata mindenki": hja, csak ezercsillio dolog van ahhoz, hogy valamit jol is csinalj.
- "csak egy böngésző kellett hozzá.": miazistennek? Fut az CLI-bol is. Mellesleg nem art hozza egy webszerver is, bar most mar van beepitett is.

Bonuszkerdes: "Nekem is a PHP jött be leginkább" Egyaltalan melyik az a programnyelv, amit ismersz is? (Nem a PHP-t nem ismered, ezt mar bebizonyitottad).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Most ezt olvasd el úgy, mintha magadról írtad volna. Még elgondolkoztató lehet.
Egy dolgot fogadok el tőled, hogy te igen problémásnak találod a PHP nyelv használatát. Azonban nem mindenkinek van ilyen nagy problémái. Más munkáját ócsárolni a legkönnyebb, legyen az programozási nyelv vagy azzal készített alkalmazás.

"te igen problémásnak találod a PHP nyelv használatát."

Persze, mert párszázezer sornyi PHP és párszázezer sorniy C# kód, illetve még random kisebb-nagyobb mennyiségű kód különféle programnyelveken után talán van annyi összehasonlítási alapom, hogy megállapítsam, hogy egy hányás.

Bónusz: a PHP egy procedurális nyelv, nem funkcionális. Ha már nagyon erőltetni akarjuk a webet, akkor funkcionális nyelv pl. az SQL. (És mondjuk igazából az is inkább deklaratív mintsem funkcionális, mint ahogy emlékeztettek rá.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Altalaban nem ertek saxus-sal egyet, de a PHP kapcsan kivetelesen egyezik a velemenyunk.

A PHP-nek alapvetoen negy problemaja van:

- A nyelv nincs rendesen megtervezve, orditanak az ad-hoc tervezes hibai, meg az alapveto C-s szintaktikat se sikerult teljes mertekben implementalni, pedig az egy nyelvnek eleg esszencialis lenne
- A hozza kapcsolodo runtime semmilyen tervezesi patternt nem tud felmutatni. Ahogy a kapcsolodo C-s libekbol kijon az adat, gyakorlatilag egy az egyben azt kapod meg PHP-ban, attol fuggetlenul, hogy ennek mennyi haszna van. Igazabol tisztan szintaktikai szempontbol nincs ertelme egy adott kodot PHP-ban megirni, felesleges boilerplate.
- A verziovaltasok menedzselese katasztrofalis. Nincs rendes valtozas kezeles, bizonyos szintaktikai/runtime dolgok ugy tunnek el alverziok kozott, hogy hirtelen valaki kozli, hogy na akkor ez most innentol kasza. Van ugyan deprecated fuggveny kezeles a rendszerben, de nem szeretik hasznalni.
- OOP nyelv letere hihetetlenul gyengen tipusos. Nincsenek eles hatarok a numerikus, a szoveges es az igaz/hamis ertekek kozott, minden primitiv tipus gyakorlatilag egymasba mosodik. Ha valahol latsz egy 1-est, nem tudhatod, hogy az most szam, boolean, vagy szoveg, analizalni kell a kontextust, hogy rajojj.

--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Én azt nem szeretem, mikor C-ből ész nélkül vesznek át dolgokat. Pl. 


if (a) 
{ 
  ... 
}

vagy éppen: 


if (a = 3) 
{ 
  ... 
}

Ez C-ben rendben van, de ez sajnos megmaradt pl. JavaScriptben (horribile dictu: TypeScriptben) is.
És kezdődhet a patkolás: 


if (3 == a)
{
   ...
}

... ami ugye baromság, mert engem nem az érdekel, hogy a 3 értéke ugyana-e, mint 'a'-é.

Fuszenecker Róbert

Látom nem értetted meg a lényeget, a következő formáknak *semmi* keresnivalója nem lenne a PHP-ben (de igazából egy nyelvben sem):

if (a) ...
if (a = 3) ...

Nem véletlen, hogy ezek pl. fordítási hibát adnak C#-ban, Javaban és minden értelmes nyelven.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ez más tészta. A belső értékadás tényleg nem predikátum, de nem is az az if feltétele, hanem az ==. Az "if is scope boundary" más kérdés, mint hogy a nyelv gyengén típusos-e. A példád egyébként java-ban is működik, attól eltekintve, hogy a deklarációt kívülre kell rakni: 


int ch;
while ((ch = reader.read()) != -1) {
}

Az if itt egyebkent kicsit santa pelda sajnos, mert csak egyszer hajtodik vegre. Ugyanakkor peldaul egy while ciklus - ami szintaktikailag pont ugyanezt a felepitest alkalmazza, valoszinuleg a compilerekben ugyanaz a kod ertelmezi szintaktikailag, mint az ifet - eseteben az ertekadas periodikusan ujra es ujra vegrehajtodik, es ennek kimenete lesz a feltetel parametere. Ha nincs ez a lehetoseg, akkor a while eseteben egy valahonnet vett default ertekre is ellenorizni kellene, hiszen a ciklus elso lefutasa elott a ciklusvaltozo nem tudna erteket kapni sehonnet.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Tegyük fel, hogy azt akarod írni (mondjuk C-ben), hogy
if (a == 3) { ... }
Ilyenkor nagyon könnyű elkövetni azt a gépelési hibát, hogy if (a = 3) -t írsz, és ezt a hibát a fordító nem fogja meg, simán lefordul a program, csak szarul működik. Ennek elkerülésére alakult ki az a konvenció, hogy inkább if (3 == a) -t írunk, mert ekkor ha kihagyunk egy = -t, akkor a 3 = a kifejezés már nem fog fordulni. Ezt értette hg8lhs kolléga patkolás alatt.

Ez egy tök szép példa, de nekem még a büdös életben nem sikerült ilyen elgépelést csinálnom, és más kódjában sem jött még szembe.
(Ugyanakkor több alkalommal raktam pontosvesszőt az if után, és debuggoltam órákat... :) )

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Nincs ezzel semmi baj, csak _szerintem_ egy nem létező problémát oldanak meg ezzel, ennélfogva _szerintem_ a feature megléte nem teszi jobbá a nyelvet. Szerintem.

(Ugyanakkor zavarja a szemem a 3 == b megoldás.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Szerintem meg egy nagyon is létező problémát oldottak meg. Ugyan nagy ritkán, de néha-néha mégis kapok egy-egy fordítási hibát ilyenből, hogy véletlen elgépelem. Ez C# esetén nem gond, mert ott visít a fordító. Ott a gond, ahol nem visít érte.

Másrészt meg, ha most feltételt vizsgálunk, ne értéket adjunk már...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az, hogy nem láttad gépelni, nem jelenti azt, hogy nem is tud :)
Erről egy vicc jutott az eszembe, ha valaki ismeri, az ne olvassa!

A történész, a fizikus és a matematikus vonatoznak Skóciában.
Meglátnak egy fekete tehenet.
Azt mondja a történész: - Ezek szerint Skóciában feketék a tehenek.
Mire a fizikus: - Ezt nem mondhatjuk, csak annyit, hogy Skóciában legalább egy tehén fekete.
Mire a matematikus: - Még csak ezt sem állíthatjuk, csak annyit, hogy Skóciában legalább egy tehén egyik oldala fekete.

A macskak viszont tudnak gepelni. Ezt szerintem eleg sok forumtars megerositheti.
Sast is lehet, hogy csak azert nem lattal meg gepelni, mert viszonylag kevesen tartanak lakasban haziallatkent.

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

Kockas zarojel nyit, code, kockas zarojel zar, enter, kod,enter kockas zarojel nyit, /code, kockas zarojel zar. 


if(true == this.isCCode()) {
   return false;
}

--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Jó, nekem is volt olyan kódom, amiben ez lett a végeredmény, mert pl. a true ág hosszabb volt eredetileg aztán gyalulva lett.

Csak az ilyeneknek mindig az a vége, hogy realizáltam, hogy ennyi maradt, lecseréltem szimplán egy return true;-ra.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( stoned | 2015. 01. 06., k – 06:47 )

Sok évnyi OO programozás után Haskellbe elég nehezen tudtam beleásni magam, a Scala mégsem okozott problémát, talán azért mert nagyobb volt a motiváció, talán mert mindig át lehet váltani imperatív stílusba. Ennek ellenére én Haskell-el kezdenék. Letisztultabb nyelv, mint a Scala, mind szintakszis, mind koncepciók terén. Megvan minden, ami a többi mainstream nyelvnél: build rendszer, package management, viszonlyag tűrhető mennyiségű library, kód dokumentáció, unit testing, stb. IDE támogatottságról csak annyit tudok, hogy Eclipse-ben és IntelliJ-ben van Haskell plugin, de nem tudom mennyire használható. Ami biztos, hogy Emacs-ban elsőosztályú a támogatottsága mind a Scala-nak, mind Haskellnek.
A Haskellben tanultak később Scala-ban felhasználhatók. Ha egy Scala pozícióra jelentkezve azzal nyitsz, hogy középszintű Haskell ismeretek, az már elég lehet, főleg ha van mellé Java háttér is.
Praktikus szempontok alapján a Scala sokkal jobb, főleg elhelyezkedés szempontjából, de mint írtam, a Haskell tudás sokat ér ha Scala-zni kell. A Java interop. is nagyon hasznos, minden elérhető, ami adott a JVM platformon. Haskellből érkezve jobban látszik, egyes dolgoknál mi a mögöttes koncepció, és mi az, amit a platform sajátosságai kényszerítenek ki.

http://learnyouahaskell.com/
http://book.realworldhaskell.org/

Erlangról csak ködös emlékeim vannak. Itt egy összehasonlítás Haskellel: http://jlouisramblings.blogspot.hu/2010/04/haskell-vs-erlang-for-bittor…

A a .Net világról keveset tudok, F# a legelterjedtebb arrafelé.

Én is Haskell tanulásba kezdtem, bár nem hiszem, hogy business fejlesztésre alkalmas lenne. Cserébe, eléggé elterjed, jól dokumentált, tisztán funcionális, így kivállóan alkalmas a szemlélet elsajátítására. Valószínű Scalára fogok váltani, pontosan azért mert lehet benne keverni a szemléleteket, így valós fejlesztésre alkalmasabbnak tartom, de pont emiatt nem érzem úgy, hogy első funcionális nyelvnek jó lenne. Eric Meiernek van jó videósorozata Haskellről, illetve sokat elmélkedik az egész funcionális programozásról. Kedvenc funcionális hippim az arc, keress rá yutubén.

-
Változékony Grails alkalmazás konfiguráció facepalm

+1 a haskellnek és a http://learnyouahaskell.com/ -nak.
A linken található könyv olvasható ingyen, online, és nagyon jól, szájbarágósan bemutatja a haskell nyelvet.

Szerk.: A real world haskell(2. link) is nagyon jó könyv, de én mindenképp az elsővel kezdeném, mert szerintem az jobban elmagyarázza az alapokat, és ha valaki végig olvassa az első könyvet, és megcsinálja a példa programokat is, akkor érthetőbb lesz a 2. könyv.

A "Real World Haskell" valóban nem rossz, viszont arra érdemes figyelni, hogy egy kicsit már régi (2008). A Haskell — mivel a GHC a de facto szabványa — nagyon gyorsan fejlődik (ami jó és rossz is egyben). Ehhez elég talán annyit írnom, hogy az RWH GHC 6.10-et ajánl, miközben már a 7.10 kerül lassan kiadásra =) És a két verzió között van egy-két apróbb eltérés.

Egyébként, ha például érdekel valakit a konkurens/párhuzamos (és GPU) programozás Haskellben, akkor esetleg még érdemes elolvasni az egyik GHC-fejlesztő, Simon Marlow, tavaly megjelent könyvét a témában, "Parallel and Concurrent Programming in Haskell" a címe, online is olvasható. Továbbá a tisztán funkcionális gondolkodás megértését esetleg még segítheti Chris Okasaki klasszikusa, a "Purely Functional Data Structures", online ez is fellelhető.

A többit leginkább cikkekből lehet összebogarászni, illetve az FP Complete oldalán is lehet egyetemi tananyagokra, blogokra lelni a témában.

Jogos, én csak hobbiból haskellezek néha, ezért erre nem is gondoltam a könyv olvasásakor.
Mindenesetre az alapok megértésére jó könyv mind a kettő szerintem, az elején úgyis az fog gondot okozni a kérdezőnek, hogy átállítsa az agyát imperatív programozásról funkcionális programozásra, de tény, hogy érdemes lehet megnézni mi változott azóta :)

Egyébként még annyit, hogy a Real World Haskellben emlékeim szerint elég sok a hiba, pl. a példakódokban, nem kell meglepődni ha valami nem működik elsőre. Az online verzióban ezek lehet, hogy javítva lettek.

Persze, indulásnak ezek remekül megfelelnek. Csupán azért gondoltam, hogy ezt még azért hozzáteszem, mert könnyen frusztrációvá is fajulhat az ismerkedés — például, ahogy te is írtad, a könyvben levő kódok már nem is teljesen fordulnak. De azóta tényleg változott elég sokat a Haskell-világ: bejöttek a GADT-k, type family-k, megjelentek az iteratee-k, a lensek és mindenféle kategóriaelméleti fogalmak (a monádon túl), és onnantól már szinte egy másik nyelvet kapunk... =) De ez talán érthető is, mivel a Haskellt (és az FP-t) még mindig aktívan kutatják.

Erről jut eszembe, hogy nemrég olvastam egy nagyon jó összefoglalót, ami kifejezetten a nyelvben való elmélyedést segítheti: "What I Wish I Knew When Learning Haskell".

Ha esetleg egy kicsit nyugisabb nyelvre vágyik valaki, akkor talán az OCaml lehet a válasz. Sokban hasonlít a Haskellhez, és ahhoz jelent meg "Real World" könyv nemrég. Ugyan nem tisztán funkcionális, de kezdésnek esetleg jó lehet.

( wachag | 2015. 01. 06., k – 06:50 )

Várd meg az fp101x tanfolyamot az edx-en. Erik Meijer tartja, elég jó.

Erlang könnyebb, Haskell menőbb.

Erlanggal nagyon rég foglalkoztam, akkor is csak a móka kedvéért, annyira emlékszem, hogy elég gyorsan el tudtam kezdeni.

Mostanában haskelleztem, pár észrevétel:

A Haskell egyik legerősebb oldala a kőkemény típusosság. Az elgépelések miatti fordítási hibák mellett csak típusegyezési hibákat láttam eddig(igaz, csak hobbiból haskellezek).
Ez nehéz, amíg meg nem szokod, utána viszont a típusok vezetnek.

Ha Haskell: kezdetben csak egyszerű programokat (qsort, prímkeresés, személyi szám validálás) írj. Amíg ezt meg nem szokod, kerüld a do notationt és az IO-t. Minden kifejezésnek nézd a típusát. Segít.
Aztán ne ijedj meg a monadoktól :-).

A Haskell az FP Java-ja: kb. minden meg van hozzá írva.

Haskellhez nem árt némi affinitás a matematikához.

( uid_194 | 2015. 01. 06., k – 08:54 )

Clojure vagy Haskell, szerintem.

Scala hibrid, es tul nagy a kisertes, hogy az ember ne funkcionalisan programozzon benne, ami tapasztalatom szerint rettento nagy gat. A Scalanal kemenyebb vonalas nyelvek sokkal alkalmasabbak tanulasra. (Raadasul a Scala szintaxisa nem epp a legegyszerubb...)

Erlangot sem javasolnam elso nyelvnek, mert bar sok elonye van, nagyon erzodik, hogy telekom iranybol szuletett. Kesobb erdemes vetni ra egy pillantast, de kezdesnek nem ezt javasolnam.

Haskellnek az egyik nagy elonye, hogy kimeletlenul funkcionalis, es ezzel rakenyszeriti az embert a tanulasra. Ez igencsak hasznos. Raadasul a Learn You a Haskell For Great Good cimu konyv zsenialis. A nyelvhez van kismillio library, egesz jo kozosseg, es hasznos tutorialok. Viszont az erosen tipusossaga, es a pure functional volta ugyanugy lehet hatrany is, mint ahogy elony. (En Haskellel kezdtem a funkcionalis programozast, bejott, de az eros tipusossagot sokszor ereztem gatnak. Hasznosnak hasznos, de ahhoz, hogy az ember ne erezze akadalynak, mar rutinbol kell tolni a nyelvet, az pedig sok ido.)

A Clojuret en azert javasolnam, mert egyreszt praktikus (tok jo Java interop), masreszt funkcionalis, de nem annyira erosen, mint a Haskell (pont Java interop miatt). A teljes java okoszisztemat lehet hasznalni, zsenialis libek vannak hozza (core.async, core.logic, ring, stb), jo dokumentacio, csomo howto, es rem egyszeruen megtanulhato, ha az ember nem fel a LISP nyelvektol. A #clojure IRC csatorna, a levelezolista, es a kozosseg ugy altalaban segitokesz nagyon. Tanulasnal ez szerintem szinten fontos szempont.

Mind Haskell, mind Clojure piackepes. Haskell talan elterjedtebb (leven oregebb nyelv is), viszont Clojure talan konnyebben tanulhato, de ez beallitottsag kerdese (en pl mar Clojure elott kedveltem a LISP nyelveket, igy nem teljesen nullarol kezdtem). Clojure mellett szol meg az is, hogy kulonosebb erolkodes nelkul lehet olyan Clojure libet/alkalmazast irni, ami Javabol is kivaloan hasznalhato, ez pedig nagyot dob a hasznossagon es piackepessegen.

--
|8]

A Citibe (Canary Wharf, London) kerestek Clojure fejlesztot par honapja, 40-80k-s fizetesi savval. Azert 80k mar rendes penz Londonban is. Gyanitom viszont, hogy nem nagyon talaltak senkit, mert kicsit kesobb mar contractori pozikent volt meghirdetve :)

A masik erdekesseg: Functional Works, szoval mar van specializalt fejvadasz is, es ugy tunik, meg is tud belole elni.

Szoval erdemes funkcionalis programozast tanulni, nem csak hobbinak lehet jo :)

Megélhetésre gondolok: ház bérleti díj, rezsi, telefonok (4 db), kaja, adó, autó (akár 2 vagy több) fenntartása, gyerekeknek iskola, egyéb, utazás, mozi, étterem, stb - normál (közép) réteg életvitele - gyereknek szórakozás (ha csajozik, bulizik és ő is költ) stb. Tehát nem luxus, de nem is szűkölködő családi életre gondolok.

Szerintem erre kevés lenne Londonban ez a fizetés.

Szerintem egy normal, nem luxusigenyu csaladnal nem kovetelmeny a 2 vagy tobb auto, illetve a 4 darab telefon, sem itt, sem kint. Az elet nagyon jol mukodik 1 db autoval is, illetve 2 felnott + 1 gyerek eseten 2 telefon elofizetes, a gyereknek pedig pre-paid kartya bosegesen eleg lehet, ez rahagyassal szamolva is max 3 telefon fenntartasa. A vezetekes - foleg, ha mindenkinek van mobilja - nem kotelezo, esetleg keszenletkent valami minimalis csomaggal befizetve, raadasul az a legkissebb koltsegtenyezo.

Ertekrendileg ugyanis nem allnak annyira tavol tolunk, a ketto vagy tobb auto kinn is mar egy magasabb eletszinvonalat kepvisel, azok, akik Londonban laknak, leginkabb tomegkozlekednek, mert sokkal megerosebb a fold alatt kozlekedni, mint a dugoban ulni, fuggetlenul attol, hogy mennyibe faj az Oyster card.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nem contractori, hanem permanent fizetesnek 80k eleg korrekt (nem tudom, hany forint, miert erdekes ez?). Ez havi kb. 4500 netto, 1500-ert mar kapsz normalis lakast elfogadhato helyen (de mondjuk legyen 2000 rezsivel egyutt - csak egy pelda, mi ferhet ebbe bele: 2 bedroomos Temze-parti teraszos lakas Canary Wharf mellett az Isle of Dogs-on), akinek a maradek 2500 nem eleg egy honapra ugy, hogy legalabb 1000 fontot felretesz, az szerintem ne probalja meg az orosz milliardosok eletet elni orosz milliardos apuka nelkul :)

Tegyuk hozza, hogy itt "alap" fejlesztorol beszelunk, mindenfele titulus nelkul, atlag evi 10% bonusszal. Nyilvan VP-tol felfele mas nagysagrend a fizetes, bonusz, egyeb juttatasok, ha valaki ilyen helyzetben van, meseljen.

( uid_720 | 2015. 01. 06., k – 09:53 )

F#-pal használhatod a .NET keretrendszert, az F# egy elég jól kitalált, modern nyelv.
A JavaScriptben is vannak funkcionális megoldások, de 1000 éves örökségek/ökörségek is.

Fuszenecker Róbert

( haspokember | 2015. 01. 06., k – 10:39 )

Tovabbra is a courseras Functional Programming in Scala az etalon, ha az alapoktol kezdve szeretnel funkcionalisan gondolkozni. Mellesleg Scalat tanit, de ez nem igazan szamit, a megtanultak gyakorlatilag egy-az-egyben alkalmazhatok barmilyen mas nyelven (peldaul ezutan sokkal erthetobb lesz a Haskell is, en mindig csodalkozom es mely ahitattal hodolok azoknak, akik rogton melyvizbe ugranak fejest). A Scala ajanlhato meg abban az esetben, ha a JVM-en amugy mar otthonosan mozogsz, sok minden ugyanaz (pl. IDE-k) vagy a meglevokre epit (Maven -> SBT).

A masik jo tanfolyam a Programming Languages, nem annyira profi, atgondolt es strukturalt, mint a scalas, de nagyon hasznos plusz dolgokat lehet megtanulni, tobbek kozott ML-t es egy LISP-varianst.

Alapvetoen ket lenyegesen eltero nyelvtipus van: a statikus es a dinamikus tipusos nyelvek.

Elobbibol elsosorban az F# ajanlhato, mint egy mai modern ML-varians (van hozza nagyon jo konyv is: Real World Functional Programming, ez onmagaban majdnem olyan jo, mint a courseras tanfolyamok).

Az utobbi pedig mara egyertelmuen Clojure, elsore kicsit ut, de a fenti tanfolyamok utan szo szerint kapkodni fogod a fejed, hogy az alapok mellett mennyi okossagot sikerult belevarazsolni a nyelvbe - en legalabbis a mai napig racsodalkozom dolgokra, hogy je, igy is lehet...

Vegul pedig azt a nyelvet tanuld meg, amiben az ismeroseid tudnak neked segiteni, az eleg fontos, foleg az elejen :))

Haskell-t, Erlangot akkor javaslok, ha mar el tudod donteni, miert ezeket valasztanad. Kezdo nyelvnek nem ajanlanam oket.

( BaT | 2015. 01. 06., k – 17:47 )

Én három funkcionális nyelvet ismerek, ezek a scala, erlang, f#. Erlanggal kezdtem még egyetemen, aztán jött a scala, majd belekóstoltam az f#-ba is. Ez a sorrend nekem eléggé bejött, az erlang tisztán funkcionális, szintaxisa nem túl bonyolult és a funkcionális eszközkészlet szinte minden elemét támogatja (currying nincs). Ezután scalat már könnyű volt megtanulni, csak át kellett ültetni az erlangból már ismert eszközöket a scala szintaktikájára. Viszont épp ezért szerintem a scala nem jó választás első funkcionális nyelvnek. F# érdekes nyelv, talán az alkalmasabb első funkcionális nyelvnek, de én mégis azt mondom hogy ezekből egyértelműen az erlang a nyerő.

( pgee | 2015. 01. 06., k – 21:23 )

Koszonet minden ertelmes hozzaszolonak!

A topic nyitas elott nagyjabol 2 nyelvre sikerult leredukalnom a problemat, igy a Scala es a Haskell kozott kellett volna valasztanom, de nyitott voltam az erveitektol fuggoen.

Elolvasva a valaszokat a Scala volt szimpatikusabb, viszont mivel nem tisztan funkcionalis, es nem rendelkezem JAVA-s hatterrel sem, raadasul a linkelt Haskell konyv is igen igeretesnek tunik, igy a Haskell mellett teszem le a voksom. Az F# a dotnet miatt esett ki alapbol, az Erlang-ot pedig nem ajanlottatok annyian. A PHP-s viccrol pedig ne is beszeljunk.

( tovis v | 2015. 01. 07., sze – 13:34 )

A rövid válasz szerintem a C, a "plain" C mindenféle objektumok és azok evolúciója nélkül.
A hosszú válasz sokkal zűrösebb, benne van hit és tapasztalat. Az assembly sajnos "röghöz" köt - azaz egy bizonyos processzor architektúrát és annak mnemonicját fogod megtanulni, nem a program nyelvet. Ettől fogva mindent PIC-el vagy ATMEL -el vagy ARM -al karsz majd megoldani, és nem azzal ami az adott feladathoz tartozik.
A C azért jobb megoldás, mert úgy is felfoghatod int egy szimbolikus, univerzális assemblert nagyon kiterjesztett makró lehetőségekkel.
A C segítségével bármilyen vasat az uralmad alá hajthatsz.
Tény hogy ez már a múlt olyan távoli homályába nyúlik amivel manapság nem biztos, hogy "nagyot lehet kaszálni". A mostanában megjelenő új nyelvek is valójában a C köpenyéből jöttek elő, abban az értelemben hogy akár a szintaktikáját is átveszik.
Tény, hogy mondjuk GUI -t programozni C -ből sziszifuszi meló.
Az én konklúzióm, hogy a C a legjobb funkcionális nyelv, de önmagában már semmiképpen nem áll meg. Azaz ahogy régen én C -ben írtam az alsórendű funkciókat (pl. az WIN32 API -ra épülő socket kezelés) és itt-ott assemblyben az interrupt (vagy más idő korlátos) rutinokat a GUI -t vagy a magas szintű adatbázis kezelést teljesen más eszközökkel készítem és ebbe illesztem a C -t vagy épp az assemblert.
Mottó:
Nincs olyan amit nem lehet C -ben megírni, de sok olyan van amit nem érdemes!

* Én egy indián vagyok. Minden indián hazudik.

( zoner | 2015. 01. 08., cs – 14:17 )

Lua -t senki nem emlitette, pedig itt a helye szerintem. Foleg, ha beagyazott rendszerekkel szeretne valaki foglalkozni.

tudtam, hogy valaki meg fogja kérdezni :)
Nézd, 3+ éve foglalkoztam vele, a következőkre emlékszem, hogy nagyon zavart:
- rettentően inkonzisztensnek éreztem, hogy metódusokat nem lehet értékként használni, miközben a függvényeket lehet, és parciális applikáció is van (-> szerintem a példány-szintű metódusra való hivatkozásnak egy parciálisan applikált függvényre való hivatkozásnak kellene lennie, amiben már kötött paraméter a this)
- nagyon lassú volt az IDE

Ezen kívül biztos volt még pár dolog, mindenesetre nekem ez akkor elég volt ahhoz, hogy elmenjen a kedvem a scala-tól (főleg, hogy akkoriban nem kellett munkahelyemen scala-zni, sőt még java-zni sem, szóval nem volt sürgősen szükségem a nyelv mélyebb megismerésére).

Kezdőnek egyébként azért nem ajánlom, mert multiparadigmás -> könnyű az imperatív megközelítést alkalmazni, ami persze működik, csak attól még nem tanulja meg az illető a funkc. programozást.

Lehet, hogy felreertek valamit, de (2.11.4): 


scala> class A(val a: Int) {
     | def getA() = this.a
     | }
defined class A

scala> val f = new A(5).getA _
f: () => Int = <function0>

scala> f()
res0: Int = 5

Vagy mast ertesz ertek alatt?

Az IDE-k 3+ ev alatt oriasit fejlodtek, ahogy a compiler is, 2.10-tol vannak makrok, stb. Szoval nagyon sokat valtozott a Scala ennyi ido alatt...

Mint említettem, 3+ éve foglalkoztam a scala-val, ha jól emlékszem, akkor 2.7.x volt. Örülök neki, ha azóta sokat fejlődőtt (bár nem hiszem, hogy egyhamar újra foglalkozni fogok vele). Ettől függetlenül még mindig nem gondolom, hogy ha valaki funkc. programozást akar tanulni, akkor multiparadigmás nyelvvel érdemes kezdenie (ld. fentebb).

No problem, de erre meg annyit hadd reagaljak, hogy a korabban belinkelt scalas tanfolyamon ha jol emlekszem, a 8 (?) het alatt nem kerul elo pl. a var kulcsszo (egyebkent a class sem kb. a 4. hetig). Rengeteget szamit, hogy vaktaban kezdesz el kiserletezni egy nyelvvel, vagy valaki fogja a kezed kozben, es iranyit. Just my 2c.

( enpassant v | 2015. 01. 26., h – 16:09 )

Kicsit megkésve, de én is a Scala-ra szavaznék.
Multiparadigmás nyelv, így funkcionális, imperatív és OOP is egyben.
Ha csak a funkcionális programozás érdekel, akkor nagyon jó tanfolyam (amit korábban is említettek) illetve könyvek vannak a témában (pl. Functional Programming in Scala, Manning).

Számomra nagyon fontos egy nyelvnél a külső megjelenés és az érthetőség. Emiatt esett ki számomra több funkcionális nyelv is. Egyszerűen, ha ránéztem egy-egy példára, vagy csak zárójel hegyeket láttam, vagy elsőre érthetetlen kódokat. A Scala-nál nem volt ilyen érzésem, így szerintem könnyebben tanulható a funkcionális rész is.

A tanulásnál nagyon sokat segít, hogy van hozzá interaktív interpreter (REPL), ahol gyorsan és egyszerűen kipróbálhatók, megnézhetők a tanultak.

Az egyik legelterjedtebb funkcionális nyelv. A java interoperabilitása miatt, a rengeteg lib és framework hozzá, illetve a Typesafe által fejlesztett reactive stack (Akka, Play, Spray, Spark, ...) miatt szerintem az egyik legpiacképesebb már most és azt hiszem a jövőben ez egyre inkább így lesz.

Hat, ha a Minecrafthoz jo, akkor masra is jo lehet.

Van olyan doksi, ami kimondottan nem a funkcionalis lehetosegekre gyur ra? Nekem a szintaxis rettentoen... hat... kenyelmetlennek tunt.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Hat, Minecrafthoz is csak abbol a szemponbol jo, hogy a HotSwap miatt konnyu fejleszteni. (Amit a Legutóbb Java HotSwap, .NET Edit&Continue szavazás alapjan eleg kevesen - mernek - hasznalni.) Nagyjából ezek a legfobb ervek a Java+MC mellett. Meg, hogy valamivel konnyebb pluginezhetőséget nyújt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kosz, a funprog szamomra nem fun.

Amugy, kisse konkretabb ajanlasra gondoltam. Nem akarok random konyvekert ugy penzt adni, h nem tudom, egyaltalan foglalkozik-e azzal az aspektussal, ami nekem kell, vagy kizarolag funkcionalis programozast oktat, ami engem elegge nem erdekel - meg ha ezzel meg is bantok embereket.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nem bantasz meg senkit, csak teljesen ertelmetlen a kerdesed - olyan, mintha Javat szeretnel tanulni, de nem erdekelne az OOP. Ha a funkcionalis programozas mint olyan, teljesen hidegen hagy, maradj a Pythonnal, az a neked valo nyelv (en sem bantasbol mondom, a Python eleg sok dologra igen jol hasznalhato).

Nem teljesen ugyanarrol beszelunk. A Scala - a Javaval ellentetben - egy multiparadigmas nyelv, vagyis lehet OOP es funckionalis aspektusban is dolgozni benne. Szamomra azonban egy olyan konyv, ami nem foglalkozik reszletesebben az oroklodessel, az interfeszekkel es egyeb, az OOP-hez elengedhetetlen dolgokkal erdektelen, mivel engem a funkcionalis resze legfeljebb annyiban erdekel, amennyi ebbol az OOP szemlelethez kell. Ugyanakkor, ha funkcionalis aspektusbol szeretnek kozeliteni a Scala-hoz, akkor ezek a dolgok kisebb relevanciajuak lennenek, vagyis a feluletes ismeret boven eleg lenne ezekbol, hiszen sokkal hangsulyosabb lennenek a funkconalis programozas alapveto elemei.

Es nem bantasz meg, dolgoztam mar Pythonnal is, Rubyval is, ez utobbi a kedvenc programozasi nyelvem, de szeretek uj dolgokat kiprobalni, illetoleg szeretnek kicsit kozelebbrol megismerkedni a Minecraft modolasaval, de probalok a Java-nal egy kicsit tobbet nyujto rendszert talalni. Szamomra az idealis a Groovy lenne, azonban feleslegesnek tartom meg egy JVM nyelv behuzasat a jatekba, mikor ott a Scala.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Sajnos nagy tevedesben vagy. Az egy dolog, hogy persze a legtobb nyelven ossze lehet adni kettot meg kettot, az eredmenyt el lehet tarolni egy valtozoban, es ki is lehet iratni (bar van, ahol meg ehhez is trukkozni kell -> lasd Haskell :)). Ha ezen a szinten szeretned az adott nyelvet programozni, akkor hajra, bar sok ertelmet nem latom (termeszetesen eltekintve a munka miatt kotelezove tett programozastol).

Viszont ha elkezdesz Scalat tanulni, akkor nagyon-nagyon hamar belefutsz azokba a konstrukciokba, amikkel nem nagyon tudsz mit kezdeni majd ilyen hozzaallassal. Eleve, a teljes scalas collection library alapertelmezesben immutable, de mondjuk ebbol a csapdabol meg gyorsan ki lehet csusszani, ha rajossz, hogy vannak mutable collectionok is (vagy hasznalod a javas osztalyokat). De mar az oop reszen felhuzod a szemoldokod: mi a fenenek kulon tipus arra az osztalyra, amibol nem lehet leszarmazni (case class)? Micsoda marha volt, aki kitalalta, bezzeg a Javaban ott a final kulcsszo, ezeknek ez nem volt eleg. Vagy probalsz megirni egy for ciklust: eleve nagyon furcsa a szerkezete, a yield-nel meg esetleg eszedbe jutnak a pythonos generatorok, es karomkodsz, hogy miert kell ezt megint igy tulbonyolitani.

Aztan elkezdesz konyvtari funkciokat hasznalni: az Option class meg csak-csak (elvegre a 8-as Javaba is bekerult, valamire biztosan jo), de mi az, hogy van map metodusa? Es mit keres a for ciklusban? A Future/Promise parosnal feladod, ha egyaltalan eljutsz idaig.

Mas kodjat persze sosem leszel kepes olvasni, a barataidnak pedig korbekuldozgeted az erdekesebb Scalaz peldakodokat, amikben egy oldalon keresztul nincs is betu az angol abecebol. Mekkora bolcseszek ezek, mondod, sok idejuk lehet, az biztos. Kulonben is, olyan fuggvenyt irni, ami egy masik fuggvenyt ad vissza, hat nooormalis?

Amikor a Scalarol kerdeznek majd, a vallad vonogatod, hat igen, bonyolult a szintaxis, meg iszonyat lassu a fordito, raadasul refactoralni sem lehet, mert a kod teljesen olvashatatlan. Ez az evszazad atverese, az tuti. Es mindekozben a nyelv lehetosegeinek kb. 5 szazalekat lattad, es az 5 szazaleknak a felet sem ertetted meg. Talan ez a legnagyobb baj: nem is veszed eszre, hogy mennyi mindent nem veszel eszre.

Just FYI, been there, done that, got the T-shirt: en meg halvanyan emlekszem arra, amikor Scalat tanultam (pedig engem kifejezetten erdekelt a funkcionalis programozas is), illetve frusztralt kollegak reakcioira, kulonosen az utolso bekezdesben emlitettekre (aztan gyorsan kiderult, hogy az illeto, aki kritizalta az olvashatatlan szintaxist, azt sem tudta, mi a reduce/fold - hat igy tenyleg nehez...)

Ezt szeretnem megsporolni neked, akkor mar tenyleg inkabb a Groovy, az amugy is olyan Ruby-szeru, konnyen emesztheto, nem okoz kulonosebb hasfajast. Just my 2c.

UI: meg egy onzo hatso szandekom is van, ugyanis ezzel a hozzaallassal nem fogsz idiomatikus scala kodot irni - ez addig nem baj, amig csak te reszeled a kododat, de ha barki masnak is hozza kell nyulnia, nagyon hosszu kormondatokban fog fogalmazni, es valoszinuleg nem csak te fogsz csuklani utana...

Ugy erzem, kicsit elbeszelunk egymas mellett.

En nem mondtam, hogy mindenaron scalat akarok hasznalni. Jelen pillanatban ahhoz, amihez nekem szuksegem lehetne a scalara egyaltalan, semmifajta kenyszer nincs erre vonatkozoan, a rendszer transzparens modon tamogatja a pure java kornyezetet is. Ha nem tetszik a scala nyelv, vagy nem erzem hatekonyak, vagy nem boldogulok a megerteseben, akkor baromi egyszeruen le fogom tojni az egeszet ugy, ahogy van. Van ketszaz mas programozasi nyelv, amihez szinten nem ertek, eggyel tobb vagy kevesebb az en lelkemen torest nem fog okozni. Meg az is lehet, hogy a funkcionalis reszet is megszeretem, honnan a francbol tudjam?

Jelen pillanatban azonban adott egy alapvetoen Java-ban, tobbe-kevesbe OOP szemlelettel fejlesztett alkalmazas, amihez - mondjuk igy - plugint szeretnek csinalni. Tehat nem en valasztottam az OOP-t, ez adott. Van lehetosegem scala-t hasznalni, de ez egyaltalan nem kotelezo. Arra vagyok kivancsi, hogy erre a feladatra, ebben a kornyezetben hasznalhatok-e scalat, erdemes-e azt hasznalni, vagy hatekonyabb tudok lenni Java-ban. Engem az egeszbol a masfajta szintaktika es a masfajta logika erdekel.

Ertem, hogy te nagy funkcionalis programozas-fanatikus vagy, es ezert tisztellek is (oke, mint szent orultet, de a tisztelet a lenyeg :-) ), de nagyon kerlek, ne rendezz nekem itt rogtonitelo birosagot ugy, hogy egyfelol nem is ismersz engem, masfelol otleted sincs, mit akarok elerni egyaltalan.

Azt hiszem, abban mindketten megegyezhetunk, hogy a Java - minden jo tulajdonsaga ellenere - kihivasokkal kuszkodik, ha az egyszerubb szintaxisokra terelodik a szo. Tolem peldaul nem allnak nagyon tavol a lambda kifejezesek, a kulonbozo callbackek logikaja, meg ha ezt sokkal jobban szeretem OOP kornyezetben latni (emiatt kicsit ambivalens is a kapcsolatom a JavaScripttel, az szamomra tulsagosan funkcionalis). Ott, ahol lehet ilyeneket hasznalni, jelentosen leegyszerusodnek bizonyos dolgok, es rovidebbe, gyorsabba valik olyan logikak megvalositasa, amikhez normal Java-ban masfelszer annyi kod kell. Emiatt kezdtem el peldaul ismerkedni a Groovy-val. Lattam es olvasgattam is mar Scala kodot, es nem tartom feltetlenul olvashatatlannak, sot, lattam benne erdekes megoldasokat, amiket szeretnek jobban megismerni. Azonban ahhoz, hogy beleassam magam a melysegeibe, eloszor tudnom kellene hasznalni a nyelvet magat, ismernem kellene az eszkozeit. Nem tudok egybol funktorokat hasznalni anelkul, hogy meg ne ismernem oket alapszinteni.

Ami miatt kiemeltem az OOP fontossagat, az pusztan az az indok, hogy az, amivel ki akarom probalni, eroteljesen OOP szemleletet kovetel. Nem funkcionalist, OOP-t. Annak pedig nem tudok ugy nekimenni, hogy nem ismerem a Scala OOP reszet rendesen.

Koszonom, ha eljutottal eddig a sorig.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Röviden: nem, ne akarj egy meglévő kódbázishoz scala-ban kódot írni. Lefőképp azért nem, mert mint a felettünk szóló elmondta, nem értesz a nyelvhez. Biztos, hogy egy meglévő
kódbázishoz egy új nyelvet kell behozni azért, mert "állítólag" jobb a Scala? Úgy, hogy esetenként több ember dolgozik rajta. Te lehet hogy esetleg érteni fogod a kódot, de van értelme? A funkcionális programozás prolog és sml tapasztalataim alapján teljesen másfajta gondolkodásmódot igényel, mint a procedurális/oop. Értem én, hogy lehet keverni, de a mákostésztát sem keverjük össze a krumplilevessel, csak azért, mert egy helyre megy :)

"Biztos, hogy egy meglévő kódbázishoz egy új nyelvet kell behozni azért, mert "állítólag" jobb a Scala?"

Olyan ertelemben a Scala nem uj nyelv, hog a Minecraft jelenleg is hasznal Scala-t bizonyos helyeken, tehat a projekt szemszogebol a nyelv egyaltalan nem uj.

"Ugy, hogy esetenként több ember dolgozik rajta."

Felreertetted. En egy modot, egy plugint akarok csinalni, amin 1 azaz egy darab ember dolgozna: en magam. Csak nekem kell erteni a kodot, senki masnak.

Ami a funprog-ot illeti: sokadszorra probalom jelezni kezzel-labbal, hogy en a scalabol alapvetoen nem a funkcionalis reszre vagyok kivancsi. Persze, az is erdekel, de en a Scalanak inkabb az OOP megkozelitesevel akarok ismerkedni, semmint a funkcionalis reszevel. Nem akarok tisztan funkcionalis szemleletu kodot irni, kozel akarok maradni a Java-hoz, engem a Scala foleg a szintaxisa miatt erdekel, a funkcionalis megkozelites bizonyos esetekben egyszerubb szintaxist hoz magaval, en tisztan emiatt akarom kiprobalni a Scalat. Ezert engem nem bant az, hogy nem pont olyan kodot fogok kesziteni, mintha Prologban irnam...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"Minecraft jelenleg is hasznal Scala-t bizonyos helyeken" vs "MC-t Scalaban írták" - ReadException

Amugy meg alapbol betelepul egy komplett scala runtime a libek koze, gondolom, hogy nem azert, mert valakinek rettenetesen vicces kedve volt. De valoban nem neztem utana, hogy a deobfuszkalt forrasfaban van-e scala fajl. De ha neked van idod, akar utana is nezhetnel.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A funkcionális programozás prolog és sml tapasztalataim alapján teljesen másfajta gondolkodásmódot igényel

Gondoltam tudja, mirol beszel, en csak emlitesszintjen ismerem a Prologot.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Kb. fél éve vagyok scala fejlesztő, nekem ezzel az a tapasztalatom, hogy ha scalaban fejlesztesz, akkor kerüld a java library-ket, mert legtöbb esetben csak szívás lesz belőle. Ennek két okát látom.

Az egyik, hogy a java libraryk tisztán oop szemléletmódot követnek, ami sokszor nem illik bele egy scala kódba. Pl. ott a Calendar, ami amúgy javaban is egy ronda valami, de alapvetően beleillik a javas oop szemléletmódba. Viszont scalaból nagyon kilóg, a mutable state-jével, gettereivel és settereivel. Persze van ellenpélda is, ott a yoda-time ami immutable objektumokat használ, ezért közelebb áll a scala szemléletmódhoz.

A másik, hogy a scalanak van egy standard library-ja, amire azért van szükség, mert a java standard library nem a funkcionális gondolkodásmódra épül. Egy java library pedig nem fogja a scala standard libraryt támogatni.

Ezért ha mégis java libraryra van szükség, akkor sokszor az a megoldás, hogy írnak egy scala libraryt, ami a háttérben a java libraryt használja, és ami egyrészt kezeli a scala típusokat, másrészt ha kell akkor megoldja, hogy az illeszkedjen a scala szemléletmódba.

Amennyire en latom, a Minecraftban ez a resze reszben megoldott, reszben pedig elkerulhetetlen. Tekintve, hogy a jatekot alapvetoen Javaban irtak, nehez elkerulni a Java alapu konyvtarak hasznalatat, hiszen mind a kornyezet, mind pedig a legtobb mod alapvetoen Javaban irodott. Reszben pedig mintha lattam volna Scala-kompatibilis reszeket is benne, de a taszklistan az elso pontok kozott szerepel, hogy ennek melyebben utanaolvassak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Amiket mellékeltem, azok mind általánosan tárgyalják a Scalat.
Különösen ajánlom a Venkat Subramaniam és a Martin Odersky által írtat.

"Kosz, a funprog szamomra nem fun."
Ha van egy fél óra időd, akkor nézz bele a videóba. Lehet az FP-t fun módon is tanulni.

Illetve a videó sem csak az FP-re összpontosít, hanem a Scala elég nagy részét bemutatja elég érdekes módon.

( xea v | 2015. 01. 27., k – 10:56 )

OOP tapasztalat utan nem maga a nyelv, hanem a gondolkodasmod elsajatitasa a legnehezebb. Elso pillantasra vonzo lehet a Scala, hiszen eros a marketing, jo a coursera kurzus, van viszonylag sok felhasznalo, stb stb de tul sokban hasonlit a Javahoz ahhoz, hogy elkenyelmesitsen es Java-szeru kodot irj Scalaban es azt hidd, hogy ez FP, holott csak a kulcsszavakat cserelted le val/var/sealed/satobbire. Tovabbi vonzo erv a Scala/Clojure vonalnak, hogy a JVM miatt lehetoseget ad a millio tonnanyi mar megirt kod hasznalatara, de ez csak egy ujabb lehetoseg a lusta/rossz kod irasara.

Ezert elsonek a Haskellt javasolnam, mert tisztan funkcionalis nyelv (annak is igazan remek) es ezaltal rakenyszerit arra, hogy te magad kezdj funkcionalisan gondolkodni. Ez persze valoszinuleg nem fog konnyen menni, mert olyan absztrakt gondolkodasmod kell hozza, amivel ritkan talalkozik az ember OOP nyelveknel (typeclassok, functorok, applicative-ok, monadok, monoidok, arrowok, currying, function composition, stb).

Erdemes peldaul a http://learnyouahaskell.com/ -dal kezdeni, mert kezdoknek szol es mire a vegere ersz, egeszen mashogy fogod latni a vilagot.

"OOP tapasztalat utan nem maga a nyelv, hanem a gondolkodasmod elsajatitasa a legnehezebb."

A gondolkodásmód elsajátítás a lényeg és valóban az a legnehezebb. Scala-nál az a könnyebbség megvan, hogy ismerős dolgokon keresztül tudod elsajátítani a gondolkodásmódot. Ha még a jelölések is ismeretlenek, akkor még nehezebb dolguk van azoknak, akik már nagyon hozzászoktak az ismerős jelölésekhez. Legalábbis a saját tapasztalatom ez.

Illetve még az is vízválasztó talán a két megközelítés között, hogy az egyiknél kvázi mindent meg kell tanulni a funkcionális programozásról, míg a másiknál a fokozatos megismerés is lehetséges.

Nem vagyok a Haskell ellen, sőt az egyik legjobbnak tartom (még a jelölés rendszere is a barátibbak közé tartozik). Ha jó funkcionális programozóvá akar válni valaki, akkor tényleg nagyon jó azzal kezdeni. Ha a cél viszont a funkcionális programozás megismerése, hogy jobb programozóvá váljak erős OOP háttér után, akkor inkább a Scala-t javasolnám (persze itt is el lehet jutni a jó funkcionális programozó szintig).