Ho appeno letto l’articolo: quello si chiama “object oriented” 
ed e’
quello che uscirebbe a un qualunque programmatore OO non proprio
orrendo.
E’ chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti. Btw attualmente c’e’ ancora un
fortissimo accoppiamento (== bad design) fra la logica di lettura e
quella
di scrittura, che sono mescolate insieme (violazione di DIP). Ma non
volendo anticipare (anticipation == evil) diciamo che potrei sopportare.
Per la mia esperienza Ruby (e Smalltalk prima di lui) rimangono
imbattibili
come linguaggi ibridi, anche se Java si e’ ormai molto avvicinato e
Javascript e’ gia’ li da tempo (devi solo selezioare fortisssimamente
quello che usi).
On May 18, 2015 1:40 PM, “maurizio de magnis”
[email protected]
wrote:
@Bruno:
E' chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti.
Puoi riformulare con altri termini questo concetto? Fatico a seguirti
Btw attualmente c'e' ancora un
fortissimo accoppiamento (== bad design) fra la logica di lettura e
quella
di scrittura, che sono mescolate insieme (violazione di DIP)
Quali parti di quel codice consideri come bad design?
@allTheFunctionalPeople:
sarebbe interessante confrontare la soluzione “Ruby con oggetto e
millantamento di funzionalità” con una soluzione funzionale duro-purista
(per esempio in Haskell, Lisp/Scheme-like, uotevah) allo stesso
problema,
in modo da misurare la distanza “funzionale” dall’esempio Ruby.
2015-05-18 20:21 GMT+02:00 bruno bossola [email protected]:
Il giorno 18 maggio 2015 22:20, maurizio de magnis <
[email protected]> ha scritto:
@allTheFunctionalPeople:
sarebbe interessante confrontare la soluzione “Ruby con oggetto e
millantamento di funzionalit” con una soluzione funzionale duro-purista
(per esempio in Haskell, Lisp/Scheme-like, uotevah) allo stesso problema,
in modo da misurare la distanza “funzionale” dall’esempio Ruby.
…un talk per il rubyday al quale parteciperei volentieri 
te fai il poliziotto buono o cattivo? 
2015-05-18 22:25 GMT+02:00 Michele F. [email protected]:
E' chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti.
Puoi riformulare con altri termini questo concetto?
Si, scusatemi, ero sul bus e ho zippato un po ahah! Allora, “logiche
ortogonali” sono quelle logiche che devono cambiare per ragioni diverse
e
pertanto devono essere isolate. Se sono grosse abbastanza (di solito lo
sono) sono “reificate” (astratte ed estratte) in un oggetto separato.
Btw attualmente c'e' ancora un
fortissimo accoppiamento (== bad design) fra la logica di lettura e
quella
di scrittura, che sono mescolate insieme (violazione di DIP)
Quali parti di quel codice consideri come bad design?
Ho visto ora che la lettura e’ fuori dal ciclo (non lo avevo notato,
dopo
le pippone sulle performance non mi immaginavo si fosse letto tutte le
linee del file in memoria… bad idea) quindi la violazione e’ piu’
“leggera” se vuoi, perche’ c’e’ solo l’incastro della parsificazione con
l’output. Percepisco un generale fastidio riguardo al diverso livello di
astrazione dei due pezzi: la parsificazione e’ incapsulata in un
oggetto,
la scrittura spiattellata. Un altro accoppiamento piu’ “fine” da vedere
e’
quello fra il processo e il modello: linea dentro, linea fuori:
nell’esatto momento in cui ci devi mettere un totale (che in quel tipo
di
report e’ comune) cominci a darci dentro con if &.co. Un esempio lo
trovate
se mi ricordo bene nel primo capitolo di “Refactoring” di Fowler, un
problema di reporting molto simile
Secondo errore e’ la concreta dipendenza dal dispositivo (“puts”) che
rende
il codice intestabile e sicuramente non scritto con TDD: dovresti avere
un
oggettino che si occupa di scrivere, testato separatamente. perche’ in
quel
modo il tuo codice di alto livello dipende non da astrazioni (come
dovrebbe) ma da roba bella concreta (violazione di DIP
Vacation Rental Hacks )
Meglio?
Ciao!
2015-05-18 22:20 GMT+02:00 maurizio de magnis
[email protected]:
con tutte queste violazioni più che di poliziotti parlerei di vigili… (
͡° ͜ʖ ͡°)
ipotizzando un talk di due relatori in cui uno espone Ruby e l’altro
Haskell 
2015-05-18 22:26 GMT+02:00 maurizio de magnis
[email protected]:
Il giorno 18 maggio 2015 22:26, maurizio de magnis <
[email protected]> ha scritto:
te fai il poliziotto buono o cattivo? 
…scherzi, non mi perderei lo spettacolo dalla platea che per niente al
mondo!
Attenzione che dopo il FOOOP rimane il FAAAP (…ing) che mi sembra un
po’ la direzione che si prende quando si comincia a parlare di
functional
programming
Ecco aggiungete la mia trollata alla lista delle trollate mentre fate
faaap:
append([H|T], TrollingTail) ->
[H|append(T, TrollingTail)];
append([], TrollingTail) ->
TrollingTail.
2015-05-18 23:15 GMT+02:00 bruno bossola [email protected]:
E' chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti.
Puoi riformulare con altri termini questo concetto?
Si, scusatemi, ero sul bus e ho zippato un po ahah!
Eheh, ogni tanto quando i concetti sono molto zippati mi si lancia il
warning “excessive trickness”
Allora, “logiche
ortogonali” sono quelle logiche che devono cambiare per ragioni diverse e
pertanto devono essere isolate. Se sono grosse abbastanza (di solito lo
sono) sono “reificate” (astratte ed estratte) in un oggetto separato.
Ok, ci sono
> "leggera" se vuoi, perche' c'e' solo l'incastro della parsificazione con
> l'output. Percepisco un generale fastidio riguardo al diverso livello di
> astrazione dei due pezzi: la parsificazione e' incapsulata in un oggetto,
> la scrittura spiattellata.
Ok, l’autore avrebbe potuto fare un File.open(‘x’) {|f| f.each_line
{|f_line| … }, ma penso che abbia voluto mantenere basso il “rumore”
attorno al concetto che voleva approfondire, ovvero come effettuare un
parsing più in stile funzionale.
Se noti, la lettura da file viene affrontata solo all’inizio del post.
Allo stesso modo non impiega tanto tempo nella gestione dell’output.
Un altro accoppiamento piu’ “fine” da vedere e’
quello fra il processo e il modello: linea dentro, linea fuori:
nell’esatto momento in cui ci devi mettere un totale (che in quel tipo di
report e’ comune) cominci a darci dentro con if &.co. Un esempio lo trovate
se mi ricordo bene nel primo capitolo di “Refactoring” di Fowler, un
problema di reporting molto simile
Per snocciolare meglio la questione, questo approccio
https://gist.github.com/olistik/ad33366e7d0da5c1f257 sarebbe
sufficientemente functional-ish?
O in alternativa, questo altro tentativo
https://gist.github.com/olistik/0e5719d2477669466f36?
Secondo errore e’ la concreta dipendenza dal dispositivo (“puts”) che
rende
il codice intestabile e sicuramente non scritto con TDD: dovresti avere un
oggettino che si occupa di scrivere, testato separatamente. perche’ in quel
modo il tuo codice di alto livello dipende non da astrazioni (come
dovrebbe) ma da roba bella concreta (violazione di DIP
Vacation Rental Hacks )
Meglio?