it-swarm.it

Perché la programmazione funzionale non è più popolare nel settore? Adesso ci riesce?

Durante i miei quattro anni all'università abbiamo utilizzato molta programmazione funzionale in diversi linguaggi di programmazione funzionale. Ma ho anche usato molta programmazione orientata agli oggetti, e in effetti uso più linguaggi orientati agli oggetti quando faccio il mio piccolo progetto per prepararmi al mio primo lavoro. Ma spesso desidero codificare in un linguaggio di programmazione funzionale quando realizzo questi progetti.

Tuttavia, quando si cerca un lavoro, è molto raro vedere un lavoro in cui è richiesta la conoscenza di un linguaggio di programmazione funzionale.

Perché i linguaggi di programmazione funzionale non sono più utilizzati nel settore? Al giorno d'oggi ci sono molte notizie sui linguaggi di programmazione funzionale, quindi mi chiedo se la programmazione funzionale sta prendendo piede nel settore ora?

61
Jonas

Direi che uno dei motivi per cui la programmazione funzionale non è più diffusa è la mancanza di base di conoscenza. La mia esperienza è che le aziende sono molto avverse al rischio in termini di implementazione di tecnologie che non sono flusso principale e che preferirebbero investire in framework collaudati (Java, c ++, c #). È solo quando c'è un'esigenza aziendale (come in Ericsson) che vengono presi in considerazione nuovi paradigmi. Ma anche nel caso di Ericsson ho sentito che il management ha richiesto l'uso di c ++ e Joe Armstrong è stato costretto a codificare le chiamate in c ++ !! Questo dovrebbe mostrare come le aziende riluttanti devono implementare nuove tecnologie!

38
ennuikiller

Ero un professore e, proprio come i programmatori, i professori sono sempre alla ricerca della prossima grande cosa. Quando pensano di averne trovato uno, lo rendono un carrozzone e tutti si accumulano. Dal momento che predicano agli studenti che pensano che i professori debbano essere davvero intelligenti, altrimenti perché dovrebbero essere professori, non ottengono resistenza.

La programmazione funzionale è un tale carrozzone. Certo, ci sono molte domande interessanti su cui indagare e un sacco di articoli per conferenze interessanti da scrivere. Non è un'idea particolarmente nuova, e puoi farlo praticamente in qualsiasi linguaggio moderno, e le idee non devono essere nuove per essere interessanti. È anche una buona abilità da avere.

Detto questo, la programmazione funzionale è solo una freccia da avere nella faretra, non l'unica, proprio come OOP non è l'unica.

La mia passione per il mondo accademico informatico è la mancanza di interazione pratica con l'industria per determinare ciò che realmente ha senso nel mondo reale, vale a dire il controllo di qualità. Se quel controllo di qualità fosse presente, potrebbe esserci un'enfasi diversa, sulla classificazione dei problemi e sulla gamma di soluzioni ad essi, con compromessi, piuttosto che solo sugli ultimi bandwagon.

67
Mike Dunlavey

Perché il problema più grande nello sviluppo del software in questi giorni è la capacità di gestire la complessità. Questo non è l'obiettivo della maggior parte dei linguaggi di programmazione funzionale. Come tale, le lingue che fanno rendono quella una priorità (vale a dire le più popolari OOP) tendono a rubare solo alcune delle caratteristiche più interessanti che emergono dal più accademico linguaggi funzionali e quindi rimanere al top.

25
Fishtoaster

La programmazione funzionale sta sicuramente iniziando a prendere piede - lentamente ma sicuramente.

Ad esempio, l'avvio che sto costruendo utilizza un linguaggio funzionale (Clojure) come linguaggio di sviluppo principale per i seguenti motivi:

  • Produttività - apprendimento FP è difficile, ma una volta capito è molto difficile da battere in termini di potenza ed espressività. Probabilmente scrivo circa 1/10 del numero di righe per implementare una determinata funzionalità rispetto a ciò che avrei bisogno in C # o Java

  • Affidabilità - le funzioni pure sono molto più facili da ragionare e testare rispetto agli oggetti con stato. Quindi puoi scrivere test migliori e validare la correttezza del tuo codice molto più facilmente.

  • Concorrenza - i linguaggi funzionali enfatizzano l'immutabilità, che ha enormi vantaggi per le applicazioni simultanee rispetto alla necessità di funzionare efficacemente su più core. E piaccia o no, correre su più core è il futuro. Vedi http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey per una spiegazione brillante del perché questo è così importante

  • Composibilità/modularità - i linguaggi funzionali sembrano prestarsi a collegare i componenti più facilmente dei complessi sistemi OO. non ho capito tutti i motivi di ciò, ma parte di ciò deriva dal fatto che non hai tutta la "complessità accidentale" che OO trascinano con sé. on Radical Simplicity di Stuart Halloway esplora queste idee in modo molto più approfondito.

[~ # ~] edit [~ # ~] : in risposta al commento di Despertar, un esempio di "complessità accidentale" di OOP che limitano la modularità sono i problemi con la clonazione profonda e la clonazione superficiale: non è possibile comporre oggetti insieme e passarli come strutture composte senza un'attenta analisi della semantica di clonazione e mutazione. è gestibile, ma in sistemi complessi diventa rapidamente un problema significativo, che non esisterà in primo luogo se si fa affidamento su strutture di dati funzionali puri.

24
mikera

Mancanza di app killer

Ehi, questo qui sembra nuovo. (Dig dig Dig)

Penso che la maggior parte dei linguaggi di programmazione abbia prosperato avendo una "app killer" - qualcosa di avvincente che era esclusivo del linguaggio (o visto in quel modo). Questo non vuol dire che tutta la diffusione sia stata quell'applicazione , ma che abbia spinto la lingua ad una maggiore accettazione.

Ecco la mia visione non terribilmente accurata di ciò che la nicchia ha guidato l'adozione di alcune delle lingue che abbiamo oggi:

  • C: Funziona ovunque (era la fine degli anni '70 e '80)
  • C++: framework GUI (primi anni '90)
  • Java: applet e servlet (alla fine degli anni '90)
  • Objective-C: app iOS (prima ancora, app OS X)
  • Ruby: Rails
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, ecc.
  • Javascript: AJAX, soprattutto tramite framework
  • lua: script di gioco, in particolare WoW

A parte questo, molti linguaggi proprietari sono entrati nella porta attraverso potenti organizzazioni di vendita (Oracle e, in misura minore, i linguaggi di Microsoft), creando effettivamente la propria nicchia.

Una nota molto importante su tale elenco: la "nicchia" del linguaggio, come indicato dall'app killer, diventa sempre più specifica con il passare dei decenni. Nota l'ultimo nell'elenco: script di gioco , in particolare. Sta diventando sempre più difficile per le lingue attirare l'attenzione a causa dell'elenco di cose che sono già state fatte abbastanza bene da un'altra lingua.

Quindi, ciò che un linguaggio funzionale deve davvero decollare è una nicchia. In realtà, non ci sono ancora enormi linguaggi funzionali, ma ce ne sono molti nelle nicchie più piccole:

  • Emacs LISP: uso costante fin dagli anni '80 in Emacs da parte degli sviluppatori. ( Quasi mai usato altrove.)
  • Erlang: Ovunque tu voglia molti agenti simultanei.
  • Schema: istruzione
  • APL/J/K: Finanza (chiamiamoli funzionali, per il bene dell'argomento)
  • LISP comune: "AI" - Questo è ciò per cui le persone tendono a dire che è usato, che è una benedizione e una maledizione.

Ora, l'unica lingua principale che sento di aver lasciato fuori da questa discussione è Python. Python ha fatto qualcosa di molto interessante; è riuscito senza sembrare il vincitore in nessuna nicchia importante. Questo potrebbe significa che sono totalmente sbagliato nel vedere la popolarità della lingua in questo modo. Potrebbe anche significare che una lingua abbastanza buona può diventare popolare senza un'app killer guidare l'adozione e l'accettazione, ma è molto difficile e potrebbe richiedere molto tempo (Perl ha una storia simile, ma è arrivata qualche anno prima e ora ha una diffusione minore).

Da questo, posso dire quali lingue funzionali penso sono in aumento:

  • Clojure: programmazione Web, esp. attraverso Heroku
  • Scala: Lift (o forse Play, in questi giorni) - JVM senza Java

Se mi chiedessi dove cercare i linguaggi funzionali più diffusi, direi di essere alla ricerca di un linguaggio funzionale con lo sviluppo di cloud chiavi in ​​mano (come Heroku o GAE) o lo sviluppo di app mobili chiavi in ​​mano.

12
Jesse Millikan

Per lo stesso motivo per cui LISP non ha mai preso piede (che le guerre di fiamma abbiano inizio!). La programmazione funzionale è un paradigma molto alieno rispetto alla programmazione imperativa e orientata agli oggetti. Se, come la stragrande maggioranza degli studenti CS, hai iniziato con C e sei passato a C++/Java, tendi a non voler imparare a pensare in un modo completamente ortogonale al modo in cui pensi normalmente.

9
Chinmay Kanchi

Consideriamo le imprese e la programmazione.

Ci sono aziende che usano il loro software come risorsa strategica. Questo non è tipico. Per la maggior parte delle aziende, l'IT è qualcosa che supporta il vero business dell'azienda. È una spesa necessaria. Sono prudenti perché sanno che per $ X possono ottenere l'IT di cui hanno bisogno, mentre se passano a qualcosa di diverso risparmieranno meno di $ X se tutto va bene e perdono molto se tutto va male.

Inoltre, nelle aziende, la cosa più economica da fare è in genere quella che hanno fatto ieri. Il cambiamento, tuttavia, è desiderabile, è costoso. Se un'azienda dovesse passare, per esempio, da una soluzione C # /. NET, anche a F #, avrebbe dei problemi. I loro programmatori (che probabilmente non sono i programmatori più acuti là fuori) dovrebbero imparare una nuova lingua, essere abili in entrambi e usarli entrambi frequentemente. Ci sarebbero routine scritte in entrambi per molto tempo. Se dovessero passare a qualcosa come Haskell, o se in primo luogo usassero C++/MFC, cambieranno molto di più, e sarebbe molto più costoso.

Inoltre, ci sarà una scorta di programmatori C # e il supporto continuo di Microsoft, per molto tempo a venire. È possibile contare sulle pratiche IT attuali. Non esiste lo stesso livello di supporto istituzionale o di garanzia della disponibilità continua dei programmatori.

Pertanto, per la maggior parte delle aziende, apportare modifiche alla programmazione funzionale sarebbe costoso in anticipo e pagherà da solo se la riduzione dei costi IT è sufficiente nel lungo periodo, tranne che il lungo periodo è potenzialmente incerto.

6
David Thornley

Scrivi già il codice in stile funzionale, ma non lo conosci.

Quando viene richiesto di eseguire unit test per il codice, si tende a scrivere funzioni testabili, che non creano o dipendono da effetti collaterali e restituiscono sempre lo stesso risultato sugli stessi argomenti (le cosiddette funzioni pure). Questo è il vantaggio principale dei programmi funzionali.

Penso che i linguaggi funzionali siano troppo limitanti. Quindi, invece di sostituire le lingue imperative con lingue funzionali, le lingue imperative otterranno funzionalità funzionali. Oggi quasi tutti i linguaggi di programmazione hanno chiusure e lambda.

2
Calmarius

Credo che ci sia una sola vera risposta alla tua domanda. Puoi entrare in molte ragioni correlate per cui questa risposta è il caso, ma quelle sono domande diverse.

Ecco qui:

  • Gli architetti del software forniscono soluzioni di cui sono fiduciosi che funzioneranno.
  • La maggior parte degli architetti non lavora in linguaggi funzionali.
  • Una volta scelte le tecnologie e le lingue, le aziende trovano persone che possono lavorare con loro.

Sta prendendo piede? Tutto dipende dal fatto che le persone che hanno fiducia nell'uso dei linguaggi funzionali stanno diventando architetti e scelgono di usarlo per i progetti su cui lavorano.

1
John Fisher

Il vero problema è lo stato.

I linguaggi funzionali non hanno uno stato globale. La maggior parte dei problemi industriali richiede uno stato su larga scala (come si rappresenta un libro mastro o un insieme di transazioni) anche se alcune funzioni su piccola scala non lo richiedono (elaborazione di un libro mastro).

Ma stiamo eseguendo codice su macchine di architettura Von-Neuman che sono intrinsecamente piene di stato. Quindi in realtà non ci siamo liberati dello stato, i linguaggi funzionali nascondono semplicemente la complessità dello stato allo sviluppatore. Ciò significa che il linguaggio/compilatore deve gestire lo stato dietro le quinte e gestirlo.

Quindi, sebbene i linguaggi funzionali non abbiano uno stato globale, le loro informazioni sullo stato vengono passate come parametri e risultato.

Quindi la domanda diventa allora: la lingua può gestire lo stato in modo efficiente dietro il senso? Soprattutto quando la dimensione dei dati supera di gran lunga la dimensione dell'architettura.

Guardandolo dal lato hardware

Il sistema operativo ha aiutato molto negli ultimi due anni nella visualizzazione dello spazio degli indirizzi, quindi le applicazioni non devono ufficialmente preoccuparsene. Ma le applicazioni che non si preoccupano di cadere cadono nella trappola del thrashing dell'hardware quando la pressione della memoria diventa intensa (il thrashing dell'hardware rallenterà i tuoi processi fino a gattonare).

Dato che il programmatore non ha il controllo diretto dello stato nel linguaggio funzionale, per gestirlo devono fare affidamento sul compilatore e non ho visto linguaggi funzionali che gestiscano bene questo.

Sul lato opposto della medaglia il programmatore pieno di stato ha il controllo diretto sullo stato e può quindi compensare le condizioni di memoria insufficiente. Anche se non ho visto molti programmatori che in realtà sono abbastanza intelligenti da farlo.

Guardando dal lato dell'industria:

L'industria ha molti programmatori inefficienti pieni di stato.

Ma è facile misurare i miglioramenti di questi programmi nel tempo. Si lancia un team di sviluppatori al problema che possono migliorare il codice migliorando il modo in cui il programma gestisce lo stato.

Per i programmi funzionali i miglioramenti sono più difficili da misurare poiché è necessario migliorare gli strumenti che miglioreranno i programmi (stiamo solo guardando come le applicazioni gestiscono lo stato sottostante in modo efficiente qui, non il miglioramento complessivo del programma ).

Quindi per l'industria penso che dipenda dalla capacità di misurare i miglioramenti del codice.

Da una prospettiva assumente

Ci sono molti programmatori stat-full disponibili per il noleggio. I programmatori funzionali sono difficili da trovare. Quindi il tuo modello di domanda e offerta di base entrerebbe in gioco se l'industria passasse alla programmazione di stile funzionale e questo non è qualcosa che vogliono accadere (i programmatori sono abbastanza costosi come sono).

0
Martin York