Valg af et funktionelt programmeringssprog [lukket]

Da du vil have et praktisk   sprog:

Bemærk, at Haskell og Lisp bruges mere end de andre i industrien, selvom der har været en del interesse for nylig i Clojure og F #.

Men se hvad der sker, når vi tilføjer skema til blandingen:

Hmm, ligner det ikke så meget et akademisk sprog nu, gør det?

Faktisk er ovenstående graf sandsynligvis en løgn; ordet “skema” kan vises i hjælp ønskede annoncer i andre sammenhænge udover programmeringssprog. 🙂

Så her er en anden graf, der sandsynligvis (lidt) er mere repræsentativ:

Hvis du vil udforske en virkelig kick-ass dialekt af Scheme, skal du kigge på Ketsjere.

Kommentarer

• Wow, dejligt indlæg. Racket er nøjagtigt hvad jeg ' bruger ved hjælp af … PLT-Scheme var dens navn, da jeg begyndte at lære det. Den røde linje i den sidste grafik generer mig. Tænkte aldrig, at ordningen kunne bruges så meget. Og Clojure ser helt sikkert ud til at tage fart. Hmm …
• @M. Joanis: Tag de sidste to grafer med et saltkorn; trappekastet og volatiliteten i den sidste graf antyder, at der ikke er mange datapunkter i grafen, selvom det indikerer, at nogen mener, at sprogene er værd at betale for.
• @Robert Harvey, hvad ændret fra den anden til den tredje graf?
• @Geoffrey: Se på billedteksterne; Jeg tilføjede ordet " udvikler " til søgeudtryk.
• Bemærk, at Haskell og Lisp også er homonymer og at Faktisk ' s data ikke generaliserer til resten af verden. ITJobsWatch viser 79 Scala-job, 55 F #, 47 Haskell, 30 Lisp og 7 Clojure-job.

Hvis du vil lære funktionel programmering, kan du bedre tjene til at lære Haskell først og derefter bruge det sprog, du ønsker. Du kan lære funktionel programmering ved hjælp af de andre sprog, men de giver stadig mulighed for bydende og objektorienteret kode. Hvis du skriver et rigtigt program i Haskell, lærer du funktionel programmering hurtigere, fordi de andre paradigmer ikke er tilgængelige til at falde tilbage på.

Når du har skrevet dit Haskell-program, har du værktøjer som monader og teknikker. som punktfri kodning for at bringe til det sprog, du vælger. Begreberne synes at kortlægge særligt godt til skema.

Kommentarer

• Jeg tror, du ' har ret i at vælge et rent funktionelt sprog først. Jeg ville være meget interesseret i at se en ordning af funktionelle sprog efter renhed.
• @ M. Joanis: af de sprog, der er anført i dit spørgsmål, vil jeg sige, at Haskell er den reneste, efterfulgt af Clojure, F # og Lisp.

Hvis du faktisk kunne implementere et rimeligt komplekst system i skema, ville du være ret ønskeligt hos virksomheder, hvor du sandsynligvis vil arbejde. Tidligere i min karriere stødte jeg på nogle studerende, der havde udført en hel del arbejde i ordningen, og den eneste gang det var en ulempe var, da de ikke kunne forklare deres arbejde eller faktisk ikke forstod det godt nok til at implementere grundlæggende data strukturer og algoritmer inden for en rimelig tid. Jeg lod altid kandidater besvare sådanne spørgsmål på deres foretrukne sprog. Jeg stødte på nogle mennesker, der troede, at de var bedst til Scheme, der formåede at kæmpe en hel del med ting, der skulle være lette, som at tilføje et element til en sammenkædet liste, hvilket mystificerede mig.

Men hvis du var i stand til at “få” ordningen godt nok til at skrive selv en gennemsnitlig webapp, ville det højst være et godt salgsargument seriøse softwarevirksomheder.

Hvis du interviewede i en “blub” -butik, og udviklerne bare syntes, du var underlig på grund af din dygtighed i Scheme eller Haskell eller F #, ville du sandsynligvis ikke ønsker at arbejde der. I de fleste tilfælde får kompetente udviklere deres valg af koncerter, så ikke sved “praktisk”, medmindre de eneste muligheder, du kan forestille dig i din fremtid, er corporate. Arbejd med at være kompetente, fleksible og nedbryde problemer.

College handler ikke om praktisk funktion. Det handler om at skabe et sikkert miljø at udforske og lære. Det er faktisk nyttigt, selvom du ender med at skrive almindelig software resten af din karriere.

Når det er sagt, det gør jeg ikke ” Du kan ikke se, hvorfor du så hurtigt vil begrænse dig til et af disse valg. Du kan let få en fornemmelse af alle fire sprog på cirka 4 uger, og vælg derefter et, der skal koncentrere dig om, der passer bedst til dine nuværende luner. Så gå tilbage til en anden af dine muligheder og prøv at implementere noget lignende. Gå videre til noget mere komplekst, og overvej dine muligheder igen. Eksperimentering er god. Medmindre du prøver at tjene til livets ophold næste måned, behøver du ikke blive specialist endnu.

Jeg har skrevet nogle i Scheme, F #, Emacs Lisp og Common Lisp og har læst mindst lidt af Haskell, i det mindste lejlighedsvis i løbet af de sidste par år. Jeg kan ikke sige, at jeg er ekspert i nogen af dem, men hver udflugt til disse sprog har haft gavn af mig på alle de andre sprog, jeg arbejder professionelt (C #, Java, Ruby og lejlighedsvis Boo, Perl og Python). Nysgerrighed vil skabe dig en mere varig og tilfredsstillende karriere end noget andet.

Kommentarer

• " Nysgerrighed vil bygge dig en mere varig og tilfredsstillende karriere end noget andet. " Denne erklæring er meget inspirerende. Du ' har ret. Jeg ' jeg er for hurtig. Jeg har altid lyst til, at det hele vil tage for meget tid at lære … Hvis jeg kunne gå 12 år tilbage, da jeg startede, vidste jeg ' ikke at spilde alle mine tid på VB og C ++. Jeg har lyst til, at disse år var temmelig dårligt spildte. Jeg var ikke ' t nysgerrig nok. Jeg ville kode ting. Det var nok at bruge de sprog, jeg kendte. Jeg troede på det tidspunkt, at jeg vidste en hel del, men at det så forfærdeligt slet ikke var '.

Jeg dykkede ned i Haskell et stykke tid, men konklusionen, jeg kom til, var, at det var lidt for akademisk. Det var meget svært at gøre noget praktisk. På et rent funktionelt sprog passer ting som IO ikke helt ind i modellen, så du er nødt til at beskæftige dig med monader. Jeg besluttede, at jeg skulle bruge en enorm tid på at være knap kompetent, så jeg gik videre .

Jeg lavede Scheme på college. Kan lyde trivielt, men alle forældrene er virkelig distraherende / irriterende. Svært at vende tilbage til det efter at have brugt sprog som Python.

For nylig har jeg har udforsket F #. Det er funktionelt, men kan også være bydende nødvendigt og objektorienteret, når du vil. Dette sammen med at være i stand til at bruge ethvert .NET-bibliotek gør det muligt let at blande dine rene funktionelle dele med mere praktiske ting som GUIer, IO og netværk. Du kan få en enkeltstående version af F #.

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

Kommentarer

• Det faktum, at F # og Clojure ikke er rent funktionelle, spiller en vigtig rolle i deres favør. Måske kan F # være min indgang i .Net familie en dag …
• @MJoanis, du angav omkostninger som et point mod F #, men som Erik påpeger, kan du få det helt gratis.
• Hvis jeg læser vilkårene rigtigt, får du stort set det gratis på den betingelse ikke at bruge det (eller købe licenser). Men jeg forstår, at det stadig kan være en meget god ting at lære, hvis jeg ender i et firma, der bruger Visual Studio.Jeg ' Jeg vil sandsynligvis prøve, når jeg ' fungerer med et mere gratis funktionelt programmeringssprog.
• @M. Joanis: Nej, F # er endda open source, og du kan prøve at køre på Mono på andre platforme.
• Måske har tiderne ændret sig siden 2010, men som en person, der begyndte at lære haskell i de sidste par måneder, har jeg don ' t synes det er svært at gøre IO i haskell. For grundlæggende ting skal du bare lære nogle nye do-syntaks At få den rigtige grundlæggende forståelse tager et par uger toppe, men jeg ser virkelig ikke ' hvad fuzz handler om monader. Jeg tror ikke ' at de var sværere at lære end klasser, forekomster, statiske medlemmer og alle de andre statsrelaterede jazz i OOP.

Jeg evaluerede alle de vigtigste funktionelle sprog et år eller to tilbage fra perspektivet om at have et praktisk, funktionelt programmeringssprog til generelle formål.

Jeg endte med at vælge Clojure , hvilket efterfølgende har vist sig at være et glimrende valg.

Generelt set var hovedårsagerne:

• Biblioteksøkosystem – for at et sprog skal være nyttigt, skal du have adgang til gode biblioteker. At være på JVM betyder, at du har let adgang til det største open source-bibliotek og værktøjsøkosystem, så det var en no-brainer fra et pragmatisk perspektiv at gå efter et JVM-sprog. Scala scorede også højt her.

• Makro-metaprogrammering – Dette aspekt af Lisp appellerede altid til mig, især da jeg forventede at lave en hel del kodegenerering. Jeg har meget værdsat argumenterne i Paul Grahams korte essay Beating The Averages “. De forskellige Lisps scorede alle stærkt her.

• Performance var “god nok “- Clojure er altid kompileret og får fordelene ved JVM JIT optimiser og fremragende GC. Som altid er der noget overhead ved at bruge et funktionelt sprog, men med Clojure var det klart, at du hver kan tæt på Java-hastighed med en smule indsats (Clojure understøtter Java-primitiver og valgfri statisk skrivning til de situationer, hvor du har brug for det). Mit skøn er, at Clojure er 2-5x langsommere end hvad du kunne opnå med optimeret Java- eller C ++ -kode, hvilket er i overensstemmelse med det, du ser i mangelfulde benchmarks , og med tiden forventer jeg, at forskellen bliver mindre. Det er også let nok at bare skrive særligt præstationsfølsom kode i ren Java og kalde den fra Clojure.

• Samtidighed – Clojure har en temmelig unik og kraftfuld tilgang til samtidighed, især for stærkt multi-core samtidighed. Det er lidt svært at forklare, men denne video er fremragende til at give en smag af principperne. Jeg synes, at Clojure i øjeblikket har det bedste svar på det vanskelige spørgsmål “hvordan skal du administrere delt, samtidig og ændret tilstand i et funktionelt programmeringssprog?”.

• Sprogdesign – Clojure er IMO et meget gennemtænkt sprogdesign. Eksempler er at have vektor [] og kort {} bogstaver ud over de almindelige Lisp parenteser, brug af uforanderlige vedvarende datastrukturer, understøtte dovenskab i hele sproget via sekvensabstraktionen og give programmøren en række ortogonale funktioner til at løse forskellige problemer . Se abstraktionskunsten og simple gjort let .

• Community – altid subjektivt, men jeg kunne godt lide det, jeg så i Clojure-samfundet. Holdningen var meget hjælpsom, konstruktiv og pragmatisk. Der er en stærk “få ting gjort” -vægt, hvilket muligvis afspejler det faktum, at mange Clojure-mennesker (inklusive Rich Hickey selv) kommer fra en baggrund i at opbygge komplekse virksomhedssystemer. Det faktum, at Clojure-samfundet også har stærke forbindelser til Java-samfundet, var vigtigt for at overbevise mig om, at Clojure ikke ville risikere at sætte sig fast i en “niche”.

Hvis jeg skulle nævne et par mindre ulemper ved Clojure, ville disse være:

• Dynamisk skrivning – ofte er dette en fordel med hensyn til produktivitet, men i gennemsnit tror jeg, at jeg ville bytte dette til stærkere typekontrol og inferens. Dette mildnes for det meste ved at have en god automatiseret testpakke, men hvis du kan lide dine typer statisk valideret af compileren, kan Haskell eller Scala måske være mere din kop te.

• Forkant – Clojure udvikler sig meget hurtigt og der er “sa der foregår meget innovation – ulempen ved dette er, at der er en masse eksperimenter, nogle biblioteker og værktøjer er stadig umodne, og der er lejlighedsvise ændringer mellem Clojure-store versioner, som du har brug for at holde øje med.

Alt i alt tror jeg dog ikke, du kan gå galt med Clojure, hvis du vil have et fremragende og pragmatisk moderne funktionelt sprog!

Kommentarer

• Tak! Fantastisk indlæg! Jeg overvejede lige nu i disse dage at bruge det til et virksomhedsinternt projekt, der vil være stærkt baseret på træer og rekursivitet. Derudover har vi en hel del Java-kode her omkring, som vi kan genbruge med Clojure.

Det ser ud som om, du har lavet dit hjemmearbejde, så du ved det sandsynligvis allerede, men ordningen er en dialekt af Lisp, ligesom Common Lisp er. Hvis du kan lide mange ting ved ordningen, men ikke kan lide dens akademiske natur, så prøv Common Lisp. I henhold til TIOBE-indekset er det det 13. mest populære sprog vs skema på position 26.

Få af de sprog, du har nævnte vises på de jobbeskrivelser, jeg har set for nylig, selvom det måske bare er mit lille prøvesæt. Jeg vil personligt lære Haskell, selvom jeg ikke forventer at bruge dette sprog direkte i mit job. Begreberne funktionel programmering er mere værdifulde for fremtidige programdesign end selve sprogets direkte salgbarhed.

Kommentarer

• Tak for TIOBE link, det er en interessant reference. Jeg antager, at du vælger Haskell for sin renhed i form af funktionel programmering?
• @ M.Joanis: Temmelig meget, selvom jeg ' tænker på senere at afhente Lisp også. Se programmers.stackexchange.com/questions/18838/…
• Det valgte svar gør en masse fornuft. Renhed ser ud til at være vejen at gå, indtil jeg virkelig har forstået hele det funktionelle paradigme.