Clojurians
#clojure-italy
<
2017-10-14
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

nilrecurring13:10:39

Appena guardato il talk di Rich, sono rimasto un po’ spiazzato. Di solito amo i suoi talks, perchè illuminanti, utili e ragionati

nilrecurring13:10:19

Stavolta ci sento un po’ troppo tribalismo non necessario (“don’t fall to the proof-people”), e bashing poco informato sui type systems

nilrecurring13:10:27

Perchè quando parla di type systems si riferisce a Java e C++, e il loro type system incentiva davvero il coupling (e l’esempio delle 1500 classi in java calza bene)

nilrecurring13:10:41

Ma da come parla sembra che non abbia mai usato un type-system moderno (Haskell, Purescript, Idris). I tipi sono componibili, il problema dei product types è risolto dai row-types (che sono praticamente clojure maps, ma typechecked), e il problema del coupling si evita con i polymorphic types

nilrecurring13:10:24

E appena visto il talk di @bronsa, assolutamente fantastico :clap::clap::clap:

richiardiandrea17:10:52

@nilrecurring ottima analisi, ho visto tanto focus su static vs dynamic di nuovo. Dibattito che per me è chiuso da tempo senza vincitori

richiardiandrea17:10:17

Grazie per il link su reddit, imparo imparo imparo :smile:

richiardiandrea17:10:49

(chi lo guardava quel cartone? Mi pare tmc o MTV non ricordo)

nilrecurring17:10:33

Sono d’accordo sul “senza vincitori”: static e dynamic hanno degli use-cases differenti, e hanno entrambi dei punti validi, quindi davvero non ha senso riaccendere il dibattito

nilrecurring17:10:19

Il punto chiave che permette di evitare il coupling è structural vs nominal typing

nilrecurring17:10:14

structural = il tipo è definito dalla struttura (come nei row types), nominal = il tipo è definito dal nome che gli si da (come le classi Java)