Forum: Italian Ruby user group Re: approccio di sviluppo

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cd7dc6b12cfeed6eae27f7401a198884?d=identicon&s=25 bruno bossola (Guest)
on 2015-05-18 20:22
(Received via mailing list)
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"
<maurizio.demagnis@gmail.com>
wrote:
321db48bf4bdf48da05e781325aed20a?d=identicon&s=25 Maurizio De magnis (olistik)
on 2015-05-18 22:20
(Received via mailing list)
@Bruno:

<quote>
E' chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti.
</quote>

Puoi riformulare con altri termini questo concetto? Fatico a seguirti
:-)

<quote>
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)
</quote>

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 <bbossola@gmail.com>:
4cb81d167732f861dd41144985e161c0?d=identicon&s=25 Michele Franzin (michele_f)
on 2015-05-18 22:25
(Received via mailing list)
Il giorno 18 maggio 2015 22:20, maurizio de magnis <
maurizio.demagnis@gmail.com> 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 ;-)
321db48bf4bdf48da05e781325aed20a?d=identicon&s=25 Maurizio De magnis (olistik)
on 2015-05-18 22:27
(Received via mailing list)
te fai il poliziotto buono o cattivo? :-D

2015-05-18 22:25 GMT+02:00 Michele Franzin <michele@franzin.net>:
321db48bf4bdf48da05e781325aed20a?d=identicon&s=25 Maurizio De magnis (olistik)
on 2015-05-18 22:28
(Received via mailing list)
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
<maurizio.demagnis@gmail.com>:
Cd7dc6b12cfeed6eae27f7401a198884?d=identicon&s=25 bruno bossola (Guest)
on 2015-05-18 23:15
(Received via mailing list)
<quote>
E' chiaro che esistono delle logiche ortogonali che devono essere
identificate e reificate in oggetti.
</quote>

> 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.


<quote>
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)
</quote>

> 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
http://www.objectmentor.com/resources/articles/dip.pdf )

Meglio?

Ciao!




2015-05-18 22:20 GMT+02:00 maurizio de magnis
<maurizio.demagnis@gmail.com>:
C82630c82a3c675d2928804f432fcf17?d=identicon&s=25 Elia Schito (Guest)
on 2015-05-18 23:18
(Received via mailing list)
con tutte queste violazioni più che di poliziotti parlerei di vigili… (
͡° ͜ʖ ͡°)
96de2d8d465edb7a3cf9573b3ec174d4?d=identicon&s=25 Stefano Verna (Guest)
on 2015-05-18 23:53
(Received via mailing list)
> On May 18, 2015, at 10:27 PM, maurizio de magnis <maurizio.demagnis@gmail.com>
wrote:
>
> ipotizzando un talk di due relatori in cui uno espone Ruby e l'altro
> Haskell ;-)

+1 :)
4cb81d167732f861dd41144985e161c0?d=identicon&s=25 Michele Franzin (michele_f)
on 2015-05-19 08:22
(Received via mailing list)
Il giorno 18 maggio 2015 22:26, maurizio de magnis <
maurizio.demagnis@gmail.com> ha scritto:

> te fai il poliziotto buono o cattivo? :-D
>
>
...scherzi, non mi perderei lo spettacolo dalla platea che per niente al
mondo!
5ce16d85034e08079db3cafeb5b8ff09?d=identicon&s=25 Davide Rambaldi (Guest)
on 2015-05-19 09:16
(Received via mailing list)
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.
321db48bf4bdf48da05e781325aed20a?d=identicon&s=25 Maurizio De magnis (olistik)
on 2015-05-19 12:34
(Received via mailing list)
2015-05-18 23:15 GMT+02:00 bruno bossola <bbossola@gmail.com>:

> <quote>
> E' chiaro che esistono delle logiche ortogonali che devono essere
> identificate e reificate in oggetti.
> </quote>
>
> > 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" :-D


> 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 :-)

<quote>
> "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
> http://www.objectmentor.com/resources/articles/dip.pdf )
>
> Meglio?
This topic is locked and can not be replied to.