Strategie di programmazione funzionale in lingue imperative

Lo stato mutabile è facilmente evitabile usando oggetti immutabili. Allo stesso modo, le variabili globali sono solitamente la scelta dello sviluppatore (o di un framework mal implementato).

Detto questo, potresti anche voler utilizzare paradigmi funzionali aggiuntivi in lingue non funzionali . Riguarda l'espressività del tuo codice. Se vedi che una comprensione delle liste in Python rende il tuo codice facile, fallo. Se lo trovi più leggibile in un caso particolare, avere una struttura immutabile usata attraverso il concatenamento del metodo, ottimo.

Ma non dimenticare, alcune persone trovano varianti imperative più semplici di quelle funzionali , anche se ciò significa scrivere tre volte il LOC originale e rischiando di introdurre bug sottili. Ancora più importante, alcuni programmatori non capiscono i concetti di base. Molti programmatori C # sono in difficoltà con la valutazione pigra e non sono in grado di spiegare perché, se prendi un IEnumerable<T> che restituisce una serie di elementi dal database e prima contali il numero di elementi, quindi esegui il ciclo, non ce ne sarà uno , ma due query al database. Non sto nemmeno parlando di monadi e altri concetti che sono per lo più inutilizzati nei linguaggi tradizionali non funzionali.

Inoltre, non preoccuparti di non lavorare con i linguaggi funzionali. Le lingue non funzionali tendono ad essere ispirate negli ultimi anni da quelle funzionali. C # è un ottimo esempio. Python e JavaScript sono altri due linguaggi mainstream che tendono ad introdurre in loro aspetti sempre più funzionali. In sostanza, qualsiasi linguaggio che supporti la valutazione lazy e le espressioni lambda è un buon candidato per il codice in stile funzionale.

How can I write solid functional code that does not allow side effects even in languages that have mutable state and global variables?

La semplice risposta è, non usare variabili globali o mutevoli, o solo perché puoi mutarle non significa che devi.

Considera una classe come questa:

class ImmutableClass
{
    private int myImmutableField;

    public ImmutableClass(int fieldValue)
    {
        this.myImmutableField = fieldValue;
    }

    public int FieldValue { get { return this.myImmutableVariable; } }
}    

Quella classe è immutabile e persino sicura per i thread. Non c'è modo di mutare lo stato dopo che è stato costruito, anche se il campo è tecnicamente mutevole.

Preferisci funzioni pure e variabili / oggetti immutabili.

Oltre a ciò, tieni a mente i limiti e le convenzioni della lingua che stai utilizzando. Non dimenticare:

• La leggibilità. I tuoi colleghi troveranno più difficile capire il tuo codice non idiomatico

• Ottimizzazione della chiamata su coda mancante

• Mancanza di pigrizia

• Mancanza di ottimizzazioni utili (ad es. stream fusion)

• Mancanza di sintassi conveniente (ad esempio per le funzioni anonime) ecc ...

Nella mia esperienza, ad eccezione di alcuni map se filter s qua e là, la spinta delle astrazioni funzionali troppo lontano non ha mai funzionato bene. La programmazione funzionale è molto potente, ma non significa che sia il "vero modo assoluto" in tutti i contesti.