Perché Python non è molto buono per la programmazione funzionale? [chiuso]

Ho sempre pensato che la programmazione funzionale possa essere eseguita in Python. Pertanto, sono rimasto sorpreso dal fatto che Python non abbia ricevuto molta menzione in questa domanda e, quando è stato menzionato, normalmente non era molto positivo. Tuttavia, non sono state fornite molte ragioni per questo (sono state menzionate la mancanza di pattern matching e tipi di dati algebrici). Quindi la mia domanda è: perché Python non è molto buono per la programmazione funzionale? Ci sono più ragioni della sua mancanza di pattern matching e tipi di dati algebrici? Oppure questi concetti sono così importanti per la programmazione funzionale che un linguaggio che non li supporta può essere classificato solo come un linguaggio di programmazione funzionale di seconda classe? (Tieni presente che la mia esperienza con la programmazione funzionale è piuttosto limitata.)

La domanda a cui fai riferimento pone quali lingue promuovono la programmazione sia funzionale che funzionale. Python non promuove la programmazione funzionale anche se funziona abbastanza bene.

Il miglior argomento contro la programmazione funzionale in Python è che i casi d'uso imperativo / OO sono attentamente considerati da Guido, mentre i casi d'uso di programmazione funzionale non lo sono. Quando scrivo Python imperativo, è una delle lingue più belle che conosca. Quando scrivo Python funzionale, diventa brutto e sgradevole come il tuo linguaggio medio che non ha un BDFL .

Il che non vuol dire che sia un male, solo che devi lavorare di più di quanto faresti se passassi a un linguaggio che promuove la programmazione funzionale o passi a scrivere OO Python.

Ecco le cose funzionali che mi mancano in Python:

• Corrispondenza del modello
• Ricorsione della coda
• Ampia libreria di funzioni elenco
• Classe di dizionario funzionale
• Curry automatico
• Modo conciso per comporre le funzioni
• Elenchi pigri
• Sintassi di espressione semplice e potente (la sintassi a blocchi semplice di Python impedisce a Guido di aggiungerla)

• Nessuna corrispondenza del modello e nessuna ricorsione della coda significano che gli algoritmi di base devono essere scritti in modo imperativo. La ricorsione è brutta e lenta in Python.
• Una piccola libreria di elenchi e nessun dizionario funzionale significa che devi scrivere molte cose da solo.
• Nessuna sintassi per curry o composizione significa che uno stile privo di punti è pieno di punteggiatura come argomenti che passano esplicitamente.
• Iteratori anziché gli elenchi pigri significa che devi sapere se vuoi efficienza o persistenza e spargere le chiamate verso listse vuoi persistenza. (Iteratori vengono utilizzati una volta)
• La semplice sintassi imperativa di Python, insieme al suo semplice parser LL1, significa che una sintassi migliore per le espressioni if ​​e le espressioni lambda è sostanzialmente impossibile. A Guido piace così, e penso che abbia ragione.

Guido ha una buona spiegazione di questo qui . Ecco la parte più rilevante:

Non ho mai considerato Python fortemente influenzato dai linguaggi funzionali, indipendentemente da ciò che la gente dice o pensa. Conoscevo molto di più i linguaggi imperativi come C e Algol 68 e sebbene avessi fatto funzioni oggetti di prima classe, non vedevo Python come un linguaggio di programmazione funzionale. Tuttavia, in precedenza, era chiaro che gli utenti volevano fare molto di più con elenchi e funzioni.

...

Vale anche la pena notare che anche se non immaginavo Python come un linguaggio funzionale, l'introduzione di chiusure è stata utile nello sviluppo di molte altre funzionalità di programmazione avanzata. Ad esempio, alcuni aspetti delle nuove classi di stile, decoratori e altre funzionalità moderne si basano su questa capacità.

Infine, anche se nel corso degli anni sono state introdotte numerose funzionalità di programmazione funzionale, a Python mancano ancora alcune funzionalità presenti nei linguaggi di programmazione funzionale "reali". Ad esempio, Python non esegue determinati tipi di ottimizzazioni (ad es. Ricorsione della coda). In generale, poiché la natura estremamente dinamica di Python, è impossibile eseguire il tipo di ottimizzazione in fase di compilazione conosciuta da linguaggi funzionali come Haskell o ML. E va bene.

Ne tiro fuori due cose:

1. Il creatore del linguaggio non considera davvero Python un linguaggio funzionale. Pertanto, è possibile vedere le funzionalità "funzionali-esque", ma è improbabile che tu veda qualcosa che sia definitivamente funzionale.
2. La natura dinamica di Python inibisce alcune delle ottimizzazioni che vedi in altri linguaggi funzionali. Certo, Lisp è altrettanto dinamico (se non più dinamico) di Python, quindi questa è solo una spiegazione parziale.

Lo schema non ha tipi di dati algebrici o pattern matching ma è sicuramente un linguaggio funzionale. Cose fastidiose su Python dal punto di vista della programmazione funzionale:

1. Lambdas paralizzato. Poiché Lambdas può contenere solo un'espressione e non è possibile eseguire tutte le operazioni con la stessa facilità in un contesto di espressione, ciò significa che le funzioni che è possibile definire "al volo" sono limitate.

2. Gli if sono dichiarazioni, non espressioni. Questo significa, tra l'altro, che non puoi avere un lambda con un If al suo interno. (Questo è risolto dai ternari in Python 2.5, ma sembra brutto.)

3. Guido minaccia di rimuovere mappe, filtri e riduzioni di tanto in tanto

D'altra parte, Python ha chiusure lessicali, Lambdas e comprensioni di elenchi (che sono in realtà un concetto "funzionale" indipendentemente dal fatto che Guido lo ammetta o meno). Faccio molta programmazione in "stile funzionale" in Python, ma difficilmente direi che sia l'ideale.

Non definirei mai Python "funzionale" ma ogni volta che programma in Python il codice finisce inevitabilmente per essere quasi puramente funzionale.

Certo, ciò è dovuto principalmente alla comprensione dell'elenco estremamente piacevole. Quindi non suggerirei necessariamente Python come linguaggio di programmazione funzionale, ma suggerirei la programmazione funzionale per chiunque usi Python.

Consentitemi di dimostrare con un pezzo di codice tratto da una risposta a una domanda "funzionale" di Python su SO

Pitone:

def grandKids(generation, kidsFunc, val):
  layer = [val]
  for i in xrange(generation):
    layer = itertools.chain.from_iterable(itertools.imap(kidsFunc, layer))
  return layer

Haskell:

grandKids generation kidsFunc val =
  iterate (concatMap kidsFunc) [val] !! generation

La differenza principale è che libreria standard di Haskell ha funzioni utili per la programmazione funzionale: in questo caso iterate, concate(!!)

Una cosa veramente importante per questa domanda (e le risposte) è la seguente: che diavolo è la programmazione funzionale e quali sono le sue proprietà più importanti. Proverò a darmi il mio punto di vista:

La programmazione funzionale è molto simile alla scrittura di matematica su una lavagna. Quando si scrivono equazioni su una lavagna, non si pensa a un ordine di esecuzione. Non c'è (in genere) nessuna mutazione. Non torni il giorno dopo e non lo guardi, e quando esegui di nuovo i calcoli, ottieni un risultato diverso (o potresti, se hai bevuto del caffè fresco :)). Fondamentalmente, quello che è alla lavagna è lì, e la risposta era già lì quando hai iniziato a scrivere le cose, non hai ancora capito di cosa si tratta ancora.

La programmazione funzionale è molto simile; non cambi le cose, devi solo valutare l'equazione (o in questo caso "programma") e capire qual è la risposta. Il programma è ancora lì, non modificato. Lo stesso con i dati.

Vorrei classificare quanto segue come le caratteristiche più importanti della programmazione funzionale: a) trasparenza referenziale - se si valuta la stessa affermazione in un altro momento e luogo, ma con gli stessi valori variabili, significherà comunque lo stesso. b) nessun effetto collaterale - non importa per quanto tempo fissi la lavagna, l'equazione che un altro ragazzo sta guardando un'altra lavagna non cambierà accidentalmente. c) anche le funzioni sono valori. che possono essere passati in giro e applicati con o verso altre variabili. d) composizione della funzione, puoi fare h = g · f e quindi definire una nuova funzione h (..) che equivale a chiamare g (f (..)).

Questa lista è nel mio ordine prioritario, quindi la trasparenza referenziale è la più importante, seguita da nessun effetto collaterale.

Ora, se passi attraverso Python e controlli quanto bene il linguaggio e le librerie supportano e garantiscono questi aspetti, allora sei sulla buona strada per rispondere alla tua domanda.

Python è quasi un linguaggio funzionale. È "lite funzionale".

Ha funzionalità extra, quindi non è abbastanza puro per alcuni.

Manca anche alcune funzionalità, quindi non è abbastanza completo per alcune.

Le funzioni mancanti sono relativamente facili da scrivere. Dai un'occhiata a post come questo su FP in Python.

Un altro motivo non menzionato sopra è che molte funzioni e metodi incorporati di tipi incorporati modificano un oggetto ma non restituiscono l'oggetto modificato. Se tali oggetti modificati fossero restituiti, ciò renderebbe il codice funzionale più pulito e più conciso. Ad esempio, se some_list.append (some_object) restituisce some_list con some_object aggiunto.

Oltre ad altre risposte, un motivo per cui Python e la maggior parte degli altri linguaggi multi-paradigma non sono adatti alla vera programmazione funzionale è perché i loro compilatori / macchine virtuali / runtime non supportano l'ottimizzazione funzionale. Questo tipo di ottimizzazione è ottenuta dal compilatore che comprende le regole matematiche. Ad esempio, molti linguaggi di programmazione supportano una mapfunzione o un metodo. Questa è una funzione abbastanza standard che accetta una funzione come argomento e un iterabile come secondo argomento quindi applica quella funzione a ciascun elemento nell'iterabile.

Comunque risulta che map( foo() , x ) * map( foo(), y )è lo stesso di map( foo(), x * y ). Il secondo caso è in realtà più veloce del primo perché il primo esegue due copie in cui il secondo esegue uno.

I linguaggi funzionali migliori riconoscono queste relazioni matematicamente basate ed eseguono automaticamente l'ottimizzazione. Le lingue che non sono dedicate al paradigma funzionale probabilmente non verranno ottimizzate.