Perché OCaml non è più popolare?

Ho sempre sentito che C è il linguaggio di scelta da utilizzare per i sistemi embedded, o tutto ciò che deve funzionare alla massima velocità. Non ho mai sviluppato una predilezione per C, soprattutto perché non mi piace l'aritmetica del puntatore e il linguaggio è appena un gradino sopra l'assemblatore.

D'altra parte, le lingue ML sono funzionali, le lingue raccolte con immondizia e OCaml ha persino un modello a oggetti, ma hanno la reputazione di essere veloci come le lingue C. ML hanno l'astrazione che chiunque potrebbe chiedere per scrivere di alto livello, conciso codice, ma mantiene la velocità necessaria per scrivere applicazioni ad alte prestazioni.

OCaml in particolare può essere usato ovunque sia tradizionalmente usato C, ad esempio per dispositivi integrati, driver grafici, sistemi operativi, ecc. Con tutti i diritti, ormai OCaml avrebbe dovuto impadronirsi del mondo, ma quasi nessuno aveva sentito parlare della lingua ma solo usato.

Questa è una domanda soggettiva, ma perché OCaml e ML altre lingue sono rimaste così oscure, mentre C e altre lingue sono diventate popolari?

La prima risposta è che nessuno sa davvero perché le lingue diventano popolari, e chiunque dica altrimenti è illuso o ha un'agenda. (Spesso è facile identificare il motivo per cui una lingua non riesce a diventare popolare, ma questa è un'altra domanda.)

Con questo disclaimer, ecco alcuni punti che sono suggestivi, il più importante prima:

• Il primo compilatore C maturo apparve nel 1974; il primo compilatore OCaml maturo apparve alla fine degli anni '90. C ha un vantaggio di 25 anni.

• C veniva fornito con Unix, che era la più grande "app killer" di tutti i tempi. Per molto tempo, tutti i reparti CS del mondo dovevano avere Unix, il che significava che tutti gli istruttori e tutti coloro che frequentavano un corso CS avevano l'opportunità di essere esposti a C. OCaml e ML stanno ancora aspettando la loro prima app killer. (MLdonkey è bello, ma non è Unix.)

• C riempie la sua nicchia così bene che dubito che non ci sarà mai un altro linguaggio di basso livello dedicato solo alla programmazione dei sistemi. (Per vedere le prove a favore, leggi l'articolo di Dennis Ritchie sulla storia di C da HOPL II.) Non è nemmeno chiaro quale sia la nicchia di OCaml, e la nicchia di Standard ML è solo un po 'più chiara. Quindi Caml e ML hanno parecchi concorrenti, mentre C ha ucciso il suo unico concorrente (BLISS).

• Uno dei grandi punti di forza di C è che il suo modello di costo è molto prevedibile: è facile osservare qualsiasi piccolo frammento di codice C in grado di avere immediatamente un'idea precisa di quali operazioni della macchina dovranno essere eseguite per eseguire quel codice. Il modello di costo di OCaml è molto meno chiaro, soprattutto perché l'allocazione della memoriaè molto meno esplicito e il costo complessivo dell'allocazione di memoria (uguale al costo di allocazione più i costi sostenuti durante la garbage collection) dipende dalle proprietà emergenti come la durata di vita degli oggetti e quali oggetti si riferiscono ad altri oggetti. Il risultato netto è che le prestazioni sono difficili da prevedere e persino difficili da analizzare dopo il fatto. (Gli strumenti di profilazione della memoria di OCaml non sono quelli che dovrebbero essere.) Di conseguenza, OCaml non è buono per le applicazioni in cui le prestazioni devono essere molto prevedibili, come i sistemi integrati.

• C è un linguaggio con uno standard e molti compilatori. OCaml è un artefatto software: l'unico compilatore proviene da un'unica fonte e il compilatore è lo standard. E quello standard cambia ad ogni versione. Per le persone che apprezzano la stabilità e la compatibilità con le versioni precedenti, una lingua a fonte singola può rappresentare un rischio inaccettabile.

• Chiunque abbia un corso per compilatore universitario a metà decente e molta persistenza può scrivere un compilatore C che funziona più o meno e con prestazioni adeguate. Ottenere un'implementazione di OCaml o ML da terra richiede molta più istruzione e ottenere prestazioni comparabili con un compilatore C ingenuo richiede molto più lavoro. Ciò significa che ci sono molti meno hobbisti a giocare con lingue come OCaml, quindi è più difficile per la comunità sviluppare una profonda conoscenza di come sfruttarla.

Penso che il problema con OCaml sia che non è troppo utile "pronto all'uso". L'eventuale motivo per cui le persone usano una lingua è perché ha librerie di cui hanno bisogno. Con niente "out of the box", tuttavia, nessuno si spinge abbastanza in un progetto per rendersi conto che devono scrivere una biblioteca. Il risultato è un linguaggio senza librerie, il che rende difficile scrivere "app reali".

Penso che questo sia ciò di cui soffre OCaml: nessuno si preoccupa di avviare "progetti reali" perché tutto ciò che esiste è un linguaggio di programmazione. Sì, posso aggiungere due e due e stampare il risultato. Il risultato è una raccolta di biblioteche che sono per lo più abbandonate accademiche (l'autore ha ottenuto il suo dottorato di ricerca e si è trasferito), il che non è molto utile per i programmatori esperti.

(So ​​che ci sono lavori in corso per cambiarlo, con progetti come "Batterie incluse". Torna qui tra 5 anni e forse OCaml sarà più popolare.)

Ci sono alcune eccezioni a questa regola. Java iniziò senza librerie, ma Sun pagò le persone per scriverle tutte in casa, e poi ne vendettero l'inferno. Certificazione Java, hardware specifico di Java, libri Java, classi Java, ecc. Quindi ha persino convinto la maggior parte delle università a insegnarlo esclusivamente, anche se non è un linguaggio molto buono da usare per l'apprendimento della programmazione.

Il risultato è stato popolarità. Il denaro può risolvere molti problemi.

Nell'arena del linguaggio funzionale, possiamo vedere che Haskell sta diventando abbastanza popolare. Penso che la maggior parte della popolarità sia dovuta a persone come dons che scrivono utili librerie e non smettono mai di commercializzare la lingua. Ogni giorno vedi alcuni articoli di Haskell sulla programmazione di Reddit. Questo lo tiene bloccato nelle menti delle persone fino a quando non decidono finalmente, "Ho intenzione di provare Haskell". Quando lo fanno, vedono cose utili come framework web, database di oggetti, librerie OpenGL e librerie di elaborazione XML. Ciò significa che possono effettivamente fare qualcosa di utile "Right Now". Quindi tra il potenziale di essere produttivo e sentirne parlare molto, Haskell ha guadagnato molta popolarità.

CL ha molte delle stesse librerie di Haskell ed è quasi altrettanto veloce, ma nessuno ne parla, quindi "sembra morto". In effetti #lisp è molto più silenzioso di #haskell, ma Lisp è ancora un linguaggio molto produttivo con molte librerie. Nessun'altra lingua ha SLIME. Ma il marketing è molto importante e Haskell lo fa meglio di Lisp o OCaml (e compete per la stessa base di utenti).

Infine, alcune persone non "ottengono" la programmazione, quindi rompendo il loro modello mentale (le variabili sono caselle con valori, il codice viene eseguito dall'alto verso il basso) garantirà che non usino il tuo linguaggio. Questo tipo di programmatore è una grande percentuale della popolazione di programmazione, quindi ciò limita ulteriormente la possibile base di utenti di linguaggi astratti come Lisp, Haskell e OCaml.

Mi piace OCaml molto come lingua. MA...

Il supporto degli strumenti non è lì. Il debugger funziona solo bene ma non funziona su Windows (ho controllato l'ultima volta) e non ci sono molti strumenti di sviluppo disponibili.

Il suo sistema di tipi è, a volte, un po ' troppo forte. Per qualcuno che non capisce come funziona l'inferenza di tipo o il sistema di tipi ML in generale, il fatto di non poter aggiungere un numero intero a un float è subito una svolta importante.

La libreria standard può talvolta avere un aspetto incoerente.

Il modello a oggetti sembra piuttosto impreciso e la libreria standard lo usa a malapena, optando invece per le librerie basate su moduli.

Ci sono molte altre cose che sostanzialmente equivalgono al fatto che la lingua non si senta "raffinata" e che allontana le persone durante il periodo molto critico in cui stanno imparando una lingua e provando a decidere se piace o no.

Penso che il suo lascito più importante sarà che, insieme ad altri dialetti ML, abbia avuto un'influenza molto forte su altri linguaggi funzionali. La maggior parte dei linguaggi funzionali della generazione attuale prende i migliori elementi dai dialetti ML e affina alcuni dei fastidi.

I sistemi integrati spesso richiedono due cose: velocità e determinismo. OCaml può fornire velocità, ma il fatto che abbia un Garbage Collector lo rende intrinsecamente non deterministico, e per un sistema in tempo reale che semplice non lo farà.

Questo è un po 'un confronto tra mele e arance. OCaml è un linguaggio abbastanza giovane [1] e non c'è mai stato uno sforzo serio e sostenuto per spingerlo nel mainstream (ad eccezione del lavoro corrente di Microsoft con F #). A differenza di C, non è la lingua franca del sistema operativo aziendale più supportato e imitato (ovvero UNIX). A differenza di Java, non ha avuto una grande azienda che lo spingesse come piattaforma di elaborazione di prossima generazione. A differenza di Perl, Python e Ruby, non ha preso piede in una nicchia influente di alto profilo (ovvero, la sua nicchia è il linguaggio di programmazione e la ricerca di ragionamento automatizzato, non di alto profilo rispetto allo sviluppo web). Quindi, non è molto popolare.

[1] In tutta onestà, il linguaggio ML originale è in circolazione dagli anni '70. Ma OCaml non è apparso fino al 1996 e non ha ereditato le librerie ML standard. È, in termini pratici, un linguaggio più giovane di C, C ++, Java, Python, Haskell o persino Ruby.

La comunità OCaml non è riuscita a sviluppare una libreria standard ampia e affidabile (oltre a quella fornita oggi da OCaml) che semplifica lo sviluppo di applicazioni. Esistono diversi tentativi per risolvere il problema, ma dai un'occhiata a Python o Ruby per vedere cosa manca. OCaml è un linguaggio eccezionale se vuoi risolvere un problema algoritmico che non dipende troppo dalla necessità di interagire con moduli standard avanzati come XML, rete, calcolo dei dati e così via, che preferiresti non implementare.

Credo che parte del problema sia il modo in cui i moduli sono mappati su file da OCaml: concettualmente tutti i file * .ml vivono nello stesso spazio nome e le directory non hanno alcun significato. Questo rende difficile per una comunità far evolvere una biblioteca. Se il compilatore associasse le gerarchie di directory in gerarchie di moduli, vedrei maggiori possibilità che una libreria standard si evolva. Ciò richiederebbe tuttavia notevoli sforzi da parte degli sviluppatori del core compilatore. (Sono a conoscenza dei moduli di imballaggio, ma penso che questo sia un problema.)

Un altro problema della libreria è la compatibilità binaria tra le versioni del compilatore. È abbastanza sicuro dire che tutto il codice della libreria deve essere ricompilato dopo un aggiornamento del compilatore. Ciò rende difficile fornire versioni binarie di moduli o librerie.

Probabilmente perché troppe persone hanno imparato la ML come parte di un'introduzione a cose teoriche strane e confuse sui tipi. Questo è quello che mi è successo.

Mi hanno mostrato ML e Smalltalk nello stesso periodo. Smalltalk sembrava semplicemente dannatamente bello, ed era immediatamente comprensibile cosa OO fosse e come si potesse fare cose piuttosto interattive in questo ambiente. ML parlava di cose matematiche astratte che non sembravano rilevanti per quello che volevo fare. E a differenza di C, non mi ha promesso di farmi scrivere giochi veloci su micro a 16 bit.

Questo è, ovviamente, profondamente ingiusto e soggettivo. Ma questa è probabilmente la storia vera per la maggior parte delle persone.

In questi giorni credo che la domanda sarebbe: ora sento di aver bisogno di conoscere questa strana e confusa roba teorica sui tipi, perché dovrei scegliere ML su Haskell o Erlang?

Credo che il problema principale sia la mancanza di una vera libreria standard. Da qui il progetto OCaml Batteries Included , che dovrebbe migliorare notevolmente la situazione. Dovrebbe entrare nella fase Beta entro pochi giorni, quindi dovrai fare di nuovo la domanda tra circa un anno.

Concordo sul fatto che lo scarso supporto di Windows, una curva di apprendimento ripida e una libreria standard snella abbiano in qualche modo soffocato la diffusione di OCaml in passato, ma aggiungerei che c'è stata un'enorme mancanza di informazioni tutorial (ad esempio libri) su OCaml rispetto ai linguaggi tradizionali come Java.

Inoltre, i tipi di persone che conoscono lingue come OCaml sono estremamente eterogenei. Tra i programmatori web, forse 1 su 1.000 avrà sentito parlare di OCaml. Tra le persone che fanno informatica scientifica all'università di Cambridge, circa il 90% delle persone che conoscevo parlava fluentemente OCaml. In effetti, sono stato uno degli ultimi tra i miei amici a imparare OCaml. Abbiamo persino eseguito OCaml sul nostro supercomputer da 256 CPU ...

Vorrei anche menzionare che questi problemi vengono affrontati rapidamente. OCaml si è recentemente reinventato per la programmazione web con progetti come Ocsigen e ha già almeno due importanti storie di successo industriale in quel contesto. C'è un altro nuovo libro su OCaml ora disponibile. La community sta collaborando a una libreria standard completa chiamata "batterie incluse" che è appena uscita in versione beta e sembra fantastica. Una versione multicore di OCaml sta per essere rilasciata. L'ultima versione di OCaml include anche molte nuove fantastiche funzionalità come modelli pigri e librerie OCaml a codice nativo caricate dinamicamente.

Penso che parte del problema sia che la programmazione funzionale non è un modo naturale per la maggior parte delle persone di pensare (e lo dico come qualcuno che ha un grande interesse e apprezzamento per la programmazione funzionale). Ciò è aggravato dal fatto che oggi la stragrande maggioranza dei programmatori ha iniziato a studiare la programmazione procedurale (i linguaggi OOP più popolari sono ancora procedurali nel cuore) e quindi i linguaggi funzionali sono difficili da adattare inizialmente.

Quando ho iniziato l'università conoscevo già una quantità ragionevole di BASIC, C ++ e Java e un po 'di linguaggio assembly Pascal e x86. Ero ben lungi dall'essere un esperto, ma avevo raggiunto la conclusione (leggermente ingenua) secondo cui tutti i linguaggi di programmazione erano sostanzialmente gli stessi con una sintassi leggermente diversa. La nostra introduzione al corso di programmazione ha usato ML che mi ha rapidamente disobbedito di questa nozione. Ho avuto problemi a orientarmi in ML in quella fase della mia carriera di programmatore e non ho visto il punto della programmazione funzionale. Penso che ci voglia un po 'più di esperienza con alcuni dei problemi della programmazione procedurale per apprezzare davvero i vantaggi di un approccio funzionale.

Il nostro docente di ML ha spesso affermato che esprimere i problemi in modo ricorsivo era più "naturale" e più semplice rispetto all'utilizzo di cicli o altri concetti procedurali. Non sono mai stato convinto da quell'affermazione e ancora non lo compro. Le funzioni ricorsive possono talvolta fornire soluzioni particolarmente eleganti e concise ai problemi, ma trovo ancora un modo innaturale di pensare ai problemi. Forse se hai un background matematico molto forte sembra più intuitivo, ma non credo sia facile per la maggior parte delle persone pensare in modo ricorsivo. Data la centralità delle funzioni ricorsive nel paradigma della programmazione funzionale, penso che questo possa anche essere un motivo per la minore popolarità dei linguaggi funzionali.

C'è anche un effetto di feedback sulla popolarità della lingua. Quando ho iniziato a programmare volevo sapere come programmare effetti grafici e giochi. Dopo aver appreso un po 'di BBC BASIC e successivamente QBASIC, ho naturalmente studiato quali fossero i linguaggi più comuni usati dalla scena demo e dai programmatori di giochi e ho iniziato a studiare l'assemblaggio C ++ e x86. Al giorno d'oggi alcuni nuovi programmatori potrebbero voler sapere come produrre applicazioni web e quindi graviteranno sull'apprendimento di PHP, Ruby o C #. Ci sono pochissime aree di applicazione per programmatori principianti auto-motivati ​​in cui la risposta a "qual è la lingua migliore per imparare a programmare qualcosa come X" sarà "Ocaml".

Molte delle ragioni pratiche fornite per la popolarità limitata di Ocaml (mancanza di librerie mature, debugger, IDE, ecc.) Sono affrontate dal supporto ufficiale di Microsoft per F # come linguaggio .NET di prima classe. Sarà interessante vedere se F # aiuta ad aumentare il livello di popolarità per la programmazione funzionale.

Credo che il nocciolo del problema sia la politica. Gli sviluppatori Ocaml sono principalmente interessati alla ricerca e non hanno le risorse per fornire e mantenere una ricca libreria. Tuttavia, non sono anche disposti a rilasciare il controllo del prodotto alla comunità che dispone di queste risorse, il risultato è che diversi tentativi di risolvere questo problema si basavano sulla cooperazione e sul finanziamento inesistenti di librerie di terzi e questi tentativi fallirono. Le batterie non funzioneranno per lo stesso motivo, a meno che gli sviluppatori Ocaml non cambino atteggiamento.

Uso Ocaml per sviluppare il mio prodotto e ho una semplice regola: minimizzare la dipendenza da codice di terze parti. Quando un articolo di terzi è utile, se possibile, incorpora i codici sorgente direttamente nel pacchetto. Ad esempio OCS Scheme e Dypgen sono parti essenziali del parser Felix, quindi vengono copiate nelle nostre fonti in modo da avere un certo controllo su di esse. Il controllo è piuttosto illusorio (dal momento che Dypgen almeno è così complesso che è improbabile che potremmo mantenerlo, ma almeno abbiamo una copia che pensiamo funzioni :)

Non userò le batterie perché la licenza è restrittiva, quindi non posso copiare la fonte e non ho fiducia nella fattibilità a lungo termine come prodotto autonomo: l'unico modo in cui potrei usarla è se fosse incorporato direttamente nella distribuzione standard di Ocaml.

Nel mondo C ++, potrei solo prendere in considerazione l'uso di Boost: sebbene sia una libreria di terze parti che non fa parte dello Standard, ha un supporto della comunità così pesante ed è effettivamente ottimamente sincronizzato con il processo di sviluppo degli Standard. Le idee sviluppate e testate in Boost diventano il tipo di pratica esistente che può essere standardizzata e il processo di standardizzazione è abbastanza aperto da consentire la partecipazione della comunità.

Ocaml ha ottenuto la popolarità che ha in realtà perché è un prodotto così eccellente, ma ciò non è abbastanza per permettergli di diventare un linguaggio tradizionale. Java è rozzo, è stato reso popolare con miliardi di dollari di marketing e sviluppo di librerie, ma alla fine ha dovuto essere rilasciato alla comunità per sopravvivere del tutto.

Mi è piaciuto programmare sia in ML che in C per un'ampia varietà di progetti. La cosa che mi impedisce di utilizzare ML nei progetti incorporati (la maggior parte dei quali ha vincoli in tempo reale e richiede la convalida) è la garbage collection.

Esistono ricerche sulla gestione della memoria con le regioni (vedere MLKit ), ma la complessità delle implementazioni e della formazione necessarie per utilizzarle correttamente (e i relativi rischi) sono state un ostacolo al loro utilizzo.

IMHO, penso che un grosso problema di OCaml non sia nella lingua (che è grandiosa) ma nelle persone che lo sviluppano e, di conseguenza, la sua licenza:

http://caml.inria.fr/ocaml/license.en.html

Usano la licenza Q Public per il compilatore! Sì, la licenza ex Trolltech utilizzata per le librerie Qt! Dimentica di ottenere qualsiasi contributo con tale licenza.

Se stavi controllando il Language Shootout ( http://shootout.alioth.debian.org/ ) circa 7-8 anni fa, OCaml era proprio dietro a C e C ++ per la velocità di esecuzione. Nel frattempo, altre lingue (come Haskell) hanno ottenuto un compilatore migliore (a causa di un diverso approccio della comunità, suppongo) e ora la velocità di esecuzione di OCaml non è così grande come in passato.

A breve, non userei OCaml, perché non vedo che vada meglio da nessuna parte senza alcuni hacker davvero bravi che creano un compilatore OCaml che ha una licenza VERAMENTE open source e una comunità con un comportamento VERAMENTE open source.

Bene, se si tratta di soldi come dice @jrockway, vedremo se F # guadagnerà la popolarità come java o C #.

Per me immagino che gli sviluppatori non si sentano a proprio agio con il modo funzionale di fare le cose (quello è dalla sessione F # in techdays 2009 in cui circa 10 persone hanno detto di conoscere la programmazione funzionale tra quasi 100 persone).

Ho iniziato OCAML quest'anno, non mi sono mai sporcato le mani con la programmazione funzionale, ma ora imparo davvero nuove cose sempre da OCAML e il modo funzionale per risolvere i problemi, (ma non posso dire che rinuncerò a C # per usare OCAML :)).

Bene, forse F # diventa popolare.

Non aiuta che c-> ocaml sia una transizione mentale più ampia di c-> lisp. Ho preso in considerazione ocaml un paio di volte e ho sempre scoperto che il rapporto costi / benefici non era lì per me, quindi mettilo di nuovo da parte. Non erano i costrutti che lo facevano sembrare duro, quelli in realtà sembravano davvero ordinati. Stava cercando di imparare un significato completamente diverso per "!". Almeno Lisp sembra così diverso che è facile evitare di interpretare erroneamente piccoli pezzi come c.

Se desideri che una lingua venga utilizzata nei sistemi embedded in tempo reale, hai bisogno di puntatori e non puoi permetterti un GC.

Penso che il motivo principale sia che troppi sviluppatori conoscono OCaml.

E quando parlo con altri sviluppatori (quelli che hanno sentito parlare di Ocaml) ho sempre l'impressione che pensano a OCaml come un linguaggio "solo educativo" ... triste ma vero

Mi piace molto O'caml ... Ho implementato un sacco di cose utilizzandolo, compilatore, interpreti, sistema per comunicare con C ...

quando l'ho imparato, il problema principale era che i messaggi di errore non erano molto chiari ... quindi, per esempio, all'inizio non ero sicuro di quando mettere ";" ed è stato davvero difficile scoprire che in realtà il; era fuori posto ...