Een functionele programmeertaal kiezen [closed]

Omdat je een praktische   taal:

Merk op dat Haskell en Lisp meer worden gebruikt dan de anderen in de industrie, hoewel er is recentelijk geïnteresseerd geweest in Clojure en F #.

Maar kijk wat er gebeurt als we Scheme aan de mix toevoegen:

Hmm, “lijkt nu niet zo veel op een academische taal, toch?

Eigenlijk is de bovenstaande grafiek waarschijnlijk een leugen; het woord” schema “kan in de help verschijnen gezochte advertenties in andere contexten dan programmeertalen. 🙂

Dus hier is een andere grafiek die waarschijnlijk (een beetje) representatiever is:

Als je een echt geweldig dialect van Scheme wilt verkennen, kijk dan eens naar Racket.

Reacties

• Wauw, leuk bericht. Racket is precies wat ik ' gebruik … PLT-Scheme was de naam toen ik het begon te leren. Die rode lijn in de laatste afbeelding baart me zorgen. Nooit gedacht dat Scheme zoveel zou kunnen worden gebruikt. En Clojure lijkt zeker een vlucht te nemen. Hmm …
• @M. Joanis: Neem de laatste twee grafieken met een korreltje zout; het trapsgewijze uiterlijk en de vluchtigheid van de laatste grafiek suggereren dat er niet veel datapunten in de grafiek zijn, hoewel het wel aangeeft dat iemand denkt dat de talen het waard zijn om voor te betalen.
• @Robert Harvey, wat veranderd van de tweede naar de derde grafiek?
• @Geoffrey: Kijk naar de bijschriften; Ik heb het woord " ontwikkelaar " aan de zoektermen toegevoegd.
• Merk op dat Haskell en Lisp ook homoniemen zijn en dat de gegevens van ' inderdaad niet generaliseren naar de rest van de wereld. ITJobsWatch somt 79 Scala-banen, 55 F #, 47 Haskell-, 30 Lisp- en 7 Clojure-banen op.

Als je functioneel programmeren wilt leren, is het misschien beter om eerst Haskell te leren en vervolgens de taal te gebruiken die je wilt. U kunt functioneel programmeren leren met de andere talen, maar ze laten nog steeds imperatieve en objectgeoriënteerde code toe. Als je een echt programma in Haskell schrijft, leer je functioneel programmeren sneller omdat de andere paradigmas niet beschikbaar zijn om op terug te vallen.

Na het schrijven van je Haskell-programma heb je tools zoals monaden en technieken zoals puntvrije codering om in de taal van uw keuze te brengen. De concepten lijken bijzonder goed in overeenstemming te zijn met Scheme.

Opmerkingen

• Ik denk dat u ' hebben gelijk over het kiezen van een puur functionele taal. Ik zou erg geïnteresseerd zijn in een ordening van functionele talen op basis van zuiverheid.
• @M. Joanis: of de talen die in uw vraag worden vermeld, zou ik zeggen dat Haskell de puurste is, gevolgd door Clojure, F # en Lisp.

Eigenlijk, als je in staat zou zijn om een redelijk complex systeem in Scheme te implementeren, zou je ” redelijk wenselijk bij bedrijven waar je waarschijnlijk zou willen werken. Eerder in mijn carrière kwam ik enkele studenten tegen die behoorlijk wat werk hadden verzet in Scheme, en de enige keer dat het een nadeel was, was dat ze hun werk niet konden uitleggen of het niet goed genoeg begrepen om basisgegevens te implementeren structuren en algoritmen binnen een redelijke tijd. Ik laat kandidaten altijd zulke vragen beantwoorden in hun voorkeurstaal; ik kwam wel een paar mensen tegen die dachten dat ze het beste waren in Scheme, die nogal wat worstelden met dingen die gemakkelijk zouden moeten zijn, zoals het toevoegen van een element aan een gekoppelde lijst, wat me verbijsterd.

Maar als je het schema goed genoeg zou kunnen “krijgen” om zelfs maar een gemiddelde webapp te schrijven, zou dat hoogstens een goed verkoopargument zijn serieuze softwarebedrijven.

Als je interviewde in een “blub” -winkel en de ontwikkelaars dachten dat je gewoon raar was vanwege je vaardigheid bij Scheme of Haskell of F #, dan zou je daar waarschijnlijk niet willen werken. In de meeste gevallen krijgen bekwame ontwikkelaars hun keuze uit optredens, dus maak je geen zorgen over praktische zaken, tenzij de enige opties die je in je toekomst kunt bedenken zakelijk zijn. Werk eraan om bekwaam en flexibel te zijn en problemen op te lossen.

College gaat niet over praktische zaken. Het gaat erom een veilige omgeving te creëren om te verkennen en te leren. Dat is in feite nuttig, zelfs als je de rest van je carrière gewone software gaat schrijven.

Dat gezegd hebbende, doe ik niet ” Ik snap niet waarom je je zo snel tot slechts een van die keuzes wilt beperken. Je zou gemakkelijk een idee kunnen krijgen van alle vier de talen in ongeveer vier weken, en er dan een uitkiezen om je op te concentreren dat het beste past bij je huidige grillen. ga terug naar een van uw andere opties en probeer iets soortgelijks te implementeren. Ga verder met iets complexers en overweeg uw opties opnieuw. Experimenteren is goed. Tenzij u volgende maand probeert uw brood te verdienen, hoeft u dat niet te doen word al een specialist.

Ik heb er een paar geschreven in Scheme, F #, Emacs Lisp en Common Lisp, en heb in ieder geval een beetje Haskell gelezen, in ieder geval af en toe de afgelopen jaren. Ik kan niet zeggen dat ik een expert ben in een van deze talen, maar elke excursie in die talen heeft me geprofiteerd in alle andere talen waarin ik professioneel werk (C #, Java, Ruby en af en toe Boo, Perl en Python). Nieuwsgierigheid zal je een duurzamere carrière geven die meer voldoening geeft dan wat dan ook.

Reacties

• " Nieuwsgierigheid zal voor je een duurzamere, vervullende carrière opbouwen dan iets anders. " Deze uitspraak is zeer inspirerend. Je ' heeft gelijk. Ik ' ben te gehaast. Ik heb altijd het gevoel dat het allemaal te veel tijd kost om te leren … Als ik 12 jaar terug zou kunnen gaan, toen ik begon, ' zou ik weten dat ik niet al mijn tijd op VB en C ++. Ik heb het gevoel dat deze jaren behoorlijk verspild waren. Ik was niet ' niet nieuwsgierig genoeg. Ik wilde dingen coderen. Het was voldoende om de talen te gebruiken die ik kende. Ik dacht op dat moment dat ik een behoorlijk bedrag wist, maar dat was zo vreselijk niet ' het geval.

Ik dook een tijdje in Haskell, maar de conclusie die ik kwam was dat het een beetje te academisch was. Het was erg moeilijk om iets praktisch te doen. In een puur functionele taal passen dingen als IO gewoon niet helemaal in het model, dus je hebt te maken met monaden. Ik besloot dat ik enorm veel tijd zou moeten steken om nauwelijks competent te zijn, dus ging ik verder .

Ik heb Scheme op de universiteit gedaan. Klinkt misschien triviaal, maar alle ouders zijn echt afleidend / vervelend. Moeilijk om daar op terug te komen na het gebruik van talen zoals Python.

Sinds kort heb ik aan het verkennen van F #. Het is functioneel, maar kan ook noodzakelijk en objectgericht zijn wanneer u dat wilt. Dit, samen met de mogelijkheid om .NET-bibliotheken te gebruiken, maakt het mogelijk om uw puur functionele onderdelen gemakkelijk te combineren met meer praktische dingen zoals GUIs, IO en netwerken. U kunt een zelfstandige versie van F # krijgen.

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

Reacties

• Het feit dat F # en Clojure niet puur functioneel zijn, speelt een belangrijke rol in hun voordeel. Misschien zou F # mijn startpunt kunnen zijn in de .Net familie ooit …
• @MJoanis, je noemde de kosten als een punt tegen F #, maar zoals Erik opmerkt, kun je het helemaal gratis krijgen.
• Als ik de voorwaarden goed lees, krijg je het in principe gratis onder de voorwaarde van het niet gebruiken (of licenties kopen). Maar ik begrijp dat het nog steeds heel goed kan zijn om te leren voor het geval ik in een bedrijf terecht kom dat Visual Studio gebruikt.Ik ' zal het waarschijnlijk proberen als ik ' functioneel ben met een meer gratis functionele programmeertaal.
• @M. Joanis: Nee, F # is zelfs open source en je kunt proberen om Mono op andere platforms te gebruiken.
• Misschien zijn de tijden veranderd sinds 2010, maar als iemand die de afgelopen maanden haskell begon te leren, heb ik denk niet dat ' IO doen in haskell helemaal niet moeilijk is. Voor basisdingen hoef je alleen maar wat nieuwe do-syntaxis te leren. Het echte fundamentele begrip krijgen duurt een paar weken, maar ik begrijp echt niet wat de fuzz is over monaden. Ik denk niet ' dat ze moeilijker te leren waren dan klassen, instanties, statische leden en alle andere staatsgerelateerde jazz in OOP.

Ik heb alle belangrijke functionele talen een jaar of twee geleden geëvalueerd, vanuit het perspectief van het zoeken naar een praktische functionele programmeertaal voor algemeen gebruik.

Ik heb uiteindelijk Clojure gekozen, wat later een uitstekende keuze is gebleken.

In het algemeen waren de belangrijkste redenen:

• Bibliotheek-ecosysteem – om een taal bruikbaar te maken, heb je toegang nodig naar goede bibliotheken. Als je op de JVM zit, heb je gemakkelijk toegang tot de grootste open source bibliotheek en tool-ecosysteem, dus het was een pragmatisch perspectief om voor een JVM-taal te gaan. Scala scoorde hier ook hoog.

• Macro-metaprogrammering – Dit aspect van Lisp sprak me altijd aan, vooral omdat ik verwachtte nogal wat code te genereren. Ik “heb de argumenten in het korte essay van Paul Graham” Beating The Averages zeer op prijs gesteld “. De verschillende Lisps scoorden hier allemaal sterk.

• Prestaties was “goed genoeg “- Clojure wordt altijd samengesteld en krijgt de voordelen van de JVM JIT-optimizer en uitstekende GC. Zoals altijd is er wat overhead bij het gebruik van een functionele taal, maar met Clojure was het duidelijk dat je elk met een beetje moeite de Java-snelheid kunt benaderen (Clojure ondersteunt Java-primitieven en optioneel statisch typen voor die situaties waarin je het nodig hebt). Ik schat dat Clojure 2-5x langzamer is dan wat je zou kunnen bereiken met geoptimaliseerde Java- of C ++ -code, wat consistent is met wat je ziet in de gebrekkige benchmarks , en ik verwacht dat die kloof na verloop van tijd nog kleiner zal worden. Het is ook gemakkelijk genoeg om gewoon bijzonder prestatiegevoelige code in pure Java te schrijven en deze vanuit Clojure aan te roepen.

• Gelijktijdigheid – Clojure heeft een vrij unieke en krachtige benadering van gelijktijdigheid, met name voor gelijktijdigheid met meerdere kernen. Het is een beetje moeilijk uit te leggen, maar deze video is uitstekend om een voorproefje te geven van de principes. Ik denk dat Clojure momenteel het beste antwoord heeft op de lastige vraag “hoe moet je de gedeelde, gelijktijdige en veranderlijke staat beheren in een functionele programmeertaal?”.

• Taalontwerp – Clojure is IMO een zeer goed doordacht taalontwerp. Voorbeelden zijn het hebben van vector- [] en kaart {} letterlijke tekens naast de reguliere Lisp-haakjes, het gebruik van onveranderlijke persistente gegevensstructuren, het ondersteunen van luiheid in de taal via de sequentie-abstractie en het bieden van een verscheidenheid aan orthogonale functies aan de programmeur om verschillende problemen op te lossen . Zie de kunst van abstractie en eenvoudig gemaakt gemakkelijk .

• Gemeenschap – altijd subjectief, maar ik vond wat ik zag in de Clojure-gemeenschap. De houding was erg behulpzaam, constructief en pragmatisch. Er is een sterke nadruk op “dingen gedaan krijgen”, mogelijk als gevolg van het feit dat veel Clojure-mensen (waaronder Rich Hickey zelf) afkomstig zijn uit het bouwen van complexe bedrijfssystemen. Het feit dat de Clojure-gemeenschap ook sterke banden heeft met de Java-gemeenschap, was belangrijk om mij ervan te overtuigen dat Clojure “niet het risico loopt vast te komen te zitten in een” niche “.

Als ik een paar kleine nadelen van Clojure zou moeten noemen, zouden dit zijn:

• Dynamisch typen – vaak is dit een voordeel in termen van productiviteit, maar gemiddeld denk ik dat ik dit zou ruilen voor sterkere typecontrole en gevolgtrekking. Meestal wordt dit verzacht door een goede geautomatiseerde testsuite te hebben, maar als je houdt van statisch gevalideerde typen door de compiler, dan zijn Haskell of Scala misschien meer jouw ding.

• Baanbrekend – Clojure ontwikkelt zich erg snel en er is een er is veel innovatie gaande – het nadeel hiervan is dat er veel wordt geëxperimenteerd, dat sommige bibliotheken en tools nog niet volgroeid zijn, en dat er af en toe veranderingen optreden tussen belangrijke Clojure-versies die je in de gaten moet houden.

Al met al denk ik niet dat je met Clojure fout kunt gaan als je een uitstekende en pragmatische moderne functionele taal wilt!

Opmerkingen

• Bedankt! Goede post! Ik overwoog het tegenwoordig gewoon om het te gebruiken voor een intern project van een bedrijf dat sterk gebaseerd zal zijn op bomen en recursiviteit. Bovendien hebben we hier nogal wat Java-code die we kunnen hergebruiken met Clojure.

It Het lijkt erop dat je je huiswerk hebt gedaan, dus je weet dit waarschijnlijk al, maar Scheme is een Lisp-dialect, net als Common Lisp. Als je veel van Scheme houdt, maar het academische karakter ervan niet leuk vindt, probeer dan Common Lisp. Volgens de TIOBE-index is dit de 13e meest populaire taal versus schema op positie 26.

Er zijn maar weinig talen die u De genoemde functies verschijnen op de functiebeschrijvingen die ik onlangs heb gezien, hoewel dat misschien mijn kleine voorbeeldset is. Persoonlijk zal ik Haskell leren, ook al verwacht ik niet dat ik die taal rechtstreeks in mijn werk zal gebruiken. De concepten van functioneel programmeren zijn voor mij waardevoller voor toekomstige programmaontwerpen dan de directe verkoopbaarheid van de taal zelf.

Opmerkingen

• Bedankt voor de TIOBE link, dat is een interessante referentie. Ik neem aan dat je Haskell kiest vanwege zijn puurheid in termen van functioneel programmeren?
• @ M.Joanis: Vrijwel, hoewel ik ' denk om later verder te gaan Lisp ook. Zie programmers.stackexchange.com/questions/18838/…
• Het gekozen antwoord maakt veel zin. Zuiverheid lijkt de weg te gaan totdat ik het hele functionele paradigma echt begrepen heb.