Sono un principiante completo con OCaml. Di recente mi sono imbattuto in questa pagina in cui sono elencate molte critiche nei confronti di OCaml.

Visto che la pagina è piuttosto vecchia (2007): quali dei punti elenco elencati sono ancora veri oggi? Ad esempio: è ancora vero che è impossibile stampare un oggetto generico?

Voglio chiarire che non sto cercando una discussione delle opinioni ivi espresse. Sto chiedendo se le informazioni elencate, come il fatto che gli overflow di numeri interi senza avvisi, siano ancora corretti per le versioni più recenti di OCaml

Questo articolo è discusso in diversi luoghi:

• caml.inria.fr
• Notizie di hacker
• Reddit

Riassumendo: sì, OCaml non è un Lisp, e no, non è perfetto (cosa significa?). Non credo che i punti menzionati nel post sul blog siano rilevanti per i programmatori O'Caml di tutti i giorni.

Dopo aver studiato O'Caml, penso che sia un linguaggio interessante che può aiutarti a costruire programmi che non oseresti nemmeno scrivere, diciamo, in C / C ++ / Java: ad esempio, dai un'occhiata a Frama-C .

Per una descrizione aggiornata di O'Caml, ti incoraggio a leggere le sue caratteristiche : il linguaggio promuove tecniche di controllo statico del tipo che consentono alle implementazioni di concentrarsi sulla produzione di runtime performanti, ma sicuri.

Importante : non sono un esperto di OCaml: se sei uno di loro e vedi che ho scritto qualcosa di orribilmente sbagliato, per favore correggimi. Modifica questo post di conseguenza.

Controllo statico del tipo

• Falso senso di sicurezza

  Questo è vero, ma ovvio.

  La digitazione statica fornisce prove di cui ti puoi fidare su un sottoinsieme delle proprietà del tuo programma. A meno che tu non accetti di diventare formale, un programma medio (non giocattolo) sarà soggetto a errori di programmazione che possono essere osservati solo in fase di esecuzione.

  Questo è quando possono essere applicate tecniche di controllo dinamico: il compilatore OCaml ha flag per generare file eseguibili con informazioni di debug e così via ... Oppure, può generare codice che si fida ciecamente del programmatore e cancella il più possibile le informazioni sul tipo. I programmatori che desiderano programmi efficaci devono implementare esplicitamente i controlli dinamici.

  Lo stesso vale per esempio Common Lisp, ma invertito: prima i tipi dinamici, con le dichiarazioni di tipo opzionali e le direttive del compilatore in secondo luogo.

• Pochi tipi di base

  Si applica ancora: la lingua principale non è cambiata (o non in modo drammatico).

• Overflow intero silenzioso

  Questa è la norma nella maggior parte delle lingue in cui l'overflow di numeri interi viene controllato manualmente. Non conosco alcuna libreria che verifichi le operazioni di controllo del tipo per verificare se può verificarsi un overflow.

• Immutabilità del modulo

  1. L'autore menziona Functors ma non riesco a vedere come il suo esempio non possa essere implementato. Leggendo il capitolo Moduli di prima classe di https://realworldocaml.org , sembra che i moduli possano essere usati per comporre e costruire nuovi moduli. Naturalmente, la modifica di un modulo esistente richiede la modifica del codice sorgente, ma ancora una volta, questo non è insolito tra i linguaggi di programmazione.

  2. " Semanticamente , le funzioni sono compilate INLINE"

  Il thread reddit sopra non è d'accordo, dicendo che l'associazione viene risolta al momento del collegamento. Tuttavia, questo è un dettaglio di implementazione e penso che l'enfatizzato Semanticamente si riferisca al modo in cui le funzioni vengono risolte. Esempio:

   let f x y = x + y ;;
   let g a b = f b a ;;
   let f x y = x * y ;;
   exit (g 2 3) ;;
  

  Il programma precedente viene compilato e, una volta eseguito, restituisce 5, poiché gè definito con la prima versione di f, proprio come se la funzione chiamante gavesse incorporato la chiamata f. Questo non è "cattivo", tra l'altro, è solo coerente con le regole di oscuramento del nome di O'Caml.

  Riassumendo : sì, i moduli sono immutabili . Ma sono anche componibili .

• Il polimorfismo causa errori di tipo runtime

  Non riesco a riprodurre l'errore menzionato. Sospetto che sia un errore del compilatore.

Nessuna macro

In effetti, non ci sono macro ma preprocessori (OcamlP4, OcamlP5, ...).

• Wrapper (con file aperto)

  Sapere come UNWIND-PROTECT può essere utile, è davvero doloroso vederlo assente da più lingue. Ecco alcune opzioni:

  1. Migliorare la gestione delle eccezioni in OCaml
  2. Estendi la sintassi OCaml

• posti

  Non credo che esistano riferimenti generalizzati in OCaml.

Minor Suckiness della lingua

• Registra un campo che dà un nome all'inferno

  Vero, ma dovresti usare i moduli:

  1. Due campi di due record hanno la stessa etichetta in OCaml
  2. Risoluzione dei nomi dei campi

• Sintassi

  Si applica ancora (ma in realtà, questa è solo sintassi).

• Nessun polimorfismo

  Si applica ancora, ma in qualche modo ci sono persone che preferiscono questo invece della torre numerica di Lisp (non so perché). Suppongo che aiuti con l'inferenza del tipo.

• Set di funzioni incoerenti

  Vedi il progetto OCaml Batteries Included . In particolare, BatArray , per un esempio di map2array.

• Nessuna variabile dinamica

  Può essere implementato:

  1. http://okmij.org/ftp/ML/dynvar.txt
  2. http://okmij.org/ftp/ML/index.html#dynvar

• Gli argomenti ~ facoltativi fanno schifo

  Per restrizione linguistica, non è possibile combinare argomenti facoltativi e parole chiave in Common Lisp. Significa che fa schifo? (ovviamente, questo può essere modificato con le macro (vedi ad esempio la mia risposta )). Vedi la documentazione di O'Caml per argomenti facoltativi e nominati in O'Caml.

• Incoerenza dell'applicazione argomento parziale

  Non penso che questo sia davvero fastidioso in pratica.

• Leggibilità dell'aritmetica

  Tiene, ma puoi usare R o Python per problemi numerici se preferisci.

• Risoluzione silenziosa del conflitto di nomi

  Si applica ancora, ma si noti che questo è ben documentato.

• Nessun oggetto input / output

  Si applica ancora.

Implementazione, biblioteche

Questi continuano a cambiare ogni giorno: non esiste una risposta definitiva.

Infine,

"Dovresti provare OCaml (o, meglio ancora, Haskell) anche se pensi che faccia schifo e non hai intenzione di usarlo. Senza di esso, la tua istruzione in Informatica è incompleta, proprio come è incompleta senza alcuni Lisp e C (o , meglio ancora, Assemblea) esposizione ".

... si applica ancora.

Visto che la pagina è piuttosto vecchia (2007): quali dei punti elenco elencati sono ancora veri oggi?

• Falso senso di sicurezza . Questo non ha senso.

• Pochi tipi di base . OCaml ora ha byte e array di byte ma nessuna stringa unicode integrata, numeri interi a 16 bit, numeri interi senza segno, float a 32 bit, vettori o matrici. Le librerie di terze parti forniscono alcune di queste.

• Overflow intero silenzioso . Invariato ma non è mai stato un problema.

• Immutabilità del modulo . La sua raccomandazione che funzioni e moduli dovrebbero essere mutabili è un triste ritorno al Lisp e una pessima idea. Puoi sostituire i moduli usando includese vuoi, ma non puoi mutarli, ovviamente.

• Il polimorfismo causa errori di tipo runtime . Questo è un grosso problema con OCaml e non è stato risolto. Man mano che i tuoi tipi evolvono l'uguaglianza polimorfica, il confronto e l'hashing falliranno quando incontrano tipi come funzioni e il debug del problema è molto difficile. F # ha un'ottima soluzione a questo problema.

• Nessuna macro . Ironia della sorte, quando ha scritto questo OCaml in realtà aveva il pieno supporto per le macro ma ora hanno deciso di estrarre la funzionalità.

• Wrapper . Questo è stato un vero problema e non è stato risolto. Non esiste ancora alcun try ... finallycostrutto nel linguaggio OCaml e nessun wrapper che lo implementa nello stdlib.

• Luoghi . Invariato ma non problematico.

• Registra un campo che dà un nome all'inferno . Strutturare correttamente il codice utilizzando i moduli.

• Sintassi . Invariato ma non problematico.

• Nessun polimorfismo . Questo è stato per lo più senza senso quando lo ha scritto e nulla è cambiato.

• Set di funzioni incoerenti . OCaml non ha ancora una consfunzione. Va bene. Non voglio roba di Lisp nella mia lingua, grazie.

• Nessuna variabile dinamica . È stata una buona cosa per OCaml. È ancora una buona cosa su OCaml.

• Gli argomenti ~ facoltativi fanno schifo . Argomenti opzionali rock. Ho provato a Microsoft per convincerli ad aggiungere argomenti opzionali a F #.

• Incoerenza dell'applicazione argomento parziale . Eh?

• Leggibilità dell'aritmetica . Questo è cambiato da quando ho smesso di usare OCaml ~ 8 anni fa. Apparentemente ora puoi farlo Int64.((q * n - s * s) / (n - 1L)).

• Risoluzione silenziosa del conflitto di nomi . Stava cercando di fare un vero e proprio sviluppo software nel REPL come faresti con Lisp. Non farlo in OCaml. Utilizzare file e compilazione batch ricorrendo al REPL solo per test, esecuzione di codice usa e getta e elaborazione tecnica interattiva.

• Ordine di valutazione . Questo era sbagliato quando lo scrisse. L'ordine di valutazione non è definito in OCaml.

• Nessun oggetto input / output . Ha citato una biblioteca di terze parti che ha già risolto questo "problema".

• Il compilatore si arresta dopo il primo errore . Eh?

• Nessuna traccia di stack per eseguibili compilati in modo nativo . Fisso.

• Il debugger fa schifo . Non ho mai usato il debugger. Il controllo statico del tipo cattura quasi tutti i miei bug.

• GC fa schifo . Ho trovato il GC di OCaml superbo, tranne per un grosso problema: il blocco globale impedisce la programmazione parallela.

• Nessuna dichiarazione a termine implicita . La ricorsione reciproca è esplicita in base alla progettazione in tutte le ML. L'unica stranezza è che le typedefinizioni sono ricorsive per impostazione predefinita, mentre i letbinding non sono ricorsivi per impostazione predefinita.

• Il round di funzioni è assente . OCaml ha ancora uno stile semplice ma le librerie di terze parti come Jane St's Core forniscono rounde amici.

• Liste . List.mapnon è ancora ricorsivo alla coda. Ho inviato patch per correggere bug gravi come questo e ho dovuto aspettare anni prima che apparissero nelle versioni. Le liste sono ancora immutabili, ovviamente. E così dovrebbero essere.

• Velocità . Credo che i tempi di compilazione per le grandi varianti polimorfiche siano stati corretti.

• Corrispondenza del modello . Un trionfo di speranza sulla realtà. La comunità Lisp non è riuscita a farlo. Da qui la mia decima regola: qualsiasi programma Lisp sufficientemente complicato contiene un'implementazione ad hoc, specificata in modo informale e piena di bug di metà del compilatore di pattern match di OCaml.

Ad esempio: è ancora vero che è impossibile stampare un oggetto generico?

Quando ha scritto che non si poteva semplicemente fare:

print value

ma potresti invocare la bella stampante dal livello più alto come una chiamata in libreria, dandogli le informazioni necessarie sul tipo. E c'era una macro che è possibile utilizzare per annotare le strutture di dati al fine di avere le stampanti piuttosto autogenerate.