Kommentarer
- Og F # og Clojure.
Svar
Jeg foreslår at lære begge dele, Haskell først, derefter Common Lisp. Min erfaring med Haskell var, at den statiske typografi i starten syntes at være en begrænsende irritation, men når jeg først var vant til det, bemærkede jeg, at de fleste af mine typefejl havde logiske fejl, der gemte sig bag dem. Når du kommer til dette punkt og den næste milepæl, som er at lære at tænke i typer og definere dine egne typer som et middel til at udtrykke din løsning, vil du være klar til Common Lisp.
Med Common Lisp, du kan tilføje monader, karry og alt, hvad du kunne lide fra Haskell, men du får også flere arv som Frank Shearar nævnt, og generiske funktioner med flere forsendelser og et avanceret system til undtagelseshåndtering.
Så hvorfor ikke kun lære Common Lisp først? Kommer fra en proceduremæssig og OOP-baggrund har min erfaring været, at jeg ikke rigtig forstod funktionel programmering, før jeg udelukkende måtte bruge den. Når funktionel programmering er behagelig, kan du tilføje resten af de værktøjer, som Common Lisp stiller til rådighed, og bruge det værktøj, der er bedst til den aktuelle opgave.
Kommentarer
- Jeg tror, du har spikret det – hvad der gør Haskell og Smalltalk så nyttige til læring er deres renhed.
- I er enig med renheden gør det lettere at lære et sprog. Jeg kunne ikke ' ikke forstå det funktionelle sprog i sig selv med LISP, fordi alt er muligt på sproget, og jeg har for meget OO-baggrund. Men i Haskell er der ingen sådanne begreber, der forstyrrer læring.
- Det ' er sjovt, jeg ' har havde den modsatte oplevelse. Jeg hentede hovedpunkterne i funktionel programmering gennem Scheme, mit første sprog. Jeg hacker lejlighedsvis i Haskell, og jeg finder uundgåeligt, at jeg er nødt til at genlære 90% + af de ting, som jeg vidste, når jeg forlader Haskell et stykke tid. Når det er sagt, er Haskell et utroligt rigt sprog med en enorm mængde at lære dig (meget med magt.) Typer Typer Typer Typer! Følg typerne!
Svar
OG tak.
Haskell lærer dig det reneste af FP, så vidt jeg i det mindste ved, ligesom Smalltalk lærer det reneste af OO. (Jeg nævner dette for ikke at antyde, at OO og FP ikke kan gifte sig, men fordi begge disse sprog er “perle” -sprog – et kerneidee taget til ekstremer.)
Lisp er virkelig en sprogfamilie, så jeg vil tale om Common Lisp, fordi det er det særlige medlem af familien, jeg bruger.
Lisp har stadig meget at lære dig:
- Det er multiparadigm, så som dsimcha påpeger det “viser dig hvordan man integrerer FP med andre paradigmer.
- Lisp lærer dig, at “kode-er-data, data-er-kode”, for eksempel gennem dens makroer.
- CLOS er en meget interessant mærke af OO, med flere arv, der fungerer, og generiske funktioner.
Svar
Haskell og Lisp er to helt forskellige dyr.
Haskell er en slags “ren funktionel programmering i et elfenbenstårn”
Lisp er en slags “kode-er-data / data-er-kode / lav dine egne sprogkonstruktioner”. Du kan manipulere din kode på den måde, du kan forestille dig.
De er meget forskellige. Begge deler det “funktionelle programmerings” -aspekt, men det er virkelig et lille, lille fælles punkt i forhold til deres forskelle. Prøv dem bare, så ser du, hvor forskellige de er!
Kommentarer
- +1: Godt punkt. Jeg kender nogle Haskell og nogle Lisp. Selvom jeg ikke er ekspert i nogen af dem, tror jeg, du har ret i, at de er meget forskellige. I Haskell dig har ikke tanken om at bruge data som kode. I Lisp har du ikke (AFAIK) mønstermatchning. Sandsynligvis er listen (!) over forskelle længere.
Svar
Læring af Lisp senere giver dig mulighed for at tilpasse Emacs, der uden tvivl er den mest avancerede teksteditor til rådighed. Du kan ikke gøre det i Haskell.
Kommentarer
- [Skærper parenteserne]
- Måske kan nogen skrive en teksteditor til det. Jeg hører, at Emacs-operativsystemet ikke ' ikke kommer med et. (Jeg barn. Jeg ved, du kan få Viper-tilstand. 🙂
- Der er faktisk en Emacs-klon kaldet Yi, der bruger Haskell på nøjagtig samme måde som Emacs bruger Lisp.Faktisk sammenlignet med (GNU) Emacs er Yi endnu renere, fordi dens kerne også er skrevet i Haskell, mens Emacs-kerner generelt ikke har tendens til at blive skrevet i Lisp. GNU Emacs ' kernen er skrevet i C, JEmacs ' er f.eks. Skrevet i Java.
- @J ö rg, hvis det er en delvis genimplementering i stedet for en fuld klon af GNU Emacs eller XEmacs, er det ikke den samme ting. Svarende til at sammenligne Word med Wordpad eller Notepad.
- @Thorbj ø rn Ravn Andersen: Ja, men ikke helt det dårligt. 🙂
Svar
Den største fordel, jeg ser ved at lære Lisp, er at lære at integrere FP i en reel -verdenorienteret multiparadigm-sprog, snarere end kun at lære det i sammenhæng med et akademisk sprog, der understreger renhed.
Kommentarer
- Jeg tror du vil have en " Haskell vs Lisp " krig!
- Haskell er et akademisk sprog, der understreger renhed … og mange mennesker bruger den i den virkelige verden. Smalltalk ' er også i den lejr.
- Mange mennesker bruger Haskell i den virkelige verden?
- @Jon Harrop: Nå, jeg bruger Haskell i den virkelige verden (og det fungerer rigtig fint til visse applikationer), måske er jeg en af de få (?)
Svar
Jeg kommer også fra en C / C ++ / Python-baggrund og har prøvet FP et par gange i de sidste par år. Oprindeligt kiggede jeg på Haskell og kunne ikke lave hoved eller hale af det, så prøvede jeg Ocaml, men kom ikke meget længere med det. Endelig begyndte jeg at høre gode ting om Scala, prøvede det og fandt ud af, at det passede mig meget godt (jeg havde også gjort lidt Java tidligere), til det punkt, at efter et år med så dabbling i Scala (og afsendelse af 161 Project Euler har problemer med det), Haskell ser ud til at give meget mere mening. Faktisk bestilte jeg netop et par bøger om Haskell og vil give det endnu en gang, selvom dette i vid udstrækning er motiveret af eksistensen af Scalaz.
Så jeg fandt brug af et multiparadigmsprog (dvs. Scala, men Lisp ville sandsynligvis også passe regningen) en god vej ind i FP. Men hvis du er glad for at dykke ned i Haskell (det var jeg ikke), gå efter det.
Kommentarer
- Interessant at du kom længere med Scala end OCaml. Hvordan kommer det?
- @Jon: Godt spørgsmål; svært at sige. Måske var jeg bare ikke ' t klar til " at komme ind i " funktionel på det tidspunkt. Måske tilfældigvis fandt jeg en Scala-tutorial, der blev sat på det rigtige niveau. Måske gjorde Scala ' s C / C ++ / Java-slægt det bare lidt mindre fremmed. I betragtning af at et rationelt væddemål i disse dage ville være på F # snarere end Scala, vil jeg ' sandsynligvis besøge OCaml-domænet på et eller andet tidspunkt, selvom da jeg dumler i disse ting bare for den store glæde ved når jeg går ind i en anden " programmeringstænkning " til min C ++ dayjob, har jeg en pervers tilbøjelighed til at prøve Haskell igen igen.
- Glat bevægende tilgang 🙂
Svar
Jeg kom oprindeligt fra en C / C ++ / Ruby baggrund og jeg brugte FP-koncepter i Ruby, når jeg kunne. Stat sårede bare min hjerne. En af mine venner kaldte mig op en dag, og han bad mig skrive noget i Haskell (mit første – og forhåbentlig ikke sidste – Haskell-job!). Jeg lærte hurtigt sproget og kastede noget sammen, der fungerede. Det var ikke smukt eller noget, men det fungerede.
Jeg tog en måneds pause fra Haskell, fordi jeg ikke havde noget at bruge det til. Men da jeg besluttede at skulle skrive min egen blogsoftware, brugte jeg Haskell ( https://symer.io ). Haskell er virkelig sejt, fordi du kan opdele et problem i dele og implementere disse dele forskelligt baseret på input. Haskell håndterer også fiasko ekstremt godt gennem intelligent boksning af værdier. Der er så mange værktøjer til at arbejde med disse felter, at du simpelthen glemmer, at de findes.
Min erfaring med lisp (Scheme) var fuldstændig negativ. Ikke kun manglede sproget disse intelligente, enkle værktøjer, det føltes lige så farligt løs som Ruby eller JavaScript. Det var en frygtelig oplevelse, og den tilbyder intet nyt ud over Ruby eller Python.
C ++ kan ikke holde et lys mod Haskell uden for hukommelsesadministration. Haskell er lige så hurtig (hvis ikke hurtigere), betydeligt mere kortfattet og meget mere sikker. Men Haskells sikkerhed kommer aldrig ind vejen.
TL; TR Haskell er et frisk pust, og Lisp er en lidt mere funktionel Ruby.