Quali affermazioni e approcci dovrei evitare quando apprendo la programmazione funzionale?

La programmazione funzionale è più di una semplice lista di istruzioni da evitare. È un cambiamento (spesso) radicale nella mentalità. Ad esempio, non ci sono cambiamenti di stato distruttivi consentiti nella programmazione funzionale. Se dico che A = 5, non ho impostato A come una sorta di scatola contenente un 5. Ho reso A esattamente lo stesso di 5, per sempre. C'è un ottimo libro, scritto in collaborazione con l'unico e solo Jon Skeet chiamato Real World Functional Programming .

Per quanto riguarda l'apprendimento della programmazione puramente funzionale, in realtà raccomando Haskell su F #. Certo, probabilmente otterrai risultati migliori in termini di codice di produzione con F # o Ocaml, ma Haskell piegherà la tua mente nella forma giusta per far funzionare la programmazione funzionale. Il processo potrebbe richiedere del tempo, tuttavia.

Raccomando Impara un Haskell se vuoi una guida. L'opzione del libro C # / F # è meno dolorosa. C # e F # ti lasciano una solida, praticabile magia come programmatore funzionale. Haskell è una stregoneria nera al confronto.

L'apprendimento della programmazione funzionale non consiste nell'applicare ciò che si sa dalla programmazione imperativa e orientata agli oggetti e sfruttando ciò per apprendere la programmazione funzionale. Nella tua domanda stai chiedendo cosa evitare, quando credo che dovresti pensare è: per imparare la programmazione funzionale mi rendo conto che dovrei assolutamente mettere da parte ciò che so sulla programmazione imperativa; dove dovrei iniziare.

Come alcuni consigli di partenza vedi Come effettuare la transizione alla programmazione funzionale?

Quindi non convertire il codice imperativo in codice funzionale. Se un algoritmo è suscettibile di programmazione funzionale, utilizzare la programmazione funzionale. Se un algoritmo è suscettibile di programmazione imperativa, allora usa la programmazione imperativa.

Per rispondere alla tua domanda in modo più specifico

• Invece di istruzioni di selezione usa corrispondenza del modello .
• Invece di istruzioni di iterazione usa ricorsione
• Invece di oggetti usa unioni discriminate .
• Invece di raccolte .NET , utilizza F # tipi come elenco F # (che sono diversi da elenco .NET ), tuple , ecc. Nota: gli oggetti sono basati su classi che sono generalmente basate su heap e preservano lo stato mentre i tipi F # sono basati su strutture che sono in genere basati sullo stack, sono ottimizzati per l'uso con F # e in genere immutable .

Nel mondo degli oggetti orientato agli oggetti sono re, nel mondo funzionale le funzioni sono re.

Probabilmente la cosa più importante per evitare è utilizzare i costrutti che cambiano stato .

Molte persone che iniziano ad apprendere la programmazione funzionale cercano di "emulare" il pensiero imperativo in un linguaggio funzionale. Ciò si traduce in programmi poveri che li fanno sentire che i linguaggi funzionali sono ingombranti e inefficaci. Quindi è importante liberarsi del pensiero imperativo. Non pensare ai passaggi che il programma dovrebbe fare , pensa alle espressioni (funzioni), a cosa significano e come combinarle per ottenere il risultato desiderato.

Inoltre, non preoccuparti troppo dell'efficacia del tuo programma all'inizio. I programmatori imperativi pensano spesso che creare nuove istanze di strutture dati ogni volta che vogliono "cambiare" qualcosa deve rendere il programma lento e inefficace. I linguaggi funzionali sono ottimizzati per questo.

Come affermato in un'altra risposta, F #, OCaml, Scala e molti altri linguaggi funzionali consentono costrutti che cambiano lo stato, effetti collaterali e sequenze imperative di affermazioni. D'altra parte, Haskell non lo consente e quindi non hai altra scelta che imparare come farlo in modo puramente funzionale. (Ho visto molte persone descriverlo come "ricablare il cervello".)