Schema vs Haskell per un'introduzione alla programmazione funzionale?


36

Sono a mio agio con la programmazione in C e C # ed esplorerò C ++ in futuro. Potrei essere interessato a esplorare la programmazione funzionale come un diverso paradigma di programmazione. Lo sto facendo per divertimento, il mio lavoro non prevede la programmazione informatica e sono in qualche modo ispirato dall'uso della programmazione funzionale, insegnata abbastanza presto, nei corsi di informatica al college. Il calcolo lambda è certamente al di là delle mie capacità matematiche, ma penso di poter gestire la programmazione funzionale.

Quale di Haskell o Scheme servirebbe da buona introduzione alla programmazione funzionale? Uso emacs come editor di testo e vorrei essere in grado di configurarlo più facilmente in futuro, il che implicherebbe l'apprendimento di Emacs Lisp. La mia comprensione, tuttavia, è che Emacs Lisp è abbastanza diverso da Scheme ed è anche più procedurale rispetto a funzionale.

Probabilmente userei il libro "The Little Schemer", che ho già acquistato, se inseguo Scheme (mi sembra un po 'strano dal mio limitato sfogliarlo). O userei "Impara un Haskell per il bene" se inseguo Haskell. Vorrei anche guardare i video di Introduzione a Haskell del dott. Erik Meijer su Channel 9.

Qualche suggerimento, feedback o input apprezzato.

Grazie.

PS BTW Ho anche accesso a F # poiché ho Visual Studio 2010 che utilizzo per lo sviluppo di C #, ma non credo che dovrebbe essere il mio criterio principale per selezionare una lingua.


3
Non dimenticareReal World Haskell
alternativa il

15
Piccolo commento laterale: il calcolo lambda è un sistema straordinariamente semplice; la cosa bella non è che è complessa, ma il contrario; che puoi esprimere tutto ciò che vuoi in un sistema così semplice. Inizia con un linguaggio di programmazione; ora butta TUTTO tranne i riferimenti alle variabili, le definizioni delle funzioni e le chiamate delle funzioni. Ecco! Calcolo lambda.


9
Posso insegnarti il ​​calcolo lambda in cinque minuti. Ora, comprendere le conseguenze di ciò che hai appena imparato richiede una vita. :)

5
Ho scelto Haskell piuttosto che Scheme principalmente perché non ha così tante parentesi dannate!
Joey Adams,

Risposte:


27

Consiglierei OCaml.

Dal mio punto di vista personale, la base principale delle moderne programmazioni funzionali¹ sono le funzioni di ordine superiore, un sistema di tipo statico, tipi di dati algebrici e adattamento dei modelli.

Tra uno Schema, un ML e un Haskell, sceglierei il ML perché penso che sia il più rilevante per questa definizione. Lo schema non ha una tipizzazione statica (c'è Typed Racket, ma non è per i principianti dello schema), e Haskell ha troppe altre cose (monadi, valutazione pigra ...) che, sebbene interessanti, possono distogliere l'attenzione dalle basi importanti .

SML e OCaml sono ugualmente interessanti; Sono più abituato a OCaml, e ha una sensazione più "pratica" che è piacevole (ma se vuoi davvero "pratico" per il rischio di perdere la tua anima, puoi anche scegliere F #).

Scheme e Haskell sono anche lingue molto interessanti. L'enfasi dello schema sulle macro è interessante, ma non direttamente correlata alla programmazione funzionale (è un'altra delle cose al mondo che dovresti assolutamente provare, così come la programmazione logica, i linguaggi basati su stack e la E orientata alle capacità).

Haskell è sicuramente un ottimo linguaggio e, credo, un punto obbligatorio per gli aspiranti guru della programmazione funzionale. Ma poiché le lingue principali di OCaml e Haskell sono molto simili (ad eccezione della valutazione pigra che distrae il principiante), è facile imparare l'Haskell una volta che conosci le basi di OCaml. O meglio, puoi concentrarti su cose strane e non devi assimilare le basi allo stesso tempo.

Allo stesso modo, una volta che hai visto OCaml, e forse anche Haskell, e vuoi ancora saperne di più, dovresti guardare Coq o Agda. Eppure pochi raccomanderebbero Coq o Agda per una prima introduzione alla programmazione funzionale ...

Per chiarire il mio punto di vista: penso che apprendere OCaml (o SML) allora Haskell ti renderà un programmatore funzionale tanto bravo quanto imparare direttamente Haskell, ma più facilmente (o meno dolorosamente).
Inoltre, OCaml e Haskell hanno entrambi degli aspetti positivi che li differenziano, ed è interessante conoscere le funzionalità avanzate di entrambi . Solo l'apprendimento di Haskell è più scarso in questo aspetto (anche se ovviamente potresti imparare OCaml dopo Haskell; penso che sia meno logico e ti renderà più frustrato).

Per imparare OCaml consiglierei la bozza del libro di Jason Hickey (PDF) .

¹ questa definizione è controversa. Alcune persone dello Schema affermeranno che la tipizzazione statica non ha nulla a che fare con la programmazione funzionale. Alcune persone di Haskell affermeranno che la loro definizione di purezza ("cosa fa Haskell, ma non di più") è una condizione sine qua non per essere un linguaggio funzionale. Sono d'accordo di non essere d'accordo.


3
Grazie per avermi spinto verso OCaml, e sì, rischierò la mia anima ed esplorerò F #. Sviluppo per Linux, Mac OS X e Windows (principalmente il primo) ma FSI sembra essere disponibile per tutte e tre le piattaforme (che eseguono mono su Linux e Mac OS X) che già faccio. Il fatto che l'intero peso di Microsoft sia alla base di un linguaggio di programmazione funzionale (anche se "impuro") dovrebbe essere accolto piuttosto che criticato dai fan della programmazione funzionale.
haziz,

SML è morto, ocaml esiste per scrivere coq
permeakra il

1
+1 per ML; è più chiaro di Haskell.
m3th0dman,

Trovo anche una buona idea imparare SML o OCaml, quindi Haskell (+1). Dopo aver conosciuto queste lingue, prenderne un'altra (ad esempio Scala) è molto semplice. Inoltre, si potrebbe vedere Scheme, Common Lisp e Clojure (in questo ordine), per avere un'idea dei linguaggi dinamici.
Giorgio,

@haziz: anche quando creano un buon software, Microsoft (o, del resto, Oracle, ecc.) rimane un monopolista, con tutte le cattive pratiche coinvolte come il blocco dei clienti, i formati incompatibili, le implementazioni incompatibili, ecc.
Giorgio

26

Se sei interessato ai concetti più avanzati nella programmazione funzionale, vai con Haskell. Esiste un sistema di tipi adeguato e un severo divieto di mutazione. Tuttavia, Haskell non è per i deboli di cuore.

Se vuoi solo un'introduzione al design funzionale, scegli Scheme. La sintassi è molto più facile da imparare e leggere. Permette la programmazione procedurale, ma basta disciplinarsi per non usare alcuna procedura con un !alla fine del nome.

Con Scheme, puoi anche leggere la Struttura e l'interpretazione dei programmi per computer , che è la migliore introduzione ai paradigmi di programmazione, a mani basse. Ci sono lezioni sul libro sia del MIT che di Berkeley .


4
"La sintassi è molto più facile da imparare e leggere" è molto soggettiva.

6
@luqui: True. Forse "regolare" è una parola migliore. Nessun backtick, infix, precedenza o problemi di associatività --- solo parentesi, molte parentesi infernali e sciocche.
Hoa Long Tam,

17

La risposta corretta è, ovviamente, entrambe! Quindi è solo una questione di quale lingua affrontare per prima. La mia situazione è identica alla tua. Mi è piaciuto molto The Little Schemer immensamente. Capirai sicuramente i costrutti di base della programmazione funzionale dopo averlo superato (e avrai un posto dove mettere le tue macchie di gelatina!)

Sono circa un quarto di Learn You a Haskell per il bene. Mi sto divertendo anche un po ', ma i due libri non potrebbero essere più diversi. Learn You a Haskell ha un approccio molto tradizionale all'insegnamento di una lingua specifica. Il piccolo schema è specifico per lo schema, ovviamente, ma è molto più interessato all'insegnamento dei fondamenti della programmazione funzionale, non del linguaggio dello schema.

Consiglio vivamente di iniziare con The Little Schemer. È meno pratico, ma più fondamentale.


17

I miei due centesimi per quanto riguarda la programmazione funzionale non sono impiccarsi su un linguaggio particolare, ma imparare i concetti chiave della programmazione funzionale. Ho imparato la programmazione funzionale venendo lanciato a testa in giù in un progetto in cui il mio capo ha insistito affinché tutto lo sviluppo fosse fatto in APL. APL è un linguaggio di elaborazione di array funzionale ed è il più lontano possibile da LISP, Haskell o da qualsiasi altro linguaggio di programmazione tradizionale. Il vero vantaggio è stato quando ho scoperto che una volta "grokking" il paradigma della programmazione funzionale e imparato mentalmente come scomporre auto-magicamente un problema in un programma funzionale, non ero più intimidito dagli aspetti idiomatici di altri linguaggi funzionali come Haskell, OCaml, Scheme, Scala e Clojure. IO'

Se dovessi scegliere un primo linguaggio funzionale, probabilmente sceglierei Haskell o Steel Bank Common Lisp (SBCL). Per Haskell, avrei letto Learn You a Haskell ... , Real World Haskell , The Haskell Road to Logic, Maths and Programming , and Pearls of Functional Algorithm Design . Per CL, avrei letto Land of Lisp , Paradigms of Artificial Intelligence Programming e (se sei davvero hardcore) Let over Lambda . Puoi mescolare e abbinare tutti quei libri per ottenere un'ampia panoramica di approcci e concetti di programmazione funzionale pratica.

Vorrei anche prendere in considerazione l'apprendimento di Clojure e Scala, in quanto sono entrambi linguaggi funzionali molto buoni e molto espressivi a tutti gli effetti (nonostante ciò che il purista del FP potrebbe dire).


6

Concordo con il punto "impara entrambi", ma ci sono alcuni altri punti che non sono stati menzionati finora. Prima di tutto, se sei nuovo nella programmazione funzionale e vai con Haskell, allora devi affrontare diverse nuove cose oltre a FP: devi imparare a vivere in un ambiente pigro che può richiedere uno sforzo considerevole e hai bisogno per gestire un sistema di tipo "reale" che può essere molto lontano da ciò che si utilizza in C o C #.

Scheme, OTOH, ha una sintassi dall'aspetto estraneo, ma non esiste un sistema di tipo statico da imparare ed è un linguaggio rigoroso, quindi le cose sono più familiari. Inoltre, le implementazioni di Scheme tendono ad essere molto malleabili - per esempio, Racket lo porta all'estremo e fornisce una variante pigra e una tipizzata staticamente. Ciò significa che puoi iniziare con le cose "facili" e imparare a usare un linguaggio funzionale, e in seguito puoi farti crescere e usare la variante digitata e quella pigra. Dovrebbero essere più facili ora, dato che puoi gestire una funzione alla volta. Per essere chiari, i concettisaranno abbastanza nuovi che il problema sintattico sarà minore e per lo più irrilevante. In altre parole, una volta che inizi ad arrivare ai nuovi concetti, sarai abbastanza occupato da far scomparire la sintassi. (E se ti interessa davvero la sintassi, allora la sintassi di Haskell è qualcosa che personalmente considero molto elegante - ma questo perché è anche molto lontano dalla tua sintassi C / C # / C ++ media.)

Ma detto tutto ciò, penso che ci sia anche un buon punto per F #: dici che lo fai come una cosa secondaria, ma quando imparerai FP vorrai presto usare tutte quelle cose buone. L'uso di F # significa che puoi fare più cose "reali" poiché è probabilmente facile affrontare lo stesso tipo di problemi che affronti nel tuo lavoro quotidiano. Idealmente, arriverai al punto in cui vedresti il ​​vantaggio di usarlo sopra, diciamo, C # - e utilizzarlo in qualche progetto. Quindi, mentre hai ragione nel non scegliere F # solo perché è più facile per te accedere, dovresti considerarlo dal momento che non c'è niente di meglio che usare effettivamentequesti nuovi concetti. Al contrario, se usi Scheme o Haskell e lo consideri un linguaggio giocattolo per il tuo scopo (anche se sai che alcune persone lo usano per applicazioni reali), allora non prenderai mai troppo sul serio l'intero argomento FP. [Ma YMMV, si basa principalmente su osservazioni soggettive e può variare notevolmente da una persona all'altra.]


6

C'è qualche motivo per cui ML non è una delle tue opzioni? È disponibile una buona quantità di materiale introduttivo tra cui libri e dispense per i corsi. Se ti piace The Little Schemer ti potrebbe piacere anche The Little MLer. Infine, puoi facilmente passare a F # in seguito. (Non che sto bussando a Haskell o Scheme - idealmente impari tutti e tre).

Inoltre, un avvertimento su Emacs Lisp. Non credo che Haskell o ML ti prepareranno per questo. Un linguaggio di Lispy come Scheme aiuterà ma ci sono ancora differenze importanti, ad es. variabili con ambito dinamico. Le estensioni di Emacs, per loro stessa natura, tendono ad essere più imperative che funzionali: si tratta solo di alterare lo stato dell'editor.


Grazie per avermi spinto verso ML / OCaml, e sì "rischierò la mia anima" ed esplorerò F #. Sviluppo per Linux, Mac OS X e Windows (principalmente il primo) ma FSI sembra essere disponibile per tutte e tre le piattaforme (che eseguono mono su Linux e Mac OS X) che già faccio. Il fatto che l'intero peso di Microsoft sia alla base di un linguaggio di programmazione funzionale (anche se "impuro") dovrebbe essere accolto piuttosto che criticato dai fan della programmazione funzionale.
haziz,

A proposito, ho ordinato The Little MLer da Amazon, l'ho già ricevuto e ho iniziato il mio viaggio. Ho anche appena aggiunto Learning F # alla mia libreria. Sembra essere una guida didattica più tradizionale, che userò per integrare The Little MLer.
haziz,

6

Scriviti uno schema in 48 ore (in haskell)

Lo consiglio davvero. Imparerai Haskell usando un problema reale e interessante e imparerai la migliore lezione di schema giocando con l'interprete che costruisci. Se segui questa strada, tieni alcune buone introduzioni di Haskell in giro. Li capirai meglio se hai un problema da risolvere.


In realtà ho usato questo wiki / pdf per imparare Haskell e rispolverare le mie abilità OCaml (traducendo Haskell idiomatico in OCaml). Sarebbe davvero bello se qualcuno potesse prendere questo materiale e "borsarlo" per diversi linguaggi funzionali. Potrebbe essere la base per una sparatoria di linguaggio funzionale piuttosto interessante!
Marc

1
Il problema principale è che introduce parsec senza introdurre monadi.
alternativa il

@alternative parsec ha un'interfaccia Monadic, ma ha anche un'interfaccia Applicativa, per non parlare di numerose altre funzioni. Non è irragionevole introdurre Parsec prima della generalizzazione monadica
Philip JF,

4

Vorrei andare con Haskell. Nello schema, potresti essere spinto a fare cose procedurali e il suo sistema di tipi non è altrettanto utile di quello di Haskell, che è ottimo per un principiante in quanto controlla quasi che il tuo codice sia corretto al momento della compilazione.


3
"praticamente controlla che il tuo codice sia corretto" è molto sbagliato. Nessun sistema di tipi può farlo. (A meno che il tuo sistema di tipi non sia un vero dimostratore di teoremi.)
Eli Barzilay,

4
@Eli, hai usato Haskell? Sebbene teoricamente questa affermazione sia ovviamente falsa, in pratica la trovo abbastanza accurata, almeno in confronto a tutte le altre lingue che ho usato. Detto questo, in realtà non sono d'accordo sul fatto che questa sia una buona proprietà per un principiante. Quando sto imparando le corde, preferirei vedere nello specifico ciò che il mio codice ha sbagliato, piuttosto che farmi urlare dal compilatore che è sbagliato e dovrò lottare con esso quando non conosco nemmeno il vocabolario utilizzato dai messaggi di errore.

1
@Eli "praticamente" è il termine chiave qui. In Haskell passi più tempo a pensare a come implementarlo, quindi l'implementazione arriva abbastanza facilmente. Quindi lo digiti per assicurarti che mappe, pieghe, ecc. Siano sani.
alternativa il

@Eli Barzilay: il sistema di tipi di Haskell sembra proprio come se fosse molto vicino a essere un teorema dimostratore. Certamente ha creato un ambiente in cui i dimostratori di teoremi sembrano quasi più comuni di altri strumenti. (Non che sto insinuando una relazione causale.)
Greyfade,

@luqui - Sì, l'ho usato; no, è ancora un'affermazione falsa, sia in pratica che in teoria. Questo non è qualcosa che è unico per Haskell però.
Eli Barzilay,

1

Penso che sia facile rimanere coinvolti nei dibattiti sulle lingue e perdere il punto. Per qualcuno che vuole solo sapere di cosa tratta FP, le differenze tra Ocaml / ML / Scheme / Haskell non sono la metà importanti del tuo comfort con il materiale (libri, video, strumenti) che usi per impararlo. E se hai o meno un amico che ti aiuta a imparare in una determinata lingua, vince su tutto il resto.


0

Se non è puro, puoi anche usare un linguaggio imperativo, quindi Haskell.


0

In una delle risposte che hai ricevuto alla tua domanda, ho trovato questo link piuttosto interessante, perché ti dà un assaggio di Haskell e Scheme.

Oltre a questo elegante link, ecco la mia opinione sulla tua domanda.

Se provieni da un background di programmazione imperativo, potresti finire per impegnarti molto nell'apprendimento della programmazione funzionale. Vorrei assicurarmi che l'esperienza di apprendimento non sia vuota. Cioè puoi applicarlo al tuo lavoro attuale o successivo o che ti aiuterà in qualche altro modo.

Ci sono molte buone lingue là fuori. Il popolo della Scala avrebbe esaltato la loro lingua, così come la gente Clojure e CL. Persino i pitonisti sostengono la pigrizia. Altre persone che ti hanno risposto hanno suggerito ML. Amit Rathore che ha scritto Clojure in Action potrebbe anche suggerirti di imparare l'Haskell.

Hai citato Windows e F #. Questo ti aiuterà nella tua posizione attuale? Non so nulla di F #. È abbastanza funzionale? Lo chiedo, perché IMHO Python ha costrutti funzionali, ma non è come programmare in Clojure.

Riassumendo, impara un linguaggio funzionale che è "veramente" funzionale e, nel farlo, ha il miglior senso per la tua situazione.


-2

Dal punto di vista di un principiante relativo, suggerisco di non iniziare con SICP se decidi di Scheme, a meno che la tua matematica non sia abbastanza matura. Il libro e i video sono pieni di sottigliezze e non sono affatto intuitivi per chi inizia.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.