nilrecurring condivido ed aggiungo: ogni linguaggio “agevola” uno strumento implementativo diverso, implicitamente o esplicitamente. C’e’ sicuramente posto per pattern matching in Clojure, o nil punning in Haskell. Ma la cosa non avviene di default ed ha solo qualche applicazione di nicchia. Forzare static types in Clojure o pattern matching a prescindere non e’ una buona mossa.

Il tizio di Akar non la pensa cosi’ e ne abbiamo discusso fino ad un “non la vediamo nello stesso modo”. Ci abbiamo bevuto una birra sopra 🙂

@reborg noi usiamo tantissimo defmulti. In realta' la nostra applicazione e' quasi solo defmethods ora 😄

nilrecurring: anche voi fate event-sourcing? 🙂

@reborg: Verissimo che ogni linguaggio favorisce un certo "modo di pensare". E.g. scrivo Clojure nella REPL a colpi di "incastrare le strutture dati in modo giusto", mentre scrivo Haskell a colpi di "penso alla soluzione funzionale e il compilatore mi dice come sistemare i tipi" (potrebbe non essere il modo "giusto" di farlo, ma mi diverto così). Sono quindi d'accordo sul non forzare pattern che funzionano su altri linguaggi: IMHO lo static typing distruggerebbe l'interattività della REPL per esempio

@helios kinda, ma non totalmente. Non c'è storage degli eventi, ma solo log (perchè sono effimeri e.g. "connessione aperta"), e non tutta l'applicazione passa dagli eventi. Potrebbe essere interessante applicarlo in modo totale, ma ho paura che possa aumentare la complessità, e soprattutto non è necessario allo stato attuale, quindi il focus è da altre parti. Tuttavia ho rimpiazzato una REST API con Sente e tutta la comunicazione (ora bidirezionale!) tra servers e clients passa dagli eventi, cosa che mi piace molto 😄

ah noi invece facciamo totalmente event-sourcing

proprio qualche minuto fa abbiamo festeggiato 200M domain events in 2 anni 🙂

OMG congrats, sono tanti 🙂

Upsides/downsides?