La programmazione funzionale aumenta il "divario rappresentativo" tra problemi e soluzioni? [chiuso]

Poiché il linguaggio macchina (ad es. 0110101000110101) , I linguaggi dei computer si sono generalmente evoluti in forme più elevate di astrazione, rendendo generalmente più semplice la comprensione del codice quando viene applicato a un problema. L'assemblatore era un'astrazione sul codice della macchina, C era un'astrazione sull'assemblatore, ecc.

Il design orientato agli oggetti sembra essere molto bravo nel permetterci di modellare un problema in termini di oggetti, ad esempio, il problema di un sistema di registrazione dei corsi universitari può essere modellato con una Courseclasse, una Studentclasse, ecc. Quindi, quando scriviamo la soluzione in un linguaggio OO, abbiamo classi simili che assumono responsabilità e che generalmente sono utili per la progettazione, specialmente per la modularizzazione del codice. Se do questo problema a 10 team indipendenti che lo risolvono con un metodo OO, in genere le 10 soluzioni avranno le classi relative al problema in comune. Ci possono essere molte differenze quando inizi a entrare nell'accoppiamento e nelle interazioni di quelle classi, quindi non esiste nulla come "zero gap rappresentazionale".

La mia esperienza con la programmazione funzionale è molto limitata (nessun utilizzo nel mondo reale, solo programmi di tipo Hello World). Non riesco a vedere come tali lingue consentano di mappare facilmente le soluzioni FP ai problemi (con un basso gap rappresentativo) come fanno le lingue OO.

Comprendo i vantaggi di FP rispetto alla programmazione concorrente. Ma mi sto perdendo qualcosa o FP non sta riducendo il gap rappresentativo (rendendo le soluzioni più facili da capire)?

Un altro modo per chiederlo: il codice FP di 10 team diversi che risolvono lo stesso problema del mondo reale avrebbe molto in comune?

Da Wikipedia on Abstraction (informatica) (sottolineatura mia):

I linguaggi di programmazione funzionale mostrano comunemente astrazioni legate a funzioni , come le astrazioni lambda (trasformare un termine in una funzione di una variabile), funzioni di ordine superiore (i parametri sono funzioni), astrazione di parentesi (trasformare un termine in una funzione di una variabile).

Il divario rappresentazionale potrebbe essere potenzialmente aumentato, perché [alcuni] problemi del mondo reale non sono facilmente modellabili con tali astrazioni.

Un altro modo in cui vedo diminuire il divario rappresentativo è nel rintracciare gli elementi della soluzione al problema. Il 0s e' 1s in codice macchina è molto difficile da risalire, mentre la Studentclasse è facile tornare traccia. Non tutte le classi OO tracciano facilmente nello spazio del problema, ma molti lo fanno.

Le astrazioni FP non devono sempre essere spiegate per scoprire quale parte dello spazio problematico stanno risolvendo (a parte i problemi matematici )?OK - Sto bene in questa parte. Dopo aver esaminato molti altri esempi, vedo come le astrazioni di FP siano molto chiare per parti del problema che sono espresse nell'elaborazione dei dati.

La risposta accettata a una domanda correlata È possibile utilizzare UML per modellare un programma funzionale? - dice "I programmatori funzionali non hanno molto da usare per i diagrammi". Non mi interessa davvero se si tratta di UML, ma mi chiedo se le astrazioni di FP siano facili da capire / comunicare, se non ci sono diagrammi ampiamente utilizzati (supponendo che questa risposta sia corretta). Ancora una volta, il mio livello di utilizzo / comprensione del FP è banale, quindi non capisco la necessità di diagrammi su semplici programmi FP.

Il design OO ha funzioni / classe / livelli di pacchetto di astrazione, con incapsulamento (controllo degli accessi, occultamento delle informazioni) a ciascuno, che semplifica la gestione della complessità. Questi sono elementi che consentono di passare dal problema alla soluzione e viceversa.

Molte risposte parlano di come l'analisi e la progettazione sono fatte in FP in un modo analogo a OO, ma nessuno cita nulla di alto livello finora (Paul ha citato alcune cose interessanti, ma è di basso livello). Ieri ho fatto molte ricerche su Google e ho trovato alcune discussioni interessanti. Quanto segue è tratto da Refactoring Functional Programs di Simon Thompson (2004) (sottolineatura mia)

Nel progettare un sistema orientato agli oggetti, è scontato che il progetto precederà la programmazione. I progetti verranno scritti utilizzando un sistema come UML supportato da strumenti come Eclipse. I programmatori principianti possono imparare un approccio alla progettazione visiva usando sistemi come BlueJ. Il lavoro su una metodologia simile per la programmazione funzionale è riportato in FAD: Functional Analysis and Design , ma esiste poco altro lavoro. Potrebbero esserci diverse ragioni per questo.

• I programmi funzionali esistenti hanno una scala che non richiede progettazione. Molti programmi funzionali sono piccoli, ma altri, come il compilatore Haskell di Glasgow, sono sostanziali.

• I programmi funzionali modellano direttamente il dominio dell'applicazione, rendendo in tal modo irrilevante il design. Mentre i linguaggi funzionali forniscono una varietà di potenti astrazioni, è difficile sostenere che questi forniscano tutte e solo le astrazioni necessarie per modellare il mondo reale.

• I programmi funzionali sono costruiti come una serie in evoluzione di prototipi.

Nella tesi di dottorato sopra citata , i vantaggi dell'utilizzo di Metodologie di analisi e progettazione (ADM) sono delineati indipendentemente dai paradigmi. Ma si sostiene che gli ADM dovrebbero allinearsi al paradigma di implementazione. Cioè, OOADM funziona meglio per la programmazione OO e non è ben applicato a un altro paradigma come FP. Ecco una grande citazione che penso parafrasasse quello che chiamo gap rappresentativo:

si può discutere a lungo su quale paradigma fornisce il miglior supporto per lo sviluppo del software, ma si ottiene il pacchetto di sviluppo più naturale, efficiente ed efficace quando si rimane all'interno di un singolo paradigma dalla descrizione del problema fino all'implementazione e alla consegna.

Ecco la serie di diagrammi proposti da FAD:

• diagrammi di dipendenza delle funzioni che presentano una funzione con quelli che utilizza nella sua implementazione;
• diagramma di dipendenza del tipo che fornisce lo stesso servizio per i tipi; e,
• diagrammi di dipendenza del modulo che presentano viste dell'architettura del modulo del sistema.

C'è un caso di studio nella sezione 5.1 della tesi FAD, che è un sistema per automatizzare la produzione di dati relativi a un campionato di calcio (calcio). I requisiti sono funzionali al 100%, ad es. Immissione di risultati calcistici, produzione di classifiche, tabelle dei punteggi, tabelle delle presenze, trasferimento dei giocatori tra squadre, aggiornamento dei dati dopo nuovi risultati, ecc. , oltre a dichiarare che "le nuove funzionalità dovrebbero essere consentite a un costo minimo", qualcosa che è quasi impossibile da testare.

Purtroppo, a parte FAD, non vedo riferimenti moderni per i linguaggi di modellazione (visivi) proposti per FP. UML è un altro paradigma, quindi dovremmo dimenticarlo.

I dati di base sono strutturati allo stesso modo in quasi tutti i paradigmi. Avrai a Student, a Course, ecc., Che si tratti di un oggetto, una struttura, un disco o altro. La differenza con OOP non è come sono strutturati i dati, è come sono strutturate le funzioni.

In realtà trovo che i programmi funzionali siano molto più simili a come penso a un problema. Ad esempio, per pianificare il programma di uno studente per il prossimo semestre, pensi a cose come elenchi di corsi che uno studente ha completato, corsi in un corso di laurea, corsi offerti in questo semestre, corsi a cui uno studente ha completato i prerequisiti, corsi con orari che conflitto, ecc.

Improvvisamente, non è così chiaro quale classe dovrebbe creare e archiviare tutti questi elenchi. Ancor meno quando si hanno combinazioni complesse di questi elenchi. Tuttavia, devi scegliere una classe.

In FP, scrivi funzioni che accettano uno studente e un elenco di corsi e restituiscono un elenco filtrato di corsi. È possibile raggruppare tutte queste funzioni in un modulo. Non è necessario abbinarlo a una classe o all'altra.

Quindi i tuoi modelli di dati finiscono per assomigliare di più a come i programmatori OOP pensano ai loro modelli, prima che vengano inquinati con classi che non hanno altro scopo se non quello di fornire spazi convenienti per mettere funzioni che operano su combinazioni di altre classi. Nessuna lezione strana CourseStudentFilterListo simile di cui hai sempre bisogno in OOP, ma non pensare mai al progetto iniziale.

Quando ho preso la mia classe Java anni fa, ci aspettavamo di mostrare le nostre soluzioni all'intera classe, quindi ho potuto vedere come la gente pensa; come risolvono i problemi logicamente. Mi aspettavo che le soluzioni si raggruppassero in tre o quattro soluzioni comuni. Invece, ho visto come 30 studenti hanno risolto il problema in 30 modi completamente diversi.

Naturalmente, man mano che i programmatori alle prime armi acquisiscono esperienza, acquisiranno esposizione a schemi software comuni, inizieranno a utilizzare tali schemi nel loro codice e quindi le loro soluzioni potrebbero fondersi su alcune strategie ottimali. Questi schemi formano un linguaggio tecnico attraverso il quale gli sviluppatori esperti possono comunicare.

Il linguaggio tecnico alla base della programmazione funzionale è la matematica . Di conseguenza, i problemi più adatti a risolvere utilizzando la programmazione funzionale sono essenzialmente problemi matematici. In matematica, non mi riferisco al tipo di matematica che vedresti nelle soluzioni aziendali, come addizione e sottrazione. Piuttosto, sto parlando del tipo di matematica che potresti vedere su Math Overflow o del tipo di matematica che vedresti nel motore di ricerca di Orbitz (è scritto in Lisp).

Questo orientamento ha alcune importanti conseguenze per i programmatori funzionali che cercano di risolvere i problemi di programmazione del mondo reale:

1. La programmazione funzionale è più dichiarativa che imperativa; si occupa principalmente di dire al computer cosa fare, non come farlo.

2. I programmi orientati agli oggetti sono spesso costruiti dall'alto verso il basso. Viene creato un progetto di classe e i dettagli vengono compilati. I programmi funzionali sono spesso costruiti dal basso verso l'alto, a partire da piccole funzioni dettagliate che vengono combinate in funzioni di livello superiore.

3. La programmazione funzionale può avere vantaggi per la prototipazione di logiche complesse, la costruzione di programmi flessibili che possono cambiare ed evolversi organicamente e la creazione di software in cui la progettazione iniziale non è chiara.

4. I programmi orientati agli oggetti possono essere più adatti ai domini aziendali poiché le classi, i messaggi tra gli oggetti e i modelli software forniscono tutti una struttura che si associa al dominio aziendale, acquisisce la sua business intelligence e lo documenta.

5. Poiché tutto il software pratico produce effetti collaterali (I / O), i linguaggi di programmazione puramente funzionali richiedono un meccanismo per produrre tali effetti collaterali pur rimanendo matematicamente puri (monadi).

6. I programmi funzionali possono essere dimostrati più facilmente, a causa della loro natura matematica. Il sistema di tipi di Haskell può trovare cose in fase di compilazione che la maggior parte delle lingue OO non riesce.

E così via. Come per molte cose nel campo dell'informatica, i linguaggi orientati agli oggetti e i linguaggi funzionali hanno diversi compromessi.

Alcuni moderni linguaggi OO hanno adottato alcuni degli utili concetti di programmazione funzionale, in modo da poter avere il meglio di entrambi i mondi. Linq e le funzionalità del linguaggio che sono state aggiunte per supportarlo, ne sono un buon esempio.

Vorrei sottolineare un aspetto che ritengo importante e che non è stato trattato nelle altre risposte.

Prima di tutto, penso che il divario rappresentativo tra problemi e soluzioni possa essere più nella mente del programmatore, in base al loro background e ai concetti con cui hanno più familiarità.

OOP e FP esaminano i dati e le operazioni da due diverse prospettive e offrono diversi compromessi, come già sottolineato da Robert Harvey.

Un aspetto importante in cui differiscono è il modo in cui consentono di estendere il software.

Considera la situazione in cui hai una raccolta di tipi di dati e una raccolta di operazioni, ad esempio hai diversi formati di immagine e mantieni una libreria di algoritmi per elaborare le immagini.

La programmazione funzionale semplifica l'aggiunta di nuove operazioni al software: è necessaria solo una modifica locale nel codice, in particolare si aggiunge una nuova funzione, che gestisce diversi formati di dati di input. D'altro canto, l'aggiunta di nuovi formati è più complessa: è necessario modificare tutte le funzioni già implementate (modifica non locale).

L'approccio orientato agli oggetti è simmetrico a questo: ogni tipo di dati porta la propria implementazione di tutte le operazioni ed è responsabile della scelta della corretta implementazione in fase di esecuzione (dispacciamento dinamico). Ciò semplifica l'aggiunta di un nuovo tipo di dati (ad esempio un nuovo formato di immagine): basta aggiungere una nuova classe e implementare tutti i suoi metodi. D'altra parte, aggiungere una nuova operazione significa cambiare tutte le classi che devono fornire quell'operazione. In molte lingue ciò avviene estendendo un'interfaccia e adattando tutte le classi che la implementano.

Questo diverso approccio all'estensione è uno dei motivi per cui OOP è più appropriato per alcuni problemi in cui l'insieme di operazioni varia meno spesso dell'insieme di tipi di dati su cui queste operazioni funzionano. Un esempio tipico sono le GUI: si dispone di un insieme fisso di operazioni che tutti i widget devono implementare ( paint, resize, movee così via) e una raccolta di widget che si desidera estendere.

Quindi, secondo questa dimensione, OOP e FP sono solo due modi speculari per organizzare il tuo codice. Vedere SICP , in particolare la Sezione 2.4.3, la Tabella 2.22 e il passaggio del messaggio di paragrafo .

Riassumendo: in OOP si utilizzano i dati per organizzare le operazioni, in FP si utilizzano le operazioni per organizzare i dati. Ogni approccio è più forte o più debole in base al contesto. In generale, nessuno dei due ha un divario rappresentativo più elevato tra problema e soluzione.

La maggior parte dei linguaggi funzionali non sono orientati agli oggetti. Ciò non significa che non abbiano oggetti (nel senso di tipi complessi a cui sono associate funzionalità specifiche). Haskell, come Java, ha liste, mappe, array, tutti i tipi di alberi e molti altri tipi complessi. Se guardi il modulo Haskell List o Map vedrai un insieme di funzioni molto simili ai metodi nella maggior parte dei moduli di libreria in linguaggio OO equivalenti. Se ispezioni il codice, troverai persino incapsulamenti simili, con alcuni tipi (o i loro costruttori, per la precisione) e funzioni utilizzabili solo da altre funzioni nel modulo.

Il modo in cui lavori con questi tipi in Haskell è spesso poco diverso dal modo OO. In Haskell dico

  null xs
  length xs

e in Java dici

  xs.isEmpty
  xs.length

Pomodoro, Pomodoro. Le funzioni di Haskell non sono legate all'oggetto ma sono strettamente associate al suo tipo. "Ah, ma ," dici, "in Java sta chiamando quale metodo di ogni lunghezza sia appropriato alla classe effettiva di quell'oggetto". Sorpresa - Haskell fa anche il polimorfismo con le classi di tipi (e altre cose).

In Haskell, se ho è - una raccolta di numeri interi - non importa se la collezione è una lista o un set o un array, questo codice

  fmap (* 2) is

restituirà una raccolta con tutti gli elementi raddoppiati. Polimorfismo significa che verrà chiamata la funzione di mappa appropriata per il tipo specifico.

Questi esempi sono, in verità, tipi non molto complessi ma lo stesso vale per problemi più difficili. L'idea che i linguaggi funzionali non ti permettano di modellare oggetti complessi e di associare loro funzionalità specifiche è semplicemente sbagliata.

Ci sono differenze importanti e significative tra lo stile funzionale e quello OO, ma non credo che questa risposta debba occuparsene. Hai chiesto se i linguaggi funzionali impediscono (o ostacolano) la modellazione intuitiva di problemi e attività. La risposta è no.

FP si impegna davvero a ridurre il divario rappresentativo:

Qualcosa che vedrai molto nei linguaggi funzionali è la pratica di costruire il linguaggio su (usando la progettazione bottom-up) in un linguaggio specifico del dominio incorporato (EDSL) . Ciò ti consente di sviluppare un mezzo per esprimere le tue preoccupazioni aziendali in modo naturale per il tuo dominio all'interno del linguaggio di programmazione. Haskell e Lisp sono entrambi orgogliosi di questo.

Parte (se non tutto) di ciò che abilita questa capacità è maggiore flessibilità ed espressività all'interno del linguaggio o dei linguaggi di base stessi; con funzioni di prima classe, funzioni di ordine superiore, composizione delle funzioni e, in alcune lingue, tipi di dati algebrici (sindacati discriminati AKA) e capacità di definire operatori *, c'è più flessibilità disponibile su come esprimere le cose di quanto non ci sia con OOP, che significa che probabilmente troverai modi più naturali per esprimere le cose dal tuo dominio problematico. (Dovrebbe dire qualcosa che molte lingue OOP hanno recentemente adottato molte di queste funzionalità, se non iniziando con esse.)

_{* Sì, in molte lingue OOP è possibile sovrascrivere gli operatori standard, ma in Haskell è possibile definirne di nuovi!}

Nella mia esperienza di lavoro con linguaggi funzionali (principalmente F # e Haskell, alcuni Clojure e un po 'di Lisp ed Erlang), ho più tempo a mappare lo spazio del problema nella lingua rispetto a OOP, specialmente con tipi di dati algebrici, che trovo più flessibile delle lezioni. Qualcosa che mi ha lasciato senza fiato quando ho iniziato con FP, in particolare con Haskell, era che dovevo pensare / lavorare a un livello leggermente più alto di quello a cui ero abituato in linguaggi imperativi o OOP; potresti anche imbatterti in questo.

Come diceva Niklaus Wirth, "Algorithms + Data Structures = Programs". La programmazione funzionale riguarda il modo di organizzare gli algoritmi e non dice molto sui modi di organizzare le strutture di dati. In effetti, esistono linguaggi FP sia con variabili mutabili (Lisp) che immutabili (Haskell, Erlang). Se vuoi confrontare e confrontare FP con qualcosa, dovresti scegliere la programmazione imperativa (C, Java) e dichiarativa (Prolog).

OOP è d'altra parte un modo per costruire strutture di dati e collegarvi algoritmi. FP non ti impedisce di costruire strutture di dati simili a quelle OOP. Se non mi credi, dai un'occhiata alle dichiarazioni sul tipo di Haskell. Tuttavia, la maggior parte dei linguaggi FP concordano sul fatto che le funzioni non appartengono alle strutture dati e dovrebbero piuttosto trovarsi nello stesso spazio dei nomi. Questo viene fatto al fine di semplificare la costruzione di nuovi algoritmi tramite la composizione delle funzioni. In effetti, se sai quale input riceve una funzione e quale output produce, perché dovrebbe importare anche a quale struttura di dati appartiene? Ad esempio, perché la addfunzione deve essere chiamata su un'istanza di tipo Integer e ha passato un argomento invece di passare semplicemente due argomenti Integer?

Pertanto, non vedo perché FP dovrebbe rendere le soluzioni più difficili da comprendere in generale, e non penso che lo faccia comunque. Tuttavia, tieni presente che un programmatore imperativo esperto troverà sicuramente programmi funzionali più difficili da comprendere rispetto a quelli imperativi, e viceversa. Questo è simile alla dicotomia Windows - Linux quando le persone che hanno investito 10 anni per familiarizzare con l'ambiente Windows trovano Linux difficile dopo un mese di utilizzo e coloro che sono abituati a Linux non possono raggiungere la stessa produttività in Windows. Quindi, il "divario rappresentazionale" di cui stai parlando è molto soggettivo.