Haskell è strettamente legato alla famiglia di lingue ML. Ciò include cose come OCaml , ovviamente, ma anche F # sulla piattaforma .NET. Questi linguaggi condividono con Haskell le basi del sistema di tipi e il modo in cui i dati vengono utilizzati - tipi di dati algebrici, corrispondenza dei modelli, inferenza dei tipi, ecc. Naturalmente possono differire sostanzialmente da Haskell su altri punti - la maggior parte delle ML sono rigide e impure , per cominciare, e la popolarità di Haskell come veicolo per la ricerca nei sistemi di tipi e nella progettazione del linguaggio significa che la maggior parte dei linguaggi in stile ML tendono ad avere sistemi di tipo meno potenti (ma potenzialmente più facili da capire). Probabilmente è sicuro di dirlo mentre potresti perdertialcune cose su Haskell, in particolare all'inizio, la maggior parte dei programmatori Haskell probabilmente si sentirebbero a proprio agio a casa in una ML piuttosto rapidamente, a un livello base di preparazione. Se vuoi una lingua con la stessa struttura generale di Haskell, una ML è la soluzione migliore.
Il lato funzionale di Scalaattinge fortemente anche dalla tradizione ML, e include anche alcune funzionalità di sistema avanzate familiari a Haskell, oltre a un sistema OOP più standard integrato con quanto sopra. Mentre OO in 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 puoi immaginare, e presenta un ambiente di lavoro più familiare per i programmatori OO. Tuttavia, proveniente da uno sfondo di Haskell, è più probabile che tu sia infastidito dai modi in cui mescolare le cose insieme in Scala rende più goffi gli idiomi funzionali e trova che la maggior parte delle API Java siano progettate male e inutilmente difficili da usare.
Infine, sebbene possa sembrare strano da considerare, Clojure ha in realtà molte cose in comune con Haskell a un livello più filosofico. Gran parte di ciò che troverete nell'approccio di Clojure allo stato e ai valori rispetto alle identità è molto vicino nello spirito a ciò che Haskell formalizza attraverso il sistema dei tipi. Di conseguenza, 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 stessa programmazione funzionale potrebbe essere più vicino a ciò che già conosci. Penso a questo proposito dire 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 proviene dalla tradizione Lisp e quindi manca del sistema di tipi statici e dell'enfasi sui tipi di dati algebrici e sulla corrispondenza dei modelli trovati nei linguaggi influenzati dalla ML. E ovviamente è un Lisp, che è di per sé un aspetto negativo per alcune persone (anche se non so davvero perché).
Parlando da solo, con il disclaimer che la mia prima esperienza con la programmazione funzionale è stata in Scheme, probabilmente mi spingerei verso Clojure, con OCaml probabilmente una seconda scelta.