Funkcionális programozási nyelv kiválasztása [zárt]

Mivel praktikus   nyelv:

Vegyük észre, hogy a Haskell és a Lisp többet használ az iparban, mint a többi, bár vannak nemrégiben érdeklődött a Clojure és az F # iránt.

De nézze meg, mi történik, ha a Sémát hozzáadjuk a keverékhez:

Hmm, most nem hasonlít annyira egy akadémiai nyelvre, igaz?

Valójában a fenti grafikon valószínűleg hazugság; a “séma” szó megjelenhet a segítségben keresett hirdetéseket a programozási nyelveken kívül más kontextusokban is. 🙂

Tehát itt van egy másik grafikon, amely valószínűleg (egy kicsit) reprezentatívabb:

Ha a rendszer igazán rugdaló nyelvjárását szeretné felfedezni, nézze meg a Ütő.

Megjegyzések

• Hú, szép bejegyzés. Az ütő pontosan az, amit ' használok … A PLT-Scheme volt a neve, amikor elkezdtem megtanulni. Az a piros vonal az utolsó grafikában aggaszt. Soha nem gondoltam volna, hogy a Séma ennyire felhasználható. És Clojure biztosan felszállni látszik. Hmm …
• @M. Joanis: Vegyük az utolsó két grafikont egy szem sóval; a lépcsőzetes megjelenés és az utolsó grafikon volatilitása arra utal, hogy a grafikonon nincs sok adatpont, bár ez azt jelzi, hogy valaki úgy gondolja, hogy a nyelvekért érdemes fizetni.
• @Robert Harvey, mi megváltozott a másodikról a harmadikra?
• @Geoffrey: Nézd meg a feliratokat; Hozzáadtam a " developer " szót a keresési kifejezésekhez.
• Ne feledje, hogy Haskell és Lisp is homonimák és hogy Valóban ' adatai nem általánosítják a világ többi részét. Az ITJobsWatch 79 Scala-munkát, 55 F #, 47 Haskell, 30 Lisp és 7 Clojure feladatot sorol fel.

Ha funkcionális programozást szeretne megtanulni, akkor jobban szolgálhat, ha először megtanulja Haskellt, majd használja a kívánt nyelvet. Megtanulhatja a funkcionális programozást a többi nyelv használatával, de ezek továbbra is lehetővé teszik az imperatív és az objektum-orientált kód használatát. Ha valódi programot ír a Haskellben, akkor gyorsabban megtanulja a funkcionális programozást, mert a többi paradigma nem lesz elérhető, hogy visszaléphessen.

A Haskell program megírása után olyan eszközök állnak rendelkezésére, mint monádok és technikák. mint a pont nélküli kódolás, hogy eljusson az Ön által választott nyelvhez. Úgy tűnik, hogy a fogalmak különösen jól illeszkednek a rendszerhez.

Megjegyzések

• Szerintem ön ' igaza van abban, hogy először egy tiszta funkcionális nyelvet válasszon ki. Nagyon érdekelne, hogy a funkcionális nyelvek tisztaság szerint rendeződnének-e.
• @ M. Joanis: a kérdésedben felsorolt nyelveken azt mondanám, hogy a Haskell a legtisztább, őt követi a Clojure, az F # és a Lisp.

Valójában, ha képes voltál egy ésszerűen összetett rendszert megvalósítani a Sémában, akkor meglehetősen kívánatos azoknál a vállalatoknál, ahol valószínűleg dolgozni szeretne. Pályafutásom során korábban összefutottam néhány hallgatóval, akik elég sok munkát végeztek a Scheme-ben, és csak akkor volt hátrány, amikor nem tudták megmagyarázni a munkájukat, vagy nem értették meg elég jól az alapadatok megvalósításához. struktúrák és algoritmusok ésszerű időn belül. Mindig hagytam, hogy a jelöltek válaszoljanak az ilyen kérdésekre az általuk preferált nyelven; összefutottam néhány olyan emberrel, aki úgy gondolta, hogy ők a legjobbak a Scheme-ben, akiknek elég sokat sikerült megküzdeniük olyan dolgokkal, amelyeknek könnyűnek kellett lenniük mint egy elem hozzáadása egy összekapcsolt listához, ami engem misztifikált.

De ha elég jól “megszerezhetné” a Sémát, hogy akár egy átlagos webalkalmazást is megírhasson, az legfeljebb nagyon jó értékesítési pont lenne komoly szoftvercégek.

Ha egy “blub” üzletben interjúkat folytatna, és a fejlesztők csak furcsának gondolták volna, ha a Scheme-ben vagy a Haskellben vagy az F # -ben jártas vagy, valószínűleg nem akarsz ott dolgozni. A legtöbb esetben az illetékes fejlesztők választják a koncerteket, ezért ne “izzadjon” a gyakorlatiasságra, hacsak az egyetlen lehetőség, amelyet elképzelhet a jövőben, nem vállalati. Dolgozzon azon, hogy kompetens, rugalmas és lebontsa a problémákat.

A főiskola nem a praktikumról szól. A felfedezés és a tanulás biztonságos környezetének megteremtéséről van szó. Ez tulajdonképpen hasznos, még akkor is, ha karrierje hátralévő részében rendes szoftvert ír.

Ennek ellenére nem mondom ” Nem látja, miért akarna csak egy ilyen választásra korlátozni ilyen hamar. Könnyen megértheti mind a négy nyelvet körülbelül 4 hét alatt, majd válasszon egyet, amelyre a jelenlegi szeszélyeihez a legjobban összpontosíthat. térj vissza egy másik lehetőségedhez, és próbálj meg valami hasonlót megvalósítani. Lépj tovább valami összetettebbre, és fontold meg újra a lehetőségeidet. A kísérletezés jó. Hacsak nem próbálsz megélni a következő hónapban, akkor nem kell lettem még szakember.

Írtam néhányat a Scheme-ben, az F # -ben, az Emacs Lisp-ben és a Common Lisp-ben, és elolvastam legalább egy kis Haskell-t, legalábbis alkalmanként az elmúlt néhány évben. Nem mondhatom, hogy egyikükben sem vagyok szakértő, de ezekre a nyelvekre tett minden egyes kirándulás előnyös volt számomra az összes többi nyelven, amelyen professzionálisan dolgozom (C #, Java, Ruby, és esetenként Boo, Perl és Python). A kíváncsiság tartósabb, teljesebb karriert hoz létre, mint bármi más.

Megjegyzések

• " mindennél kitartóbb, teljesebb karriert hoz létre. " Ez az állítás nagyon inspiráló. ' igazad van. Én ' túlságosan is siettem. Mindig úgy érzem, hogy mindez túl sok időbe telik a tanuláshoz … Ha 12 évvel visszamehetnék, amikor elkezdtem, akkor ' nem tudom, hogy ne pazaroljam el az összes idő a VB-n és a C ++ -on. Úgy érzem, hogy ezek az évek nagyon csúnyán elpazaroltak. Nem voltam ' elég kíváncsi. Kódolni akartam cuccokat. Az általam ismert nyelvek használata elég volt. Akkor azt hittem, hogy tisztességes összeget tudok, de ez olyan borzalmasan egyáltalán nem volt ' az eset.

Egy ideig Haskellbe merültem, de arra a következtetésre jutottam, hogy egy kicsit túl akadémikus volt. Nagyon nehéz volt valami praktikusat megtenni. Tiszta funkcionális nyelven olyan dolgok, mint az IO, egyszerűen nem illenek bele a modellbe, ezért monádokkal kell megküzdenie. Elhatároztam, hogy óriási időt kell töltenem, hogy csak kompetens legyek, ezért továbbléptem .

A Scheme-et az egyetemen csináltam. Triviálisnak tűnhet, de az összes szülő valóban zavaró / idegesítő. Nehéz erre visszatérni, miután olyan nyelveket használtam, mint a Python.

Nemrégiben F # felfedezése. Funkcionális, de elengedhetetlen és objektumorientált is lehet, amikor csak akarja. Ez, valamint bármilyen .NET könyvtár használata, lehetővé teszi a tiszta funkcionális részek könnyebb összekeverését praktikusabb dolgokkal, például GUI-k, IO és hálózat. Az F # önálló verzióját kaphatja meg.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=effc5bc4-c3df-4172-ad1c-bc62935861c5&displaylang=en

Megjegyzések

• Az a tény, hogy az F # és a Clojure nem pusztán funkcionális, fontos szerepet játszik számukra. Talán az F # lehet a belépési pontom a .Net család valamikor …
• @MJoanis, a költséget pontként tüntetted fel az F # -val szemben, de ahogy Erik rámutat, teljesen ingyen kaphatod.
• Ha jól olvasom a feltételeket, akkor alapvetően ingyen kapod meg a feltételt. nem használja (vagy vásárol licenceket). De megértem, hogy még mindig nagyon jó dolog megtanulni, ha a Visual Studiót használó társaságba kerülök.Valószínűleg kipróbálom ', ha egyszer funkcionál ' m szabadabb funkcionális programozási nyelvvel.
• @M. Joanis: Nem, az F # még nyílt forráskód is, és megpróbálhatsz más platformokon befutni a Mono-ban.
• Lehet, hogy 2010 óta változtak az idők, de mint aki az elmúlt hónapokban kezdett el haskellet tanulni, én ne ' ne gondolja, hogy az IO-t haskellben egyáltalán nehéz elvégezni. Az alapvető dolgokhoz csak meg kell tanulnod néhány új do-szintaxist. A valódi alapvető megértés eltartása néhány hétig tart, de valójában nem látom ', hogy mi a fuzz a monádokról. Nem gondolom, hogy ' szerintem nehezebb volt megtanulni őket, mint az OOP osztályai, példányai, statikus tagjai és az összes többi államhoz kapcsolódó jazz.

Az összes főbb funkcionális nyelvet egy-két évvel ezelőtt értékeltem abból a szempontból, hogy gyakorlati, általános célú funkcionális programozási nyelvet szeretnék.

Végül a Clojure-t választottam , amely később kiváló választásnak bizonyult.

A legfontosabb okok a következők voltak:

• Könyvtári ökoszisztéma – ahhoz, hogy egy nyelv hasznos legyen, hozzáférésre van szükség a jó könyvtárakhoz. A JVM-en való részvétel azt jelenti, hogy könnyen hozzáférhet a legnagyobb nyílt forráskódú könyvtárhoz és eszköz-ökoszisztémához, így a JVM nyelvre való törekvés gyakorlatias szempontból nem gond. Scala itt is magas pontszámot ért el.

• Makro-metaprogramozás – Ez a szempont a Lisp-től mindig felhívott engem, főleg, hogy számítottam arra, hogy meglehetősen kevés kódot generálok. “Nagyra értékeltem Paul Graham rövid esszéjében” Az átlagok legyőzése elhangzott érveket. A különféle Lisps itt mind erősen gólt szerzett.

• A teljesítmény “jó” elég “- A Clojure mindig össze van állítva, és kihasználja a JVM JIT optimalizáló és a kiváló GC előnyeit. Mint mindig, van némi rezsi a funkcionális nyelv használatában, de a Clojure használatával egyértelmű volt, hogy mindegyik kis erőfeszítéssel megközelítheti a Java sebességét (a Clojure támogatja a Java primitíveket és az opcionális statikus gépelést azokban a helyzetekben, ahol szüksége van rá). Becslésem szerint a Clojure 2-5x lassabban futballpark, mint amit optimális Java vagy C ++ kóddal érhet el, ami összhangban áll azzal, amit a hibás referenciaértékekben látni , és idővel arra számítok, hogy ez a rés tovább szűkül. Ezenkívül elég egyszerűen megírni a kifejezetten teljesítményérzékeny kódokat tiszta Java-ban, és hívni a Clojure-ból.

• Párhuzamosság – A Clojure meglehetősen egyedi és erőteljes megközelítést alkalmaz a párhuzamosságra, különösen a nagyon sok magot tartalmazó párhuzamosság esetén. Ezt “kicsit nehéz megmagyarázni, de ez a videó kiváló , hogy ízelítőt adjon az alapelvekből. Úgy gondolom, hogy a Clojure-nak van a legjobb válasz arra a trükkös kérdésre, hogy “hogyan kell kezelni a megosztott, egyidejű és mutábilis állapotot egy funkcionális programozási nyelven?”.

• Nyelvtervezés – A Clojure az IMO nagyon átgondolt nyelvterve. Ilyenek például a vektoros [] és a térképes {literálok a szokásos Lisp zárójel mellett, a megváltoztathatatlan állandó adatstruktúrák használata, a szekvencia-absztrakció révén a nyelv egészében való lustaság támogatása, valamint a programozó számára számos ortogonális tulajdonság biztosítása különböző problémák megoldására . Lásd: az absztrakció művészete és a egyszerű, egyszerű .

• Közösség – mindig szubjektív, de tetszett, amit a Clojure közösségben láttam. A hozzáállás nagyon hasznos, konstruktív és pragmatikus volt. Jelentős hangsúlyt kap a “végezzen dolgokat”, ami valószínűleg azt tükrözi, hogy sok Clojure-ember (beleértve Rich Hickey-t is) összetett vállalati rendszerek kiépítésének hátteréből származik. Az a tény, hogy a Clojure közösségnek szoros kapcsolatai vannak a Java közösséggel is, fontos volt abban, hogy meggyőzzek arról, hogy a Clojure nem kockáztatja meg, hogy elakadjon egy “fülkében”.

Ha meg kellene neveznem a Clojure néhány kisebb hátrányát, ezek a következők lennének:

• Dinamikus gépelés – ez gyakran előnyt jelent a termelékenység szempontjából, de átlagosan azt hiszem, hogy ezt erősebb típusellenőrzésre és következtetésre cserélném. Többnyire ezt enyhíti egy jó automatizált tesztcsomag, de ha tetszik, hogy típusait a fordító statikusan érvényesítette, akkor inkább Haskell vagy Scala lehet a teáscsésze.

• iv