Piccole quantità di programmazione funzionale sono comprensibili per le persone non FP? [chiuso]

Caso : sto lavorando in un'azienda, scrivendo un'applicazione in Python che sta gestendo molti dati negli array. Sono l'unico sviluppatore di questo programma al momento, ma probabilmente verrà utilizzato / modificato / esteso in futuro (1-3 anni) da qualche altro programmatore, in questo momento a me sconosciuto. Probabilmente non sarò lì direttamente per aiutarti, ma forse darò un po 'di supporto via e-mail se ho tempo per farlo.

Quindi, come sviluppatore che ha imparato la programmazione funzionale (Haskell), tendo a risolvere, ad esempio, il filtro in questo modo:

filtered = filter(lambda item: included(item.time, dur), measures)

Il resto del codice è OO, sono solo alcuni piccoli casi in cui voglio risolverlo in questo modo, perché secondo me è molto più semplice e più bello.

Domanda : oggi va bene scrivere codice come questo?

• In che modo uno sviluppatore che non ha scritto / imparato FP reagisce a questo codice?
• È leggibile?
• Modificabile?

• Dovrei scrivere documentazione come spiegare a un bambino cosa fa la linea?

   # Filter out the items from measures for which included(item.time, dur) != True

Ho chiesto al mio capo, e lui dice semplicemente "FP è magia nera, ma se funziona ed è la soluzione più efficiente, allora va bene usarla."

Qual è la tua opinione su questo? Come programmatore non FP, come reagisci al codice? Il codice è "googabile" in modo che tu possa capire cosa fa? Mi piacerebbe un feedback su questo.

È leggibile?

Per me: Sì, ma ho capito che la comunità di Python sembra spesso considerare la comprensione degli elenchi una soluzione più pulita rispetto all'utilizzo di map()/ filter().

In effetti, GvR ha persino considerato di abbandonare del tutto quelle funzioni.

Considera questo:

filtered = [item for item in measures if included(item.time, dur)]

Inoltre, ciò ha il vantaggio che la comprensione di un elenco restituirà sempre un elenco. map()e filter()d'altra parte restituirà un iteratore in Python 3.

Nota: se si desidera avere un iteratore, è semplice come sostituire []con ():

filtered = (item for item in measures if included(item.time, dur))

Ad essere sincero, vedo poco o nessun motivo per usare map()o filter()in Python.

È modificabile?

Sì, certo, tuttavia, c'è una cosa per renderlo più semplice: renderlo una funzione, non un lambda.

def is_included(item):
    return included(item.time, dur)
filtered = filter(is_included, measures)
filtered = [item for item in measures if is_included(item)]

Se le tue condizioni diventano più complesse, questo ridimensionerà molto più facilmente, inoltre, ti permetterà di riutilizzare il tuo controllo. (Si noti che è possibile creare funzioni all'interno di altre funzioni, questo può tenerlo più vicino al luogo in cui viene utilizzato.)

In che modo uno sviluppatore che non ha scritto / imparato FP reagisce su un codice del genere?

Cerca su Google la documentazione di Python e sa come funziona cinque minuti dopo. Altrimenti, non dovrebbe programmare in Python.

map()e filter()sono estremamente semplici. Non è che stai chiedendo loro di capire le monadi. Ecco perché non penso che tu debba scrivere tali commenti. Usa nomi di variabili e funzioni validi, quindi il codice è quasi autoesplicativo. Non puoi prevedere quali lingue non siano note a uno sviluppatore. Per quanto ne sai, il prossimo sviluppatore potrebbe non sapere cos'è un dizionario.

Ciò che non capiamo di solito non è leggibile per noi. Quindi, potresti sostenere che non è meno leggibile di una comprensione di elenco se non hai mai visto nessuno dei due prima. Ma come Joshua ha menzionato nel suo commento, anche io credo che sia importante essere coerenti con ciò che usano gli altri sviluppatori - almeno se l'alternativa non offre alcun vantaggio sostanziale.

Poiché la comunità di sviluppatori sta riacquistando interesse per la programmazione funzionale, non è inusuale vedere una programmazione funzionale in linguaggi che in origine erano completamente orientati agli oggetti. Un buon esempio è C #, in cui i tipi anonimi e le espressioni lambda consentono di essere molto più brevi ed espressivi attraverso la programmazione funzionale.

Detto questo, la programmazione funzionale è strana per i principianti. Ad esempio, durante un corso di formazione, ho spiegato ai principianti come possono migliorare il loro codice attraverso la programmazione funzionale in C #, alcuni di loro non erano convinti, e alcuni hanno detto che il codice originale era più facile da capire per loro. L'esempio che ho dato loro era il seguente:

Codice prima del refactoring:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Stesso codice dopo il refactoring utilizzando FP:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Questo mi fa pensare che:

• non dovresti preoccuparti se sai che il prossimo sviluppatore che manterrà il tuo codice avrà un'esperienza complessiva sufficiente e una certa conoscenza della programmazione funzionale, ma:

• altrimenti, evita la programmazione funzionale o metti un commento dettagliato che spieghi allo stesso tempo la sintassi, i vantaggi e le possibili avvertenze del tuo approccio rispetto a una programmazione non funzionale.

Sono un programmatore non FP e recentemente ho dovuto modificare il codice del mio collega in JavaScript. C'era una richiesta Http con un callback che assomigliava molto alla dichiarazione inclusa da te. Devo dire che mi ci è voluto del tempo (come mezz'ora) per capire tutto (il codice tutto sommato non era molto grande).

Non c'erano commenti e penso che non ce n'era bisogno per nessuno. Non ho nemmeno chiesto al mio collega di aiutarmi a capire il suo codice.

Tenendo conto del fatto che sto lavorando da circa 1,5 anni, penso che la maggior parte dei programmatori sarà in grado di comprendere e modificare tale codice, da quando l'ho fatto.

Inoltre, come ha detto Joachim Sauer nel suo commento, spesso ci sono pezzi di FP in molte lingue, come C # (indexOf, per esempio). Quindi molti programmatori non-FP lo affrontano abbastanza spesso e lo snippet di codice che hai incluso non è qualcosa di terribile o incomprensibile.

Direi sicuramente di si!

Esistono molti aspetti della programmazione funzionale e l'utilizzo di funzioni di ordine superiore, come nel tuo esempio, è solo uno di questi.

Ad esempio, ritengo che la scrittura di funzioni pure sia estremamente importante per qualsiasi software scritto in qualsiasi lingua (dove per "puro" non intendo effetti collaterali) perché:

• sono più facili da testare l'unità
• sono molto più compostabili rispetto alle funzioni con effetti collaterali
• sono più facili da eseguire il debug

Inoltre, spesso evito di mutare valori e variabili, un altro concetto preso in prestito da FP.

Entrambe queste tecniche funzionano bene in Python e in altre lingue che non sono comunemente classificate come funzionali. Spesso sono persino supportati dal linguaggio stesso (ovvero finalvariabili in Java). Pertanto, i futuri programmatori di manutenzione non dovranno affrontare un'enorme barriera per comprendere il codice.

Abbiamo avuto la stessa discussione su un'azienda per cui ho lavorato l'anno scorso.

La discussione riguardava il "codice magico" e se doveva essere incoraggiato o meno. Se lo guardiamo un po 'di più, sembra che le persone abbiano opinioni molto diverse su quello che in realtà era un "codice magico". Quelli che hanno sollevato la discussione sembravano significare soprattutto che le espressioni (in PHP) che utilizzavano lo stile funzionale erano "codice magico", mentre gli sviluppatori che avevano origine da altri linguaggi che usavano più stile FP nel loro codice sembrano pensare che il codice magico fosse piuttosto quando hai effettuato l'inclusione dinamica di file tramite nomi di file e così via.

Non siamo mai giunti a una buona conclusione su questo, più di quanto la gente pensi che il codice che sembra sconosciuto sia "magico" o difficile da leggere. Quindi è una buona idea evitare il codice che non sembra familiare ad altri utenti? Penso che dipenda da dove viene utilizzato. Vorrei astenermi dall'utilizzare espressioni in stile fp (inclusione dinamica di file e così via) in un metodo principale (o parti centrali importanti delle applicazioni) in cui i dati dovrebbero essere tunnel in modo chiaro e di facile lettura, intuitivo. D'altra parte, non penso che uno dovrebbe avere paura di spingere la busta, gli altri sviluppatori probabilmente impareranno rapidamente FP se si trovano ad affrontare il codice FP e forse hanno qualche buona risorsa interna per consultare i problemi.

TL; DR: evitare nella parte centrale di alto livello delle applicazioni (che devono essere lette per una panoramica della funzionalità dell'applicazione). Altrimenti usalo.

La comunità C ++ ha recentemente ottenuto anche lambda, e credo che abbiano più o meno la stessa domanda. La risposta potrebbe non essere la stessa, però. L'equivalente in C ++ sarebbe:

std::copy_if(measures.begin(), measures.end(), inserter(filter),
  [dur](Item i) { return included(i, dur) } );

Ora std::copynon è nuovo e neanche le _ifvarianti sono nuove, ma lo è lambda. Eppure è definito piuttosto chiaramente nel contesto: durè acquisito e quindi costante, Item ivaria nel ciclo e la singola returnistruzione fa tutto il lavoro.

Questo sembra accettabile per molti sviluppatori C ++. Tuttavia, non ho raccolto opinioni sulle lambda di ordine superiore e mi aspetterei molto meno accettazione.

Pubblica uno snippet di codice a un altro sviluppatore che non è fluente in Python e chiedigli se può passare 5 minuti a controllare il codice per vedere se lo capisce.

Se sì, probabilmente sei a posto. In caso contrario, dovresti cercare di renderlo più chiaro.

Il tuo collega potrebbe essere sciocco e non capire qualcosa che dovrebbe essere ovvio? Sì, ma dovresti sempre programmare secondo KISS.

Forse il tuo codice è più efficiente / bello / elegante di un approccio più semplice, a prova di idiota? Quindi devi chiederti: devo fare questo? Ancora una volta, se la risposta è no, allora non farlo!

Se dopo tutto questo, pensi ancora di aver bisogno e vuoi farlo nel modo FP, allora fallo sicuramente. Fidati del tuo istinto, sono più adatti alle tue esigenze rispetto alla maggior parte delle persone su qualsiasi forum :)