Haskell è strettamente correlato alla famiglia di lingue ML. Questo include cose come OCaml , naturalmente, ma anche F # sulla piattaforma .NET. Queste lingue condividono con Haskell le fondamenta del sistema di tipi e il modo in cui i dati vengono utilizzati: tipi di dati algebrici, pattern matching, tipo di inferenza, ecc. Ovviamente possono essere sostanzialmente diversi da Haskell su altri punti - la maggior parte dei ML sono rigidi e impuri , per cominciare, e la popolarità di Haskell come veicolo per la ricerca nei sistemi di tipo e nella progettazione del linguaggio significa che la maggior parte dei linguaggi di stile ML tendono ad avere sistemi di tipi meno potenti (ma potenzialmente più facili da capire). Probabilmente è sicuro dire che mentre si può perdere alcune cose su Haskell, in particolare all'inizio, la maggior parte dei programmatori Haskell si sentirebbe probabilmente a suo agio in una ML abbastanza rapidamente, a un livello base di cose da fare . Se vuoi una lingua con la stessa struttura generale di Haskell, una ML è la soluzione migliore.
Il lato funzionale di Scala si basa molto anche sulla tradizione ML, e introduce anche alcune caratteristiche di sistema di tipo avanzato familiari ad Haskell, nonché un sistema OOP più standard integrato con quanto sopra . Mentre OO nei linguaggi in stile ML tende ad essere affrontato come più di un "modello OO con strumenti funzionali di base" Scala vive e respira OO in stile Java. Ciò ha vantaggi per l'interoperabilità Java, come si potrebbe immaginare, e presenta un ambiente di lavoro più familiare per i programmatori OO. Tuttavia, provenendo da uno sfondo Haskell, è più probabile che tu sia infastidito dal modo in cui unire le cose in Scala rende gli idiomi funzionali più goffi e trovare la maggior parte delle API Java per essere mal progettate e inutilmente difficili da usare. Quindi se vuoi qualcosa con un sistema di tipo sofisticato che permetta la traduzione diretta di molte cose in Haskell (con qualche overhead extra sintattico) e non ti interessi compromettere lo stile funzionale, potresti divertirti con Scala.
Infine, anche se può sembrare strano, Clojure in realtà ha molte cose in comune con Haskell a un livello più filosofico. La maggior parte di ciò che troverai nell'approccio di Clojure allo stato e valori rispetto alle identità è molto vicino nello spirito a ciò che Haskell formalizza attraverso il sistema di tipi . Corrispondentemente, Clojure enfatizza l'interoperabilità Java in misura minore e non si preoccupa tanto del trascinamento in OOP, quindi in qualche modo l'approccio di Clojure alla programmazione funzionale stessa può essere più vicino a ciò che si è già familiari con . Penso che stia dicendo a questo proposito che, per quanto ne so, Clojure è l'unica lingua oltre a Haskell che ha un'implementazione di STM è semplice, efficace e funziona. D'altra parte, Clojure deriva dalla tradizione Lisp e quindi manca del sistema di tipo statico e l'enfasi sui tipi di dati algebrici e sulla corrispondenza dei modelli trovati nei linguaggi influenzati da ML. E ovviamente è un Lisp, che è di per sé un aspetto negativo per alcune persone (anche se non so davvero perché).
Parlando per me, con la dichiarazione di non responsabilità che la mia prima esperienza con la programmazione funzionale era in Scheme, probabilmente mi propenderei verso Clojure, con OCaml una probabile seconda scelta.