Velge et funksjonelt programmeringsspråk [lukket]

Siden du vil ha et praktisk   språk:

Legg merke til at Haskell og Lisp brukes mer enn de andre i industrien, selv om det har vært litt interessert i Clojure og F #.

Men se hva som skjer når vi legger til Scheme i blandingen:

Hmm, ser det ikke så mye ut som et akademisk språk, ikke sant?

Grafen ovenfor er sannsynligvis en løgn; ordet «skjema» kan vises i hjelp ønsket annonser i andre sammenhenger foruten programmeringsspråk. 🙂

Så her er en annen graf som sannsynligvis er (litt) mer representativ:

Hvis du ønsker å utforske en virkelig kick-ass dialekt av Scheme, ta en titt på Racket.

Kommentarer

• Wow, fint innlegg. Racket er akkurat det jeg ' bruker … PLT-Scheme het det da jeg begynte å lære det. Den røde linjen i den siste grafikken plager meg. Aldri trodd at ordningen kunne brukes så mye. Og Clojure ser ut til å ta av. Hmm …
• @M. Joanis: Ta de to siste grafene med saltkorn; trappens utseende og volatiliteten til den siste grafen antyder at det ikke er mange datapunkter i grafen, selv om det indikerer at noen mener språkene er verdt å betale for.
• @Robert Harvey, hva endret fra den andre til den tredje grafen?
• @Geoffrey: Se på bildetekstene; Jeg la til ordet " utvikler " i søkeordene.
• Merk at Haskell og Lisp også er homonymer og at ' data faktisk ikke generaliserer til resten av verden. ITJobsWatch lister 79 Scala-jobber, 55 F #, 47 Haskell, 30 Lisp og 7 Clojure-jobber.

Hvis du vil lære funksjonell programmering, kan du tjene bedre på å lære Haskell først, og bruk deretter hvilket språk du vil. Du kan lære funksjonell programmering ved hjelp av de andre språkene, men de tillater fortsatt imperativ og objektorientert kode. Hvis du skriver et ekte program i Haskell, vil du lære funksjonell programmering raskere fordi de andre paradigmene ikke vil være tilgjengelige å falle tilbake på.

Etter å ha skrevet Haskell-programmet ditt, vil du ha verktøy som monader og teknikker. som punktfri koding for å bringe til det språket du ønsker. Konseptene ser ut til å tilordnes spesielt godt til skjemaet.

Kommentarer

• Jeg tror du ' har rett i å velge et rent funksjonelt språk først. Jeg ville være veldig interessert i å se en ordning av funksjonelle språk etter renhet.
• @ M. Joanis: of språkene som er oppført i spørsmålet ditt, vil jeg si at Haskell er den reneste, etterfulgt av Clojure, F # og Lisp.

Hvis du klarte å implementere et rimelig komplekst system i skjemaet, ville du være ganske ønskelig hos selskaper der du sannsynligvis vil jobbe. Tidligere i karrieren kjørte jeg på noen studenter som hadde gjort en god del arbeid i skjemaet, og den eneste gangen det var en ulempe var da de ikke klarte å forklare arbeidet sitt eller ikke forsto det godt nok til å implementere grunnleggende data strukturer og algoritmer innen rimelig tid. Jeg lar alltid kandidatene svare på slike spørsmål på deres foretrukne språk. Jeg fikk noen mennesker som mente at de var best på Scheme som klarte å slite ganske mye med ting som skulle være enkle, som å legge til et element i en lenket liste, noe som mystifiserte meg.

Men hvis du var i stand til å «få» ordningen godt nok til å skrive til og med en gjennomsnittlig webapp, ville det høyst være et ganske godt salgsargument seriøse programvareselskaper.

Hvis du intervjuet i en «blub» -butikk og utviklerne bare syntes du var rar på grunn av dyktigheten din i Scheme eller Haskell eller F #, ville du sannsynligvis ikke vil jobbe der. I de fleste tilfeller får kompetente utviklere valg av spillejobber, så ikke svett «praktisk» med mindre de eneste alternativene du kan forestille deg i fremtiden din er bedrift. Arbeid med å være kompetente, fleksible og bryte ned problemer.

College handler ikke om praktisk bruk. Det handler om å skape et trygt miljø å utforske og lære. Det er faktisk nyttig, selv om du ender opp med å skrive vanlig programvare for resten av karrieren.

Når det er sagt, det gjør jeg ikke » t se hvorfor du vil begrense deg til bare ett av disse valgene så snart. Du kan lett få en følelse av alle de fire språkene på omtrent fire uker, og deretter velge ett for å konsentrere deg om det som passer best med dine nåværende innfall. gå tilbake til et annet av alternativene dine og prøv å implementere noe lignende. Gå videre til noe mer komplekst, og vurder alternativene dine på nytt. Eksperimentering er bra. Med mindre du prøver å tjene til livets opphold neste måned, trenger du ikke bli spesialist ennå.

Jeg har skrevet noen i Scheme, F #, Emacs Lisp og Common Lisp, og lest i det minste litt av Haskell, i det minste noen ganger de siste årene. Jeg kan ikke si at jeg er ekspert på noen av dem, men hver utflukt til disse språkene har hatt nytte av meg på alle de andre språkene jeg jobber profesjonelt (C #, Java, Ruby og noen ganger Boo, Perl og Python). Nysgjerrighet vil gi deg en mer varig, oppfyllende karriere enn noe annet.

Kommentarer

• " Nysgjerrighet vil bygge deg en mer varig, oppfyllende karriere enn noe annet. " Denne uttalelsen er veldig inspirerende. Du ' har rett. Jeg ' jeg er for skyndt. Jeg føler alltid at det hele vil ta for mye tid å lære … Hvis jeg kunne gå 12 år tilbake, da jeg begynte, ville jeg ' ikke kaste bort alle mine tid på VB og C ++. Jeg føler at disse årene var ganske bortkastet. Jeg var ikke ' ikke nysgjerrig nok. Jeg ville kode ting. Å bruke språkene jeg kjente var nok. Jeg trodde på det tidspunktet at jeg visste ganske mye, men at det så fryktelig ikke var ' t i det hele tatt.

Jeg dykket inn i Haskell en stund, men konklusjonen jeg kom til var at det var litt for akademisk. Det var veldig vanskelig å gjøre noe praktisk. På et rent funksjonelt språk passer ting som IO ikke helt inn i modellen, så du må takle monader. Jeg bestemte meg for at jeg måtte legge inn en enorm tid for å være knapt kompetent, så jeg gikk videre .

Jeg gjorde Scheme på college. Kan høres trivielt ut, men alle foreldrene er forstyrrende / irriterende. Vanskelig å gå tilbake til det etter å ha brukt språk som Python.

Nylig har jeg har utforsket F #. Den er funksjonell, men kan også være viktig og objektorientert når du vil. Dette sammen med å kunne bruke .NET-biblioteker, gjør det mulig å enkelt blande dine rene funksjonelle deler med mer praktiske ting som GUI-er, IO og nettverk. Du kan få en frittstående versjon av 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 funksjonelle spiller en viktig rolle i deres favør. Kanskje F # kan være mitt inngangspunkt i .Net-familien en dag …
• @MJoanis, du angav kostnad som et poeng mot F #, men som Erik påpeker, kan du få det helt gratis.
• Hvis jeg leser ordene riktig, får du det i utgangspunktet gratis under tilstanden av å ikke bruke den (eller kjøpe lisenser). Men jeg forstår at det fortsatt kan være veldig bra å lære i tilfelle jeg havner i et selskap som bruker Visual Studio.Jeg ' Jeg vil sannsynligvis prøve det når jeg ' fungerer med et mer gratis funksjonelt programmeringsspråk.
• @M. Joanis: Nei, F # er til og med åpen kildekode, og du kan prøve å løpe inn på Mono på andre plattformer.
• Kanskje tidene har endret seg siden 2010, men som noen som begynte å lære haskell de siste månedene, don ' t synes det er vanskelig å gjøre IO i haskell. For grunnleggende ting trenger du bare å lære noen nye do-syntaks Å få den virkelige grunnleggende forståelsen tar noen uker topper, men jeg ser virkelig ikke ' hva fuzz handler om monader. Jeg tror ikke ' de var vanskeligere å lære enn klasser, forekomster, statiske medlemmer og all den andre statsrelaterte jazz i OOP.

Jeg evaluerte alle de viktigste funksjonelle språkene et år eller to tilbake, fra perspektivet til å ønske et praktisk, generelt funksjonelt programmeringsspråk.

Jeg endte med å plukke Clojure , som senere har vist seg å være et utmerket valg.

Generelt sett var hovedårsakene:

• Bibliotekets økosystem – for at et språk skal være nyttig, trenger du tilgang til gode biblioteker. Å være på JVM betyr at du har lett tilgang til det største open source-biblioteket og verktøyøkosystemet, så det å gå etter et JVM-språk var en no-brainer fra et pragmatisk perspektiv. Scala scoret også høyt her.

• Makro-metaprogrammering – Dette aspektet av Lisp appellerte alltid til meg, spesielt siden jeg forventet å gjøre ganske mye kodegenerering. Jeg har satt stor pris på argumentene i Paul Grahams korte essay Beating The Averages «. De forskjellige Lisps scoret alle sterkt her.

• Ytelse var «god nok «- Clojure er alltid kompilert og får fordelene med JVM JIT-optimalisereren og utmerket GC. Som alltid er det noe overhead i å bruke et funksjonelt språk, men med Clojure var det klart at du hver kan nærme Java-hastighet med litt innsats (Clojure støtter Java-primitiver og valgfri statisk skriving for de situasjonene der du trenger det). Mitt estimat er at Clojure er ballpark 2-5 ganger tregere enn hva du kan oppnå med optimalisert Java- eller C ++ -kode, noe som er i samsvar med det du ser i feil referanseverdier , og over tid forventer jeg at gapet vil reduseres ytterligere. Det er også enkelt å bare skrive spesielt ytelsesfølsom kode i ren Java og kalle den fra Clojure.

• Samtidighet – Clojure har en ganske unik og kraftig tilnærming til samtidighet, spesielt for multikjerne samtidighet. Det er litt vanskelig å forklare, men denne videoen er utmerket for å gi en smak av prinsippene. Jeg tror Clojure for øyeblikket har det beste svaret på det vanskelige spørsmålet «hvordan skal du håndtere delt, samtidig og muterbar tilstand i et funksjonelt programmeringsspråk?».

• Språkdesign – Clojure er IMO et veldig gjennomtenkt språkdesign. Eksempler er å ha vektor [] og kart {} bokstaver i tillegg til de vanlige Lisp parentesene, bruk av uforanderlige vedvarende datastrukturer, støtte latskap gjennom hele språket via sekvensabstrahering, og gi programmereren en rekke ortogonale funksjoner for å løse forskjellige problemer . Se abstraksjonskunsten og enkelt gjort enkelt .

• Community – alltid subjektiv, men jeg likte det jeg så i Clojure-samfunnet. Holdningen var veldig hjelpsom, konstruktiv og pragmatisk. Det er en sterk «få ting gjort» vektlegging, muligens gjenspeiler det faktum at mange Clojure mennesker (inkludert Rich Hickey selv) kommer fra en bakgrunn for å bygge komplekse virksomhetssystemer. Det at Clojure-samfunnet også har sterke koblinger til Java-samfunnet, var viktig for å overbevise meg om at Clojure ikke ville risikere å sette seg fast i en «nisje».

Hvis jeg måtte nevne et par mindre ulemper ved Clojure, ville disse være:

• Dynamisk skriving – ofte er dette en fordel når det gjelder produktivitet, men i gjennomsnitt tror jeg at jeg vil bytte dette for sterkere typekontroll og inferens. For det meste blir dette redusert ved å ha en god automatisert testpakke, men hvis du liker typene dine statisk validert av kompilatoren, kan Haskell eller Scala være mer din kopp te.

• Forkant – Clojure utvikler seg veldig raskt og der «sa mye innovasjon pågår – ulempen med dette er at det er mye eksperimentering, noen biblioteker og verktøy er fremdeles umodne, og det er tidvis store endringer mellom store versjoner i Clojure som du trenger å holde øye med.

Alt i alt tror jeg ikke du kan gå galt med Clojure hvis du vil ha et utmerket og pragmatisk moderne funksjonsspråk!

Kommentarer

• Takk! Flott innlegg! Jeg nettopp, i disse dager, vurderte å bruke det til et internt selskapsprosjekt som vil være sterkt basert på trær og rekursivitet. I tillegg har vi ganske mye Java-kode her som vi kan bruke på nytt med Clojure.

Det ser ut som om du har gjort leksene dine, så du vet sannsynligvis allerede dette, men Scheme er en dialekt av Lisp akkurat som Common Lisp er. Hvis du liker mange ting om Scheme, men ikke liker dens akademiske natur, kan du prøve Common Lisp. I følge TIOBE-indeksen er det det 13. mest populære språket mot ordningen på posisjon 26.

Få av språkene du har nevnte vises på stillingsbeskrivelsene jeg har sett nylig, selv om det bare kan være det lille prøvesettet mitt. Jeg vil personlig lære Haskell, selv om jeg ikke forventer å bruke det språket direkte i jobben min. Begrepene funksjonell programmering er mer verdifulle for meg for fremtidige programutforminger enn selve språkets direkte salgbarhet.

Kommentarer

• Takk for TIOBE link, det er en interessant referanse. Jeg antar at du velger Haskell for sin renhet når det gjelder funksjonell programmering?
• @ M.Joanis: Ganske mye, selv om jeg ' tenker å senere plukke opp Lisp også. Se programmers.stackexchange.com/questions/18838/…
• Det valgte svaret gjør mye fornuft. Renhet ser ut til å være veien å gå til jeg virkelig har forstått hele funksjonelle paradigmeting.