Clojurians Log v2
clojure-italy
Fantastico. Ovviamente penso che sia corretto anche l'inverso, che noi altri del tipo dinamico ci interessiamo ad OCaml o Haskell e capiamo quali sono i punti di forza del tipo statico
sono interessato a sapere quali sono i punti di cui un utente esperto si lamenta dal tuo lato, @reborg. Spiego meglio, dal lato dell'Haskell, con cui lavoro, a volte un'eccessiva astrazione dei tipi - che purtroppo vedo in molte codebase - secondo me causa piu' problemi di quanto non ne risolva, e in quei momenti mi piacerebbe che tu non potessi esprimere delle astrazioni cosi' complesse - perche' chi ha scritto quel codice ne fa un uso indiscriminato. Ci sono momenti in cui nelle codebase in cui avete lavorato voi, anche avendo schema/spec/malli etc, vi siete detti "quello che ci vuole qui e' lo static typing"?
No, non mi e' mai capitato. Ma quello a cui mi riferisco sono alcuni punti di sovrapposizione tra i due stili. Avere o no i tipi statici produce applicazioni che hanno un stile diverso (in cui la definizione di idiomatico cambia). C'e' ad esempio un piacevole uso di pattern matching coi tipi statici, c'e' un metodo chiaro per la gestione degli effetti etc.
In dinamic typing abbiamo altre cose (nil punning per esempio per me e' una feature) oppure transducers (che io uso a piene mani ma per ragioni storiche hanno avuto poco seguito).
Ora si puo' replicare l'equivalente degli idiomi dei tipi statici in un linguaggio dinamico e viceversa. Ma non si fa perche' il linguaggio ospite non e' adatto ad un idioma che viene da uno stile diverso.
Quello che mi succede in realta' e' che c'e' un 15% di casi in cui, programmando con un linguaggio dinamico, sarebbe bello avere tutta la potenza di pattern matching oppure effects per gestire inner exceptions in nested conditionals. In quel momento e' interessante capire come lo stesso problema e' stato risolto elegantemente con altri stili di linguaggio.
Allora adesso mi ritrovo ad usare piu' volentieri e di frequente core.match ad esempio.