Sono interessato alla programmazione funzionale e ho deciso di confrontarmi con Haskell. Mi fa male la testa ... ma alla fine lo prenderò ... Ho una curiosità però, perché la sintassi è così criptica (in mancanza di un'altra parola)?
C'è una ragione per cui perché non è più espressivo , più vicino alla lingua umana?
Comprendo che FP è bravo a modellare concetti matematici e ha preso in prestito alcuni dei suoi concisi mezzi di espressione, ma ancora non è matematica ... è un linguaggio.
Linguaggi funzionali come Haskell e il suo antecedente Miranda nasce dal concetto matematico di calcolo lambda . Dalla pagina di Wikipedia:
Lambda calculus (also written as λ-calculus or called "the lambda calculus") is a formal system in mathematical logic for expressing computation by way of variable binding and substitution.
...
Lambda calculus has played an important role in the development of the theory of programming languages. The most prominent counterparts to lambda calculus in computer science are functional programming languages, which essentially implement the calculus (augmented with some constants and datatypes). Beyond programming languages, the lambda calculus also has many applications in proof theory. A major example of this is the Curry–Howard correspondence, which gives a correspondence between different systems of typed lambda calculus and systems of formal logic.
A causa di questa storia, le sintassi di questi linguaggi funzionali (e gli elementi funzionali di linguaggi più imperativi) sono strongmente influenzati dalla notazione matematica utilizzata dal calcolo lambda.
La precisione con cui sia le notazioni matematiche che i linguaggi informatici possono descrivere i requisiti e la precisione con cui i computer richiedono che le loro istruzioni siano scritte si correlano bene l'una con l'altra. L'imprecisione del linguaggio naturale crea tuttavia un enorme ostacolo al suo utilizzo per la programmazione dei computer. Anche il programmazione in linguaggio naturale di maggior successo (ad esempio Wolfram Alpha richiede un'esperienza di dominio significativa per essere utilizzata in modo efficace.
La sintassi di Haskell è vicino alla lingua umana. È specificamente progettato per assomigliare alla notazione matematica, che è un linguaggio progettato dagli umani (quindi un linguaggio umano ) per esprimere esattamente quei concetti su cui è basato Haskell.
Puoi mostrare un codice Haskell a qualsiasi matematico o logico, e sarà in grado di capirlo, anche se non ha mai sentito parlare di Haskell e non sa assolutamente nulla sulla programmazione, l'informatica o persino i computer.
D'altra parte, puoi mostrare a qualsiasi matematico o logico una parte di codice come questa:
x = x + 1
e sarà completamente confuso, dicendo: "Questo non ha senso, non c'è x tale che x equivale a x più 1 ."
Se una notazione specifica è o meno "criptica" o meno, è una questione di opinione e di familiarità.
Penso che una cosa che probabilmente stai incontrando è qualcosa che ho incontrato anche quando ho imparato la programmazione funzionale, ovvero che con la programmazione funzionale puoi (e quasi devi) pensare / lavorare a un livello più alto di quello che fai con programmazione imperativa.
Ciò che trovi meno espressivo, in realtà è più espressivo: non devi specificare ogni piccolo dettaglio e puoi fare di più con meno codice nella programmazione funzionale - c'è più potere a ciò che scrivi.
Ad esempio, potrei scrivere imperativamente:
for each (Person person in people)
print(person.name)
che è completamente leggibile come inglese.
Una versione Haskell potrebbe essere (e questo non è Haskell valido, ma è solo per il confronto sintattico):
map (print . name) people
che richiede meno codice e meno wrangling dei dettagli - Non devo rompere le cose in un ciclo e le sue variabili ( for each (...) ), la funzione map si occupa di questo per me.
Lavorare a quel livello può richiedere un po 'di tempo per abituarsi. Se è d'aiuto, Haskell è stato probabilmente il periodo più difficile in cui ho imparato una nuova lingua da quando ho iniziato a programmare e conosco 10 lingue (incluso il Lisp). Però valeva assolutamente la pena imparare.
Al momento sto facendo i conti con Scala al momento, quindi posso simpatizzare. Almeno con Scala posso tornare a uno stile imperativo quando il gioco si fa troppo duro.
Penso che ci siano diverse forze in gioco qui:
I progettisti di linguaggi funzionali hanno necessariamente un strong background matematico, quindi prendono in prestito la notazione matematica che è naturale per loro.
Maggiore espressività (vale a dire potere delle affermazioni, piuttosto che vicinanza all'inglese) di qualsiasi lingua ha (IMO) un prezzo corrispondente in pendenza della curva di apprendimento. La tarsità è una qualità molto apprezzata in Scala, con molte cose facoltative.
I linguaggi funzionali fanno semplicemente le cose in modo molto diverso, quindi la base le operazioni non si associano ai costrutti imperativi.
Se ho capito correttamente il tuo ultimo commento, la tua domanda è: perché Haskell usa spesso operatori simbolici in luoghi dove potrebbe anche usare parole chiave alfanumeriche (o nomi di funzioni)?
Per quanto riguarda le parole chiave, una risposta sarebbe che le parole chiave impediscono l'utilizzo di determinate parole come nomi di variabili. Ad esempio, sono sempre seccato quando voglio chiamare le mie variabili from e to in una lingua in cui una di queste è una parola chiave, come in Python.
Un altro motivo per gli operatori simbolici in generale è la concisione. Ciò non vale in realtà per i tuoi esempi specifici di comprensione delle liste ( <- non è più corto di in ), ma in molti casi lo fa.
Ancora un altro motivo è la leggibilità. Ciò potrebbe sembrare contro-intuitivo perché gli operatori simbolici sono spesso più difficili da imparare poiché i loro "nomi" non ti dicono veramente nulla su ciò che fanno (mentre il nome di una funzione di solito lo farà), ma una volta che sai cosa fa un determinato operatore, le espressioni con gli operatori simbolici infissi sono spesso più facili da analizzare per un utente umano rispetto a molte chiamate alfanumeriche al prefisso, poiché gli operatori sono più facilmente distinguibili visivamente dagli operandi in quel modo. Ad esempio, molte persone sono d'accordo che 2 * 3 + 4 è più facilmente leggibile di add (mult 2 3) 4 o add(mult(2, 3), 4) .
I linguaggi informatici imperativi per lo più non sono più vicini alle lingue naturali di quanto, ad esempio, sia Haskell.
Tuttavia, alcuni sono progettati per essere più simili all'inglese: Cobol e Hypercard, per esempio. Le lezioni che prenderò da questi esempi sono:
Il linguaggio per computer Perl è stato riferito progettato con alcuni aspetti più sottili di in mente lingua . Giudicherei che Perl faccia meglio di Cobol o Hypercard sull'usabilità generale, ma le persone hanno opinioni divergenti su Perl.
Penso che Haskell sia simile alla lingua umana, come si può ottenere senza introdurre una sintassi pazzesca. Si tratta in effetti di una lunga durata, ad esempio con la clausola where per posticipare una definizione e con la sintassi di comprensione delle liste che è esattamente ciò che scriverei su una lavagna. Evita anche personaggi estranei come parentesi graffe e ha un uso liberale di indentazione. L'esempio tipico è quicksort:
qsort [] = []
qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
where lesser = [x | x <- xs, x <= p]
greater = [x | x <- xs, x > p]
Ammesso, è un semplice esempio, ma non conosco nessun altro linguaggio che lo renda leggibile come questo.
Fare cose più complicate può diventare difficile da leggere in Haskell, ma questo ha a che fare con il sistema di tipi, con l'I / O vincolato e non con la sintassi.
Se mai, direi che Haskell ha sacrificato la semplicità sintattica per adattarsi a una sintassi più simile al linguaggio umano. Uno schema simile al linguaggio ha una sintassi molto lontana da ciò che un umano dovrebbe scrivere, ma è davvero semplice spiegarne le regole.
Penso che la differenza abbia a che fare con il modo in cui la programmazione funzionale / dichiarativa rende le dichiarazioni su un problema come se fosse un problema di matematica, dove la programmazione imperativa descrive un processo . Nel mondo degli affari, i programmi per computer avvolgono o sostituiscono i processi fisici, quindi potresti trovare un linguaggio che lo rispecchi per essere più intuitivo.
Si scopre che lo stile funzionale si presta a fare un uso sicuro di più processori (perché riduce al minimo la mutevolezza e gli effetti collaterali) - qualcosa che vedremo più in futuro. Inoltre, i linguaggi funzionali più moderni dispongono di raccolte con iteratori ai quali è possibile passare le funzioni. Questi metodi possono suddividere il loro carico di lavoro su più processori in modo molto efficiente senza che tu ne sia a conoscenza.
Leggi altre domande sui tag programming-languages syntax functional-programming haskell