Introduzione di costrutti di programmazione funzionale in linguaggi di programmazione non funzionali

5

Questa domanda mi è passata molto spesso in mente e poiché non ho trovato una risposta convincente mi piacerebbe sapere se altri utenti di questo sito hanno pensato anche a questo.

Negli ultimi anni, anche se OOP è ancora il paradigma di programmazione più popolare, la programmazione funzionale sta ricevendo molta attenzione. io ho solo ho usato le lingue OOP per il mio lavoro (C ++ e Java) ma sto cercando di imparare un po ' FP nel mio tempo libero perché lo trovo molto interessante.

Quindi, ho iniziato ad imparare Haskell tre anni fa ea Scala la scorsa estate. Ho intenzione di impara anche SML e Caml e rispolvera la mia (piccola) conoscenza di Scheme. Bene, molti piani (troppo ambiziosi?) Ma spero di trovare il tempo per imparare almeno le basi della FP durante i prossimi anni. Ciò che è importante per me è come funziona la programmazione funzionale e come / se Posso usarlo per alcuni progetti reali. Ho già sviluppato piccoli strumenti in Haskell.

Nonostante il mio strong interesse per la FP, trovo difficile capire perché i costrutti di programmazione funzionale vengono aggiunti a linguaggi come C #, Java, C ++ e così via. Come sviluppatore interessato a FP, lo trovo più naturale usa, ad esempio, Scala o Haskell, invece di aspettare la prossima funzione FP da aggiungere al mio linguaggio non FP preferito. In altre parole, perché dovrei avere solo alcuni FP nel mio originale linguaggio non FP, invece di cercare una lingua che abbia un supporto migliore per FP?

Per esempio, perché dovrei essere interessato ad avere lambda in Java se posso cambiare in Scala dove ho molti più concetti di FP e accesso a tutte le librerie Java Comunque? Allo stesso modo: perché alcuni FP in C # invece di usare F # (per quanto ne so, C # e F # possono lavorare insieme )?

Java è stato progettato per essere OO. Belle. Posso fare OOP in Java (e mi piacerebbe continuare a usare Java in questo modo). Scala è stato progettato per supportare OOP + FP. Bene: posso usare un mix di OOP e FP in Scala. Haskell è stato progettato per FP: posso fare FP in Haskell. Se ho bisogno di sintonizzare le prestazioni di un particolare modulo, posso interfaccia Haskell con alcune routine esterne in C

Ma perché dovrei voler fare OOP con solo alcuni basic FP in Java?

Quindi, il mio punto principale è: perché i linguaggi di programmazione non funzionali vengono estesi con il concetto funzionale alcuni ? Non dovrebbe essere più comodo (interessante, eccitante, produttivo) per programma in un linguaggio che è stato progettato fin dall'inizio a essere funzionale o multi-paradigma? Non diversi paradigmi di programmazione integrare meglio in un linguaggio che è stato progettato per esso rispetto a una lingua in cui un paradigma è stato aggiunto solo più tardi?

La prima spiegazione a cui potrei pensare è quella, dal momento che FP è un nuovo concetto (non è affatto nuovo, ma è nuovo per molti sviluppatori), deve essere introdotto gradualmente. Tuttavia, ricordo il mio passaggio da imperativo a OOP: quando ho iniziato a programmare in C ++ (proveniente da Pascal e C), dovevo davvero farlo ripensare il modo in cui stavo codificando e farlo abbastanza velocemente. Non è stato graduale. Quindi, questa non sembra essere una buona spiegazione per me.

Oppure può essere che molti programmatori non FP non siano realmente interessati capire e utilizzare la programmazione funzionale, ma la trovano praticamente comodo adottare alcuni idiomi FP nel loro linguaggio non FP?

NOTA IMPORTANTE

Nel caso in cui (perché ho visto diverse guerre di lingue su questo sito): Ho menzionato le lingue che conosco meglio, questa domanda non è in alcun modo pensato per avviare confronti tra diverse programmazioni le lingue per decidere quale è migliore / peggiore.

Inoltre, non mi interessa un confronto tra OOP e FP (pro e contro). Il punto che mi interessa è capire perché FP è stato introdotto un po 'alla volta in linguaggi esistenti che non sono stati progettati per questo anche se esistono linguaggi che sono / sono specificamente progettati per supportare FP.

    
posta Giorgio 30.03.2012 - 01:03
fonte

5 risposte

9

Nonostante alcune idee specifiche da parte dei progettisti di linguaggi, si dice che autori e amministratori dei linguaggi di programmazione stanno, alla fine, spingendo un prodotto. Quindi, potrei chiedere perché vorrei un telefono con fotocamera quando il mio telefono normale è un telefono migliore e la mia macchina fotografica una fotocamera migliore, ma ciò non impedirà ai produttori di entrambi i dispositivi di tentare di ampliare l'offerta dei loro prodotti per attrarre nuovi clienti.

Dopo averlo guardato da quella prospettiva, le nozioni di preservare l'integrità della lingua originale diventano una questione di gradi e compromessi. Se sono l'autore del linguaggio OOP AwesomeCode e vedo persone che iniziano a interessarsi al nuovo FCode del linguaggio funzionale, devo dire ai miei utenti "scusate, ma questo è solo un linguaggio OOP" e rischiano di andare a C # invece di arrivare a i suoi lambas, o faccio a pezzi e a malincuore, includono alcune funzionalità di FCode?

    
risposta data 30.03.2012 - 01:10
fonte
3

Dai un'occhiata a LINQ: non sarebbe possibile senza quelle alcune funzioni FP, mentre nasconde tutte le cose spaventose di FP sotto il cofano.

Le funzionalità FP sono molto utili per coloro che implementano librerie e framework un po 'complicati - non è ragionevole usare un linguaggio diverso per queste cose. " End users ", tutti i programmatori di media impresa, non avranno bisogno di sapere nulla di quelle caratteristiche arcane, ma sono felici di usare le librerie costruite su estensioni FP.

    
risposta data 30.03.2012 - 10:33
fonte
2

Gli stili di programmazione puramente funzionali hanno seri problemi di input / output. Ecco perché la maggior parte dei linguaggi funzionali non è pura e Haskell che ha ... intimidisce le tecniche di I / O. Tutto ciò che richiede un aggiornamento distruttivo come la grafica, ad esempio, è più difficile da fare in lingue funzionali.

I costrutti funzionali vengono aggiunti alle lingue tradizionali per tre ragioni principali:

  1. Pattern Matching: i linguaggi funzionali hanno tipicamente una sintassi estremamente compatta per gestire la corrispondenza dei pattern. Python ha sfumature di questo con le sue dichiarazioni. Questo si rivela molto utile in cose come il Data Mining.

  2. Programmazione generica / Metaprogrammazione: entrambi migliorano enormemente l'adattabilità del codice consentendo a un programma di essere più flessibile o di modificarsi mentre procede. Questo può essere estremamente importante in AI.

  3. Controllo di stato: la programmazione funzionale non ha variabili di sorta, ha invece simboli. Ogni "variabile" ha un unico valore immutabile. Ciò significa che non otteniamo alcun tipo di ambiguità in termini di cosa sia una cosa. Una magia A è una magia Un tempo nei linguaggi imperativi potrebbe essere una Magia A o B o C o D o qualsiasi altra cosa. Non c'è alcuna possibilità per uno stato indeterminato in Programmazione funzionale perché non ci sono stati in questo senso. Ciò che invece viene fatto è l'idea dell'isolamento di I / O. Si ottiene ciò che si inserisce, non una stranezza casuale e, a causa dell'isolamento, non è possibile che I / O possa danneggiare il programma interno (idealmente). Questo intero casino è in mano in particolare con Concurrency in quanto non hai bisogno di serrature o barriere.

Direi che la programmazione orientata agli oggetti è ancora pienamente applicabile con la programmazione funzionale. La programmazione OO è un modo utile di organizzare e strutturare il codice mentre la programmazione funzionale è un modo utile di ordinare e strutturare il calcolo. OCAML è un ottimo esempio qui. La programmazione OO è stata persino combinata con la programmazione logica sotto forma di Prolog ++. Quindi la programmazione OO può certamente trarre beneficio da altri stili tanto quanto possono trarne beneficio.

    
risposta data 30.03.2012 - 02:19
fonte
1

La risposta di Erik è corretta per il "perché" è stato fatto.

Vorrei aggiungere che quando selezioni una lingua, scegli quella che supporta naturalmente il paradigma. Ad esempio, voler fare FP e selezionare C ++ e discutere in alcune strane librerie è inferiore in tutti i modi a scegliere un linguaggio FP per iniziare. Scegli lo strumento che meglio soddisfa l'esigenza. Se vuoi davvero le funzioni FP, usa un linguaggio FP, non usare la debole implementazione semiprofessionale di esso con astrazioni che perdono in un'altra lingua.

Questo genere di cose mi infastidisce quando le persone cercano di coinvolgere tutto in The One True Language, che è un'idea sbagliata. Usa diversi strumenti per lavori diversi, non provare a fabbricare l'ultimo coltellino svizzero che non fa davvero un buon lavoro.

    
risposta data 30.03.2012 - 04:05
fonte
0

Chi può dire che non possono coesistere più paradigmi? Ci sono un numero di linguaggi ibridi che colmano il divario tra OOP e FP come F # e Scala.

Il problema è che negli ultimi vent'anni OOP è diventato lo standard del settore e quindi la maggior parte della gente del settore comprende la progettazione di software con oggetti. FP offre alcuni frutti a bassa quota (idee come LINQ) che possono essere immediatamente utili nel mondo OO. Offrendo prima i frutti a bassa quota, i programmatori possono rimanere produttivi e gradualmente attraversare il ponte, imparando ad applicare le idee FP al loro ritmo. Questa graduale introduzione al paradigma del FP non sarebbe possibile se i programmatori fossero costretti ad abbracciare l'intero paradigma tutto in una volta - ad es. tuffati direttamente in Haskell.

    
risposta data 21.08.2014 - 04:58
fonte

Leggi altre domande sui tag