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

17

Per tutto l'anno scorso ho scritto il codice Scala (proveniente da uno sfondo Java) . Mi è piaciuto molto il modo in cui è possibile creare codice più semplice e più pulito, con vals, case classes, funzioni map / filter / lambda, impliciti e inferenza del tipo. L'ho usato principalmente per un'applicazione Akka .

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

Anche così, dal mio punto di vista tutta questa sintassi interferisce con la logica del business. Ad esempio, un tipo di "MyBusinessObject" va bene, così come tipi "List [MyBusinessObject]", "Option [MyBusinessObject]" o anche "Future [MyBusinessObject]". Hanno tutti 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 programmazione?

    
posta Luciano 04.04.2014 - 07:14
fonte

4 risposte

36

Questo ha niente da fare con la programmazione funzionale - puoi trovare questo tipo di situazione nel contesto di qualsiasi altro linguaggio di programmazione - sviluppatori che amano i costrutti avanzati della "loro" lingua così tanto da ignorarli qualsiasi buon senso riguardo alla leggibilità e alla semplicità. Ho riscontrato una situazione simile in C, C ++, Perl, Java, C #, Basic e altri linguaggi non funzionali. Non è una programmazione funzionale che aggiunge complessità al codice - i programmatori lo fanno.

Non fraintendermi, non è consigliabile evitare funzionalità linguistiche avanzate, ma è importante trovare il giusto equilibrio nel contesto dato. 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 scrive un singolo generatore di report solo per l'ufficio locale.

    
risposta data 04.04.2014 - 07:48
fonte
7

Direi che non ti sei abituato al modo in cui codificano è almeno una parte dell'immagine. Sono in una situazione simile, come si (proveniente da C # in F # e lavorare con le persone con Haskell sfondo), e mentre lo trovo un'esperienza interessante, io ho momenti in cui mi sto sbattendo la testa contro il muro, districare un composizione di funzione point-free particolarmente contorta, solo per capire cosa sta succedendo lì. È una cosa culturale.

Per quanto riguarda se questo particolare codice aggiunge complessità al programma - non lo so. Concordato che un codice generico può essere complesso. 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 tali costrutti generici che sono complessi essi stessi, ma è una complessità che è possibile inserire su un singolo schermo. Nello stesso tempo rendono l'intero codebase un po 'più semplice. Questo è particolarmente il caso delle monadi.

Inoltre, può anche essere un caso di "arte per l'arte", come suggerisce @Doc Brown. Neanche è possibile escluderlo.

    
risposta data 04.04.2014 - 09:37
fonte
5

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 livelli più elevati di astrazione e, sebbene il codice altamente astratto possa essere estremamente utile, può anche essere difficile da comprendere perché è per definizione separato dal contesto che utilizzeresti normalmente per guidare la tua comprensione. Il tuo commento "Hanno tutti un significato e uno scopo chiari" riguardo agli oggetti di business è indubbiamente vero, ma è in realtà un riflesso del fatto che quella logica è molto specifica per un bisogno e un contesto che già comprendi. L'esistenza di un costrutto come Monad ti permette di creare qualcosa di molto utile con poco sforzo, ma il web è disseminato di pagine che cercano di spiegare cos'è una Monade. Questa è l'astrazione per te.

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

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

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 casuale di codice che si guarda può usare qualcos'altro che ti sembra estraneo.

Aspetta qui. E questo potrebbe aiutare.

    
risposta data 04.04.2014 - 17:58
fonte
-3

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

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 dagli scolari che non hanno mai visto alcun linguaggio di programmazione.

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

    
risposta data 04.04.2014 - 14:11
fonte

Leggi altre domande sui tag