☕

Giorno!

🍵

Mi sono letto la early history of smalltalk in queste notti insonni… e non e’ completamente OT rispetto a lisp

(http://worrydream.com/EarlyHistoryOfSmalltalk/)

…e 50 anni dopo siamo qui a riscoprire le stesse cose

e c’e’ sempre un tizio nella chat che fa il nostalgico :)

Grazie per lo sharing ben venga

Rispetto à hyped topics container orchestra

Meglio questa

e 50 anni dopo inventiamo YAML

e usiamo quella roba ovunque.. 😢

@reborg "functional programming is OOP done the right way" 😄

Scherzi a parte, il mio omonimo ha ribadito più volte di essersi pentito amaramente di averlo chiamato Object Oriented e non Message Oriented, nome che avrebbe riflesso meglio la vera natura del paradigma

vero…

ah si vero, ma gli oggetti erano ancora cose innoque a quei tempi

adesso mettiamo oggetti in containers e gli orchestriamo

😁

cio’ non toglie che anche in smalltalk, per capire il comportamento generato dal prossimo messaggio, devo capire (o tenermi in testa) lo stato interno dell’oggetto.

Però almeno non mi arriva un oggetto che devo "scartare" per guardare cosa c'è dentro e che non si sa se lo sta scartando anche qualcun altro nello stesso momento

si come cognitive load, anche le lingue FP hanno un cognitive load in termine di interfaccia

@justalanm non sono sicuro di scartare… se mi puoi fare un esempio

Scartare non nel senso di buttare, nel senso di aprire 😄

@darioszr e qui non sono sicuro di cosa intendi

@justalanm capit

stavo pensando a tenere in testa le cose, aldila del OP o FP

mi sembra che si chiama cognitive load. tipo il declartive code riduce cognitve load xke nel imperative devi tenere in testa tutto l"iter

e nello stesso mode, anche un interfaccia FP che non abbia oggetti e states, puo essere molto difficile da tenere in testa

😁

non so se mi capisci reborg mi sono agganciato in parte al tuo discorso.. 😁

ancora non bene. Quindi un interfaccia FP e’ l’elenco delle funzioni pubbliche?

si

non e’ che cambia ogni volta che chiamo una funzione :)

a volte credo per astrazione, e difficile sapere che tipo di data abbia bisogno una funzione

cioe se trovi in giro funzioni fatte da Pino e pino x 8 anni a fatto codice in X codebase

per lui X codebase e facile. poi pero quando Tina deve leggere il suo codice cambia molto la cosa

mi sembra che donald knuth aveva scritto una frase su questo

cmq quello che voglio dire e che x come l'ho vissuta io, certa gente ama la complessita, che ci puo anche stare( a me non fa impazzire)

quindi anche in FP codebase, ti ritrovi a dovere tenere in testa tante cose, poi se fa caldo e ancora peggio 😁

Ok, mi sembra che non avere da tenere in testa lo stato (nascosto o no) di oggettini vari renda piu’ semplice programmare FP. Mi sembra anche che stai assumendo FP sia senza tipi (a-la Clojure) ma FP non preclude di avere tipi espliciti (vedi Haskell per citarne uno). Cosi’ Tina dopo 8 anni arriva e vede: “oh data e’ di tipo “Address” :)

aha

no, i type per me non sono una religione

e piu quello che pensavo e che FP sicuramente e il futuro e l'inizio verso cambiamenti che dovremo intrapprendere nel software. cioe anche in FP esistono certi design pattern

ma per ora non ho trovato molto materiale a riguardo, giusto per curiosita. clojure applied di alex miller, e un buon libro su questo anche

perche discute in parte questi design pattern piu o meno fra componenti.

comq solo in parte, ma mi e piaciuta molto la parte in cui parla della struttura dei namespaces

che dice sui namespaces?

scusa meetings

ma dice come organizzarli in termini di funzionalita,

no probs

Rich ha espresso la stessa idea in passato https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#should-i-use-a-namespace-to-bundle-functions-to-model-a-domain-object-like-a-customer-or-product

@reborg nice! Non lo conoscevo!

ho fatto il mio primo post in ask.clojure

allora x chi fosse interessato, dice di fare una struttura simile sui namespaces:

utility, data definitions, abstractions , implementations assembly entry-points

e un capito che ho molto apprezzato

lo consiglio onestamente come libro 🚀