La programmazione funzionale aggiunge complessità al codice? [chiuso]

Per tutto l'anno passato ho scritto il codice Scala (proveniente da un background Java). Mi è piaciuto molto come potresti creare un codice più semplice e più pulito, con vals, classi di case, funzioni map / filter / lambda, impliciti e inferenza del tipo. L'ho usato principalmente per un'applicazione basata su Akka .

Quest'anno sono su un progetto Scala con un nuovo team, a cui piace molto la programmazione funzionale. Usano pesantemente Scalaz e il codice è riempito ovunque di applicativi, limiti di contesto, lettore / scrittore / monade di stato, anche il metodo principale è "avvolto" in una monade I / O. Il loro ragionamento è che questo fa sì che il compilatore "funzioni per noi" affermando che il codice è corretto e che ogni funzione è priva di effetti collaterali.

Anche così, dal mio punto di vista tutta questa sintassi interferisce davvero con la logica aziendale. Ad esempio, un tipo di "MyBusinessObject" va bene, così come tipi come "Elenco [MyBusinessObject]", "Opzione [MyBusinessObject]" o anche "Future [MyBusinessObject]". Tutti hanno un significato e uno scopo chiari. D'altra parte, codice come:

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

aggiunge complessità al programma o sono solo io che non sono abituato a questo modo di programmare?

Questo non ha nulla a che fare con la programmazione funzionale - è possibile trovare questo tipo di situazione nel contesto di qualsiasi altro linguaggio di programmazione - gli sviluppatori che amano così tanto i costrutti avanzati del "loro" linguaggio da ignorare qualsiasi senso comune di leggibilità e semplicità. Ho riscontrato una situazione del genere in C, C ++, Perl, Java, C #, Basic e altri linguaggi non funzionali. Non è la programmazione funzionale che aggiunge complessità al codice, come fanno i programmatori.

Non fraintendetemi, non consiglio di evitare funzionalità linguistiche avanzate, ma è importante trovare il giusto equilibrio in un determinato contesto. Quando si scrive una libreria generica per l'utilizzo di> 100.000 sviluppatori in tutto il mondo, ci sono diverse misure da applicare come quando si sta scrivendo un singolo generatore di report solo per l'ufficio locale.

Direi che non ti sei abituato al modo in cui codificano è almeno parte dell'immagine. Sono in una situazione simile alla tua (vengo da C # in F # e lavoro con persone con background Haskell), e mentre la trovo un'esperienza interessante, ho dei momenti in cui sbatto la testa contro il muro, districando un composizione di funzioni senza punti particolarmente contorta solo per capire cosa sta succedendo lì. È una cosa culturale.

Non so se questo particolare codice aggiunga complessità al programma. Concordato che un pezzo generico di codice può essere complesso stesso. Ma è un'utilità, non una parte della logica aziendale. Se vuoi sapere se rende la base di codice più complessa o più semplice, dovresti immaginare come dovrebbe apparire senza quel pezzo di codice. È spesso il caso di costrutti così generici che sono essi stessi complessi, ma è una complessità che puoi adattare su un singolo schermo. Allo stesso tempo, rendono l'intera base di codice un po 'più semplice. Questo è particolarmente vero per le monadi.

Inoltre, può anche essere un caso di "arte per l'arte", come suggerisce @ Brown Brown. Non posso escluderlo neanche.

Direi che in generale la programmazione funzionale riduce la complessità eliminando lo stato mutabile, riducendo così il numero di casi che devono essere considerati quando si cerca di capire come funziona una sezione di codice.

Tuttavia, la programmazione funzionale rende possibili gradi più elevati di astrazione e, sebbene un codice altamente astratto possa essere estremamente utile, può anche essere difficile da capire perché è per definizione divorziato dal contesto che normalmente useresti per guidare la tua comprensione. Il tuo commento "Tutti hanno un significato e uno scopo chiari" sugli oggetti di business è senza dubbio vero, ma è in realtà un riflesso del fatto che quella logica è molto specifica per un'esigenza e un contesto che già capisci. L'esistenza di un costrutto come Monade ti consente di fare qualcosa di molto utile con poco sforzo, ma il web è disseminato di pagine che cercano di spiegare cos'è una Monade. Questa è astrazione per te.

Inoltre, Scalaz è stato scritto da persone che avevano mangiato e respirato FP per lungo tempo; volevano portare la funzionalità disponibile in Haskell alla Scala. In tal modo non fecero alcun tentativo di essere pedagogici. Scalaz fa uso di un vocabolario e di uno stile che sembrano chiari e chiari per gli autori ma estranei ai non iniziati. I metodi che sono sconcertanti per il resto di noi sembravano così ovvi agli autori, dato il loro background di Haskell, che non meritavano nemmeno un commento.

Inoltre, come linguaggio di programmazione funzionale Scala ha alcune carenze (in parte perché la JVM ha carenze) che hanno costretto gli autori di Scalaz a scrivere codice più brutto in alcuni casi. Ad esempio, la mancanza di eliminazione generale delle chiamate di coda impone l'uso di trampolini in alcuni codici e la mancanza di un "sistema di tipo" può complicare le firme di tipo.

E infine, Scalaz fa un grande uso di se stesso. Questo potrebbe essere pensato come un segno del suo potere, ma per chi non lo sapesse può trasformare la fonte in un enigma - qualsiasi pezzo di codice casuale che guardi probabilmente farà uso di qualcos'altro che ti sembra estraneo.

Tenere duro. E questo potrebbe aiutare.

Aggiunge complessità al programma o è solo che non sei abituato a questo modo di programmare?

Perché pensi che queste possibilità non siano la stessa cosa?

Il codice ben scritto può essere letto da persone che non hanno familiarità con il linguaggio di programmazione specifico. Alcune lingue (BASIC, Pascal, ecc.) Possono essere lette e comprese da bambini che non hanno mai visto linguaggi di programmazione prima d'ora.

Se qualcuno che ha esperienza con altre lingue ed esperienza con Scala (e che presumo abbia lavorato con Scalaz per almeno una settimana e abbia colleghi per spiegare le cose più difficili) è ancora confuso; allora questa è la prova che ha aggiunto complessità.