Newsgroup: it.lavoro.informatica
Titolo: Design Patterns : per chi vuole impararli più facilmente

consiglio il libro "Head First Design Patterns" di Eric Freeman & 
Elisabeth Freeman, Ediz. O'Reilly, 2004, che ï¿œ molto piï¿œ leggibile che 
la 'Bibbia' di Erich Gamma et. al., non fosse altro perchï¿œ fa gli esempi 
in Java ed ï¿œ compilato in modo 'discorsivo' e anche con 'fumetti', (non 
rideteci sopra, e' un libro compilato secondo un metodo di apprendimento 
che denota una grande esperienza di psicologia didattica).
Io trovo i "Design Patterns" di Gamma,Helm, Johnson, Vlissides una 
'pizza' e gli esempi in C++ 'aggravanti negativi' per la comprensione 
per 'total beginners'.
Infatti, per leggerlo, bisogna aver la massima confidenza col C++
tanto quanto i bambini l'hanno con un pallone.
La GoF ha anche commentato positivamente il libro.
PS - non ho azioni della O'Reilly  (<hahahahaha>  :-))  )
John.

 che denota una grande esperienza di psicologia didattica).
Non conosco in libro in questione ma ne ho visti altri della serie "head
first" e li trovo troppo dispersivi e confusionari, quanto meno hanno
uno stile che a me confonde.
io consigliere Design Patterns in Java dell'Addison-Wesley, che secondo
me ï¿œ molto leggibile e mediamente qua a Pisa la pangloss lo tiene.

 tanto quanto i bambini l'hanno con un pallone.
Entrambi i libri sono qui sulla mia scrivania.
Mi permetto di fare una precisazione: il libro "Head First - Design 
Pattern" è un testo *eccellente* se si ha bisogno di "imparare" ma - 
come tutti i libri della serie "Head First" - non è un buon "reference 
manual". Il libro della GoF presenterà pure tutte le limitazioni a cui 
accenni ma è un ottimo manuale di riferimento. In sintesi, il mio 
consiglio è: accattateveli tutti e due. :-)
Ciao,
Giulio
--


Mi associo al consiglio.
(infatti anch'io li ho tutti e due).  :-))

 che denota una grande esperienza di psicologia didattica).
Numero di pagine?

 per 'total beginners'.
I total beg magari non hanno bisogno di pattern.
 
-- 
_____________________________
Luc (36, CO)
Software developer since 1985
_____________________________

 --
Io ho DP in Java (menzionato da michelangelo) ed e' ottimo per
integrare il libro della GoF...e per capirci di piu' con degli esempi
ben fatti, districandosi dalla quasi accademicita' del libro da cui e'
partito tutto...
Per inciso, comprai il libro GoF qualche anno fa e l'ho soltanto
sfogliato, anche perche' era fin troppo concettuale e a me serviva
qualcosa con degli esempi, magari nel linguaggio Java...quindi DP in
Java e' ottimo.
Anche perche' i pattern cambiano concretamente nell'applicazione a
seconda del linguaggio, per via dell'esistenza di costrutti che
esistono in uno ma non in un altro.

 che denota una grande esperienza di psicologia didattica).
concordo assolutamente! Credo che sia il miglior libro della serie.
Anche perche' l'argomento si sposa bene con lo stile "head first" che
non funziona bene per coprire argomenti lunghi e dettagliati ma e'
perfetto che fissare nella mente "poche idee , ma buone". Inoltre lo
stile giocoso e informale e' perfetto per abbattere la (falsa) aura di
astrazione e difficolta' che circonda spesso i DP..
Certo non bisogna essere insofferenti allo stile "originale" di Head
First, quindi consiglio di dargli un occhiata prima di comprarlo..


non fai prima cercarlo su amazon?
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/

 Numero di pagine?
638.  ma 'divertenti'.
quello di Gamma : 374 pag. escluso l'indice. Ma 'pesanti'.

 la 'Bibbia' di Erich Gamma et. al., non fosse altro perchï¿œ fa gli esempi 
quoto al 600%.....la bibbia ï¿œ pesante...il libro della Freeman ï¿œ 
divertente ma porta al risultato!
-- 
Cordiali saluti
Davide
Consulenza Informatica
 a Monza e Brianza 
www.cleosolutions.com

> consiglio il libro "Head First Design Patterns" di Eric Freeman &
Buon consiglio!
Incluso con il libro ci dovrebbe anche essere un bellissimo posterone
riassuntivo da appendere nell'ufficio del "vero informatico"(TM) :-)

 quello di Gamma : 374 pag. escluso l'indice. Ma 'pesanti'.
638 (o 374) per i patterns? I libri di fisica o di meccanica applicata
dell'università hanno meno pagine. Fisica, eh, mica astratti
schematismi come questi.



Hai mai visto un libro della serie "Head First"?
Ci sono intere pagine con solo un omino pensieroso e il fumetto con 
scritto "ma questo pattern lo posso applicare anche al tostapane?"
Ci sono note scritte "a mano", schizzi fatti a matita, pagine 
"fotocopiate" con solo delle frecce che ti indicano i collegamenti che 
dovevi trovare da solo, esercizi da svolgere e svolti, ecc.
Se lasci solo il testo, di 638 pagine ne rimangono forse meno di 200.
Ma la particolarita` e` proprio quella: rendono leggero un argomento 
anche pesante.
Bye.

 schematismi come questi.
Prima di criticare gli "astratti schematismi" bisognerebbe conoscere di
cosa si sta parlando. I DP sono tutto fuorch� astratti.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Se lasci solo il testo, di 638 pagine ne rimangono forse meno di 200.
Bisogna essere più concisi. 638 pagine sono troppe per questi
argomenti.

 argomenti.
a parte il fatto che semmai N pagine saranno "troppe per i tuoi
gusti", un libro andrebbe giudicato per quello che si trova scritto
sulle pagine, non per quante sono..

 la 'Bibbia' di Erich Gamma et. al.
io consiglio anche questo, che e' ingiustamente poco conosciuto:
http://www.amazon.com/Holub-Patterns-Learning-Design-Looking/dp/159059388X
mostra i DP in azione , ma non con un  programmino giocattolo  per
ogni pattern come fanno gli altri libri (approccio che ha il suo
senso , comunque)  ma con  due programmi discretamente complessi ed
implementati a livello professionale che contengono piu' pattern in
relazione tra di loro. E chiunque conosca un po' i pattern sa che
"risplendono" particolarmente quando sono in relazione tra di loro. E
come bonus in questo libro ci sono anche altre interessanti
considerazioni di design.. insomma secondo me e' da non perdere!

 considerazioni di design.. insomma secondo me e' da non perdere!
Anche Applying UML & Patterns: Introduction to Object-Oriented
Analysis & Design, & Iterative Development di Larman e' ottimo.
Segue un progetto complesso dove applicare i GoF pattern (e quelli
enterprise di Fowler), l'UP e altro ancora...

 sulle pagine, non per quante sono..
Ma guarda, ed io che pensavo di parlare a nome dei gusti di
tutti ............. :-))))
Comunque il numero di pagine è uno dei possibili indicatori immediati.
Ad esempio ti dice subito che l'autore tende semmai alla prolissità,
non certo alla concisione. Cosa negativa (aggiungici tu "per i miei
gusti" :-).

 Ad esempio ti dice subito che l'autore tende semmai alla prolissit�,
Cazzata. La lunghezza delle pagine � proporzionale al numero e complessit�
di argomenti trattati. Difficile trovare un libro di informatica che non
sia un mattone. Si vede che sono tutti prolissi. Visto che la sai tanto
lunga su tanti argomenti, forse dovresti tenere corsi.


 lunga su tanti argomenti, forse dovresti tenere corsi.
Ah sì? E come mai sul medesimo argomento, qui, abbiamo un libro che è
circa il doppio dell'altro?
Vedo che come sempre hai le idee molto chiare ;-)
I libri concisi di informatica abbondano, basta cercarli. Es. "UML
distilled" di Fowler.

Hole schrieb:

Ueh ragazzi, andateci piano che se io mi metto a seguire tutti i vostri 
consigli non mi restano pi� soldi per mangiare... :-))
Comunico inoltre che l'Alexandrescu ho dovuto farmelo mandare dalla 
Germania da mio figlio perch� qui a Genova nessuna libreria l'aveva e 
per ordinarlo ci voleva un mese.. :-(

 circa il doppio dell'altro?
Scusate se mi intrometto, ma senza avere davanti i due libri � 
impossibile argomentare.
La serie Head First, come � stato detto, � pi� un 'fumetto' che un libro.
E' un metodo di comunicazione senzaltro valido per quelli che i design 
pattern non sanno nemmeno cosa siano e vogliono addentrarsi nell'argomento.
E' stato ideale per me, ad esempio. Io sapevo cosa erano, ma mi � 
mancata l'esperienza per usarli. O meglio : li usavo (alcuni) senza 
sapere che erano 'design pattern'.
Ma io sono scusato : la mia laurea in informatica data dal 1991 e se 
avessi solo quella oggigiorno potrei usarla come carta igienica.
In questo campo (come in altri) se uno non si aggiorna resta indietro, e 
se resta indietro troppo, meglio che faccia il pizzaiolo.
Quindi, dopo aver avuto tra le mani il Gamma, mi sono rifatto gli occhi 
(e divertito) col secondo libro 'a fumetti'.
Il mio parere : sono soldi spesi bene e le 600 e passa pagine si leggono 
che � un piacere. Quasi come leggere Dylan Dog o Diabolik.  :-))

 Vedo che come sempre hai le idee molto chiare ;-)
Chi dimostra di avere le idee confuse sei tu, di certo non io.


 se resta indietro troppo, meglio che faccia il pizzaiolo.
Quindi direi che tale "ispas" potrebbe andare a fare il pizzaiolo :)



questa e' una sciocchezza. E la combinazione lunghezza + stile +
contenuto che ti permette di giudicare su prolissita' o meno di un
libro.
Resta giusto che e' sacrosanto avere gusti e modalita' di
apprendimento che non si accordano con lo stile di head first..

 Quindi direi che tale "ispas" potrebbe andare a fare il pizzaiolo :)
Guarda che patterns=ricette, quindi per te neppure serve il
condizionale, cuoco già lo sei... :-)))
Questo se ritieni che cuoco o pizzaiolo sia un mestiere poco
apprezzabile , come sembra.

 pizzaiolo sia un mestiere poco apprezzabile , come sembra.
direi invece apprezzabilissimo, fintanto però rimane a fare pizze e non 
si mette a fare programmi :P

 per ordinarlo ci voleva un mese.. :-(
Gulp, un genovese!
Da Feltrinelli io avevo trovato quello classico GoF in italiano,
si, in italiano, crocefiggetemi pure! :-)
Gia' all'inizio presenta le sue diffiolta'...ad esempio:
Chi ha capito la copertina?!?!? ;-)
Ciao, buon fine settimana.

 se resta indietro troppo, meglio che faccia il pizzaiolo.
Bè, qui si può discutere.  Nel corso degli ultimi decenni se ne sono
viste un bel pò di "novità" informatiche scomparse senza lasciare
traccia.
Od anche le pseudo-novità indotte commercialmente dai produttori. Ci
vuole sempre un forte spirito critico.

 Ciao, buon fine settimana.
altrettanto. :-)

 si mette a fare programmi :P
Oh, meno male che mi dai ragione. La mentalità del ricettario della
sora Lel... ops, dei patterns del GoF va bene in pizzeria, ma nel
software non va bene, proprio no.... :-))))

 condizionale, cuoco già lo sei... :-)))
guarda che stai dicendo una minchiata, i patterns non sono *affatto*
delle "ricette".
Questa tua affermazione dimostra chiaramente (casomai ce ne fosse
stato bisogno) che tu non hai la nessuna compresione di cosa sia un
design pattern. Le "ricette" sono soluzioni precise ad un problema ben
definito implementate in un determinato linguaggio, come ad esempio
nei famosi XXX Cookbook della O' Reilly. Un pattern non ha nulla  a
che vedere con un ricetta. Indica una strategia di soluzione per una
classe di problemi simili. Non da la soluzione, ma ti aiuta a
trovarla. Ti da ' un modo piu' organizzato di vedere il design del
software ad oggetti, e un vocabolario utile per esprimere idee
complesse in poche parole. Vedi te che libro riesci a leggere senza
che ti venga l'abbiocco.. ma leggine almeno uno..

 traccia.
Nell'informatica ci sono sempre stati dei 'misteri buffi'.
Come ad esempio come mai il linguaggio C (la cui sintassi , per quei 
tempi, rasentava la schizofrenia) si sia affermato con molto pi� 
successo del Pascal, che aveva una sintassi molto pi� leggibile.
Come mai pure il Modula-2 di Wirth (lo strumento col quale feci la mia 
tesi di Laurea) non ebbe mai successo, anche se gi� permetteva di fare, 
per sua struttura, il 'parallel processing', cio� di creare moduli 
comunicanti ma indipendenti che potevano essere 'lanciati' 
contemporaneamente.
Si deifica il 'code re-using' come se fosse uno dei maggiori problemi 
dell'informatica. Ma non lo �.
Per quello, per progetti piccoli e medi (che sono IMVHO il 70 % del 
fabbisogno informatico) bastano buone regole di structured programming.
Se l'OOP/OOP si limitasse ad alcune pochissimi concetti, sarebbe niente.
Invece i tre fondamenti dell'OOD/OOP : encapsulation, inheritance, 
polymorfismo, sono delle fucine di decine di concetti e regole nuove
che creano come una atmosfera 'fuzzy' in tutto il progetto.
Si spende molti pi� soldi a far capire ai programmatori l'object 
oriented programming che modificare una programma ben strutturato 
scritto in un linguaggio procedurale.
Nel caso di 'reverse engineering' poi le cose diventano palesi.
Sfido tutti a dimostrarmi che � pi� facile leggere un codice (che non si 
� mai visto prima), scritto in C++ (usando l'OOP)  che uno scritto in C 
o  Pascal e che sia stato ben 'strutturato secondo i precetti dello 
Structured Programming, in modo da risalire ai requirements originali.
Chiaramente avendo a disposizione SOLAMENTE il source code e nessun 
altra documentazione.
Se dovessimo cronometrare, un programmatore impiega met� del trempo a 
risalire al problema originale leggendo un linguaggio procedurale 
Pascal, C, Fortran, Basic) che uno in C++.
Basta leggersi un tutorial del C++ per rendersi conto di quanti concetti 
affini esistano : classi, strutture, templates etc. ognuna delle quali 
ha un suo campo di esistenza.
Se poi consideriamo la possibilit� dell'overriting dei metodi 
(peculiarit� dell'inheritance) che vuol dire in sostanza spesso usare 
gli stessi nomi per delle funzioni che 'soprascrivono' quelle della 
classe madre, addio !
Non ci si capisce pi� un kakkio *quale* era il design originale.
Si perde completamente l'orizzonte.
Eppure il mondo � sempre andato avanti lo stesso, perfino con gli 
'spaghetti codes'.
Nel 1987 fui pagato 4000 marchi tedeschi per andare a 'capire' un 
software che era stato scritto per un Commodore 64  (Visual basic) si 
voleva trasportare su un IBM 286. Ovviamente senza alcuna 
documentazione. Conteneva qualcosa come 10000 statements.
Il programmatore era morto e la ditta (che costruiva porte e finestre) 
era nelle canne.
Eppure (in due) svolgemmo un ottimo lavoro in due settimane e 
consegnammo una documentazione completa dello 'is'-status, come punto di 
partenza per delle modifiche.
Per scrivere 'utilities' di ogni genere, in ogni campo, con non pi� di 
1000-2000 statements, basta benissimo un linguaggio procedurale e poche 
regole di 'structured programming'.
Che sono molto pi� facili e immediati da imparare.
E che mantengpono intatto l'entusiasmo per l'arte della programmazione.
Programmare ad oggetti obbliga il programmatore ad adottare un altro 
modo di vedere il mondo. Molto meno 'naturale' di quello che i 
sostengpono i supporters dell'OOD.
Bene. E adesso sono pronto per la lapidazione.  :-)))
John.

prendo spunto dal post di ispas
Ah ecco, stavo quasi per risponderti :)

 Bene. E adesso sono pronto per la lapidazione.  :-)))
Che dirti ?
Siamo in due :-)
La penso esattamente come te, anche se ammetto l'OOP ha il suo
fascino :-)
Ma specialmente l'assunto "molte cose nuove sono gia' scomparse" e
"molte cose nuove derivano come concetti da quelle vecchie, per cui
non apportano nulla di realmente nuovo" li trovo particolarmente veri.
Probabilmente solo chi ha "iniziato" prima dell'avvento di cose
"nuove" puo' vedere quanto "nuove" in realta' non lo sono.
Fuffologia applicata :-)
C'ya
   STeve

 Fuffologia applicata :-)
...ovvero : i soli vantaggi dell'avere una et� avanzata.. :-))

 Bene. E adesso sono pronto per la lapidazione.  :-)))
non e' questione di lapidazione ma, se questo era un post serio, e
spero che non lo sia, di consigliarti di aggiornarti un filino, sei
indietro di vent' anni..
Poi vabbe' , se ti occupi solo di un settore in cui si lavora in
procedurale, puoi anche rimanere li' al calduccio, ma da un
informatico mi aspetterei un po' piu' di apertura mentale e di
curiosita'..

 "nuove" puo' vedere quanto "nuove" in realta' non lo sono.
nessuna persona di buon senso pensa che la programmazione ad oggetti
sia venuta dallo spazio..
e' un evoluzione di idee e tecnologie precedenti, come tutte le idee e
le tecnologie..
Una discussione su quanto l'OO fosse "nuovo" (nota il "fosse" .. visto
che oggi l'OO non e' affatto nuovo) mi sembra francamente priva di
senso..e soprattutto di utilita'..

 senso..e soprattutto di utilita'..
Ma dai, perche' ?
Mo bisogna anche fare domanda in carta da bollo per fare una
discussione ?
Se non la ritieni velida, non partecipare :)
C'ya
  STeve

 
prendo solo questo ultimo spunto, perch� sugli altri non si puo'
argomentare su cosa uno vede molto pi� facile o difficile.
Io considero la pigrizia una qualit� essenziale per un programmatore, e 
pretendo che una metodica che ha la pretesa di essere usata 
'regolarmente' sia 'immediata' da assimilare. E da metterla in pratica.
Inoltre giudico la validit� di un metodo di 'trascrizione' (passare dai 
pensieri alla codifica) nella misura in cui questa � 'biunivoca' e mi 
permette di risalire alla 'idea originale' solamente guardando il 
codice, anche senza altra documentazione.
In un qualsiasi linguaggio procedurale si puo' risalire a costruirsi un 
flow chart ed un data flow in poco tempo.
In una codifica C++ � una pura chimera.
Quelli che supportano a spada tratta, come te, la OOP � solamente perche 
l'anno imparata talmente bene e che hanno acquisito una tale esperienza 
che per loro 'pensare a oggetti' � come parlare la loro limgua madre.
Ma il periodo che dura una simile familiarizzazione si misura in anni.
Nell'altro caso si misura in mesi.
Mi sono bastati 12 mesi nel 1971 per conoscere il PL/I probabilmente 
come tu oggi conosci il C++ o altro linguaggio OOP.
Anche se non ci conosciamo, scommetto che a te invece probabilmente sono 
stati necessari alcuni anni.
Se tu oggi potessi andare indietro co una macchina del tempo all'anno 
1975, capiresti cosa voglio dire.
Ma, restando ad oggi, prendiamo degli 'esseri umani normali' e mettiamli 
davanti a due corsi : uno di programmazione procedurale ed uno di 
programmazione ad oggetti, e vedremo che il tempo per imparare 
quest'ultim � quasi il doppio che per il primo.
Inoltre, come hai detto, si puo' produrre del codice osceno anche 
scrivendo in C++.
Quindi, confontando le due tecnologie e misurando la difficolt� di 
apprendimento e la possibilit� di operare un 'reverse engineering'
io mi sento di essere dalla parte della programmazione procedurale 
strutturata.
I programmi giganteschi, i problemi complessi esistevano anche negli 
anni 70. Io ho partecipato a diversi di essi.
Quindi : oggi si � perduta l'*immediatezza* di apprendimento.
Un esperimento che prover� a fare prossimamente, giusto per provare il 
mio punto, � quello di insegnare i Design Pattern a qualche novizio, 
facendoglieli capire NON con C++, bens� facendo gli esempi con un 
linguaggio procedurale.
La mia scommessa � che lui capir� la logica di un 'Observer' o di un 
'composite' in met� tempo, magari, per rincarare la dose, con l'ausilio 
di un data flow e di un flow chart, invece che di una notazione OMT o UML.
Voglio proprio fare una prova. Poi ti sapr� dire.
Per quanto riguarda il reverse engineering, io quando lavoravo ai miei 
tempi, mi ero abituato ad 'estrarre' la documentazione dal cource code, 
se non ce l'avevo a disposizione !!!  E ci riuscivo in poco tempo.
Prova a farlo oggi con un codice C++. C'� da spararsi !
Io purtroppo, alcuni anni fa (2007), diventai pazzo a cercare con fatica 
di scoprire la logica che stava dietro alcune biblioteche di un sistema 
'open source' abbastanza conosciuto. Poi mi decisi a comprare i libri 
documentativi che costavano 330 Euro.
Mi � molto pi� facile fare il reverse engineering (cio� capire cosa fa 
una libreria) con un sistema scritto per MATLAB che uno scritto in C++ 
!!  E parlo di *oggi*, anno 2010 !
John.

 sostengpono i supporters dell'OOD.
Beh, anche qui c'� da discutere.
E' piu' naturale avere a che fare con 'procedure e variabili' o e' piu'
naturale avere a che fare con oggetti?
-- 
Ciao!
Luca

 non apportano nulla di realmente nuovo" li trovo particolarmente veri.
Io invece la trovo un'affermazione nebulosa.
Un po' come dire: si stava meglio quando si stava peggio.
Che vuol dire?
-- 
Ciao!
Luca

 sempre meno visibilita' sui processi generati.
Per come e' il mio piccolo mondo, non e' cosi'.
Se vuoi fare girare bene un applicativo in .NET, devi conoscere
valanghe di roba, e lasciar perdere i wizard che ogni tanto ci sono.
E anche quando disegni interfacce, prima o poi dovrai sporcarti le mani
col codice generato.
Certo, non vai a toccare le porte direttamente (volendo, potresti) o a
scrivere vettori di interrupt, ma quella e' altra storia.
-- 
Ciao!
Luca

 C++ !!  E parlo di oggi, anno 2010 !
ALT! STOP! Non famo casino!!
Una cosa � C++, una cosa e' OOP.
C++ non e' facile da leggere; paghi la sua potenza con la semplicita'.
Pero' vi sono molti linguaggi ad oggetti, molto leggibili, che
consentono grande velocita' (vedi ad esempio il piu' volte citato
Python).
-- 
Ciao!
Luca

 
C'� un solo modo per saperlo.
Prendi due classi distinte, di esseri umani con lo stesso livello di di 
intelligenza.
Ad uno insegni un linguaggio di programmazione, diciamo un FORTRAN o un 
BASIC, o Pascl.  Perfino in C.
All'altro gruppo insegni il C++ e la filosofia ad oggetti.
Alle fine del corso vediamo quale percentuali di bocciati ci sono in 
entrambi i gruppi.

 
Scriveresti tu un sistema closed-source (cio� non open) in Python, che 
poi devi vendere a clienti e stare attento a che non te lo copiano ??
Io no.

 di un data flow e di un flow chart, invece che di una notazione OMT o UML.
ma e' sicuramente un esperimento interessante.. fammi sapere come va a
finire....

 ragionare in modo differente.
quoto!

 classi farli appartenere
no, scusa, una volta che hai un oggetto quallo appartiene ad una
classe. Punto. Semmai sono i metodi che "non sai a quali classi farli
appartenere", ma anche per quello ci sono regole ed esperienza nel
design, ed e' una delle parti piu' creative e belle dell OO.
In effetti uno dei motivi per cui l OO mi piace e' che rispetto ad
procedurale il lato di design e' molto piu' ricco e interessante. Il
design procedurale e' molto piu' "meccanico".

 design procedurale e' molto piu' "meccanico".
se l'hai imparato cos� bene, ti creedo.
Anch'io ho imparato bene la filosofia procedurale.
Ma forse se viene Michelle Hunziker ad isegnarmi la Object Oriented 
Philosophy puo' darsi anche che la impari meglio.
Dopotutto le cose si imparano nel modo in cui te le spiegano. :-))
Ed ora scusami ma vado a vedermi Hercule Poirot (Agatha Christie).
Ciao.
:-))

 Che vuol dire?
Se ti riferisci alla seconda, che molte cose spacciate/vendute come
"nuove", come concetto, in realta' sono vecchie cose ripresentate con
un "look" moderno :)
Negli ultimi decenni c'e' stato un proliferare di linguaggi e
piattaforme che se analizzate bene alla fine sono la stessa cosa.
Questa ovviamente la mia opinione (specifichiamo se no ti accusano di
chissa' cosa ...)
C'ya
  STeve

 Python).
La leggibilita' e' una gran bella cosa ma l'efficienza e' piu'
importante, almeno nel mio mondo.
C'ya
  STeve

 copiano ??
Lo faccio in C# (che si decompila in due secondi), perche' non dovrei
farlo in Python, se mi capita?
Io son sempre convinto che la bonta' di ci� che faccio e delle mie
competenze dipenda solo in parte dal codice. Meglio, il codice e' solo
il risultato di un background che ho; se non sai PERCHE' le cose sono
scritte in un certo modo, del codice ci fai pochino.
-- 
Ciao!
Luca

 ambito tecnologico.
Sappiamo bene entrambi che lo strumento assoluto non esiste.
Per come la vedo io, se dovessi scrivere firmware, lo farei in C. Avrei
molta pi� possibilita' di controllo.
Circa gli accessors, la cosa ti fa onore. Sai meglio di me che questo
implica overhead, dal momento che impieghi lo stack a ogni giro.
Accedere direttamente a una variabile � infinitamente piu' efficiente.
Pero' e' meno leggibile, soprattutto se il tuo sorgente si sviluppa su
molti files.
-- 
Ciao!
Luca

 entrambi i gruppi.
A parte il fatto che io sono un pessimo insegnante, e che probabilmente
a fine corso, la percentuale di bocciati sarebbe analoga e molto alta,
tu non fai un paragone corretto.
Insegnamo il Pascal, rigorosamente procedurale, e un altro linguaggio
ad alto livello (Python?), ALLORA possiamo fare un paragone serio.
-- 
Ciao!
Luca

 molti files.
Non solo. Apre possibili bachi, sai meglio di me che basta sputtanare
un puntatore per trovarti ad arare campi di grano :-)))
Se poi il puntatore e' globale e/o altri processi possono accedervi,
apriti cielo.
Ma purtroppo a volte DEVI per forza accedervi direttamente per
problemi di efficienza/mancanza risorse/ecc.
Ciao
  STeve

 ...ah sì ? sono inuitive anche le templates e le strutture ?
i templates possono piacere o non piacere ma non fanno assolutamente
parte delle fondamenta della programmazione ad oggetti...

 con macchine e periferiche, sia l'approccio sbagliato.
Esatto, infatti quello e' l'esempio classico di dove *non* e' il caso
di usare un linguaggio ad oggetti.
In sostanza piu' sei "vicino al ferro" e meno l 'OO e' utile. Ed e'
anche naturale, l'OO e ' nato per simulare la realta' , e deve essere
proprio perche'  le simulazioni sono la parte della programmazione che
mi ha sempre affascinato di piu' che amo cosi' tanto la programmazione
ad oggetti.

 Nono, sto solo dicendo che OOP e' una filosofia, un modo di vita,
ma anche no! l'OO  e' una tecnica di programmazione. Parlare di
filosofia e di modo di vita fa ridere!


Io la vedo cos� : hai presente un musicista che ha fatto gli studi al 
conservatorio ? ebbene un musicista (esecutore) esperto ti legge uno 
spartito di Stockhausen come io e te leggiamo la prima pagina della 
Gazzetta dello Sport.
Mette lo spartito sul piano e comincia a suonare perfettamente.
Proprio come io e te potremmo leggere ad alta voce un articolo di gipornale.
Questo vorrebbe forse dire che il modo di scrivere la musica � 'naturale' ??
Niente affatto !! Non c'� cosa pi� criminale nella musica che il modo in 
cui si scrivono gli spartiti. ossia le regole musicali che si stanno 
usando da secoli, che datano da Guido D'Arezzo.
Che � anche la ragione pi� importante per cui il 90% di tutti i bambini 
che vanno a scuola di musica, abbandonano nel giro di due al massimo tre 
anni.
Perch� qual metodo NON � NATURALE !!!
Io ho fatto un esperimento. Ho scritto un paio di battute (otto periodi) 
della 'F�r Elise' di Beethoven su un pentagramma verticale che aveva 
linee verticali raggruppate in gruppi da due e gruppi da tre, proprio 
simulando la tastiera del pianoforrte.
Poi l'ho messa sul pianoforte,  davanti a diverse persone e ho detto 
loro : provate a suonare. Le persone avevano  8 12 16 25 35 anni. 
Nessuno di loro era mai andato a scuola di pianoforte.
Immediatamente seppero fare un 'collegamento' tra quello che c'era 
scritto sul foglio ed il tasto da schiacciare.
La cosa piacque loro (la motivazione per la musica � naturale, quella 
s�, e meno che non venga *frenata* da altri fattori, ad esempio il modo 
in cui si scrive) e cos� continuarono spontaneamente a suonare per 
'imparare' il pezzo, finoa quando potevano eseguirlo pi� o meno 
correttamente. In un paio di giorni sapevano eseguire il pezzo a memoria.
Ergo : ho dimostrato a me stesso che IL MODO in cui si sacive la musica 
oggigiorno � la maggior ragione per cui gli 'esecutori' di musica sono 
una minima parte della popolazione.
Mentre la percentuale dovrebbe essere al minimo uguale a coloro che 
vanno in bicicletta !!!!
Ritornando a pallino, cio� al software engineering � difficilissimo qui, 
in questo NG, pieno di esperti di software engineering, poter avere la 
prova che l'Object Oriented Programming � una pizza solenne che non fa 
altro che allontanare gli 'uomini di buona volont� che vorrebbero 
imparare a programmare i computer.
Perch� gli 'esperti' di Softare engineering oggi masticano l'OOP come i 
musicisti professionisti masticano il modo di scrivere la musica.
Io non so a chi giova che scrivere musica debba essere prerogativa di 
una 'elite'. E cos�, non so a chi giova che 'imparare a far lavorare i 
computer al nostro posto' debba essere una cosa per una 'elite'.

 ad oggetti.
...e cos�, dibattendo dibattendo siamo arrivati a rispondere alla 
domanda del thread. Cui bono ? A chi giova la OOD/OOP. Ma � ovvio : ai 
costruttori di hardware (Processori, RAM, e mainboard)  !!!
Infatti  la tendenza � :
a) disegnare software in un modo pi� vicino al modo
    di pensare degli 'umani'  usando l'OOD/OOP
b) questo significa che diminuendo lo 'sbattimento' di coloro che fanno 
i sw-systems engineer si aumenta lo sbattimento di coloro che creano i 
compilatori e le 'piattaforme 'P', cio� 'near-hardware', i tuntime etc.
Perch� costruire un compilatore di un linguaggio OOP � senzaltro pi� 
impegantivo che scrivere un compilatore Fortran o C.
c)  in questo modo aumentano le esigenze di calcolo e di velocit�
d) i costruttori di hardware godono, perch� creano nuovi processori piu 
veloci e RAM pi� capaci.
E cos� siamo tutti felici e contenti.
E cos� sia.

 consiglio è: accattateveli tutti e due. :-)
Ottimo, ordinato da amazon :)
Ho seguito un po' il pippone conseguente su OOP e non OOP e francamente
non riesco a capire come un buon OOP possa essere meno comprensibile.
(quoto qui perché non so dove quotare altrimenti)
Come può questo:
--8<---------------cut here---------------start------------->8---
def makeStruct(arg1, arg2):
   return struct
def funToStruct(struct, fun):
    return fun(struct)
--8<---------------cut here---------------end--------------->8---
Essere meglio di questo:
--8<---------------cut here---------------start------------->8---
class Struct:
      def init(arg1, arg2):
          ...
 
      def fun(fun):
          fun(self)
--8<---------------cut here---------------end--------------->8---
La questione è molto semplificata e nella realtà codice procedurale
tende ad avere n-mila argomenti in più, con il conseguente casino e
delirio ogni volta che modifichiamo qualcosa di più o meno fondamentale.
Io sono più per il paradigma funzionale e avere dei side effect in
generale non mi piace mai, ma se fatto bene l'OOP può veramente
rappresentare bene la realtà rendendo semplice aggiungere nuove
funzionalità.
Se mai propongo un altro esperimento, python supporta OOP e procedurale
senza problemi (anche funzionale più o meno).
Prendete un principiante e un problema e mostrategli del codice
procedurale e OOP dello stesso programma, entrambi ben strutturati
naturalmente.
Il codice OOP risulterà sicuramente più chiaro e più compatto, con una
più chiara divisione dei compiti e di chi fa cosa.

 impegantivo che scrivere un compilatore Fortran o C.
anche questo e' vero, ma nota che non e' necessariamente un male, ed
inoltre lo stesso discorso puo' esser fatto anche per il passaggio
dall ' assembly al C o al FORTRAN.
Una domanda veramente interessante , invece di questi inutili
ripensamente su una tecnica oramai affermata da decenni e che e'
oramai patrimonio del passato e' : come si programmera' tra dieci
anni? E tra cinquanta? E tra mille? :)

 anni? E tra cinquanta? E tra mille? :)
1) Una discussione non e' mai inutile, anche perche' specie nel nostro
campo, nulla e' scritto sul marmo.
Discutere sull'utilita' o meno di qualcosa non ha la scadenza
2) Okuda ... e chi sa non necessita di spiegazioni. Chi non sa, e'
tagliato fuori :-)
C'ya
    STeve

 i musicisti professionisti masticano il modo di scrivere la musica.
Due cose.
Io non sono un genio. Detto meglio: se ci sono riuscito io, ci puo'
riuscire chiunque, basta solo che ci si metta.
Secondo. Io sono convinto tuttavia che programmare non sia un mestiere
facile. Bisogna conoscere le macchine e, soprattutto, bisogna conoscere
gli utenti.
-- 
Ciao!
Luca

 piu veloci e RAM pi� capaci.
Permettimi, io la vedo in modo differente.
1) Aumentano le potenze' di calcolo.
2) Ergo, possiamo scrivere qualsiasi cosa, anche non ottimizzato, che
tanto basta comprare un po' di RAM e la cosa si risolve.
Questo � l'oggi, ma io mi divertivo molto di pi� quando dovevo sudare
le proverbiali sette camicie per fare stare i supervisori per gli
impianti di risalita entro i 580k che il DOS mi dava a disposizione.
-- 
Ciao!
Luca

 tagliato fuori :-)
:)
vabbe', lasciando perdere per il momento la questione della
programmazione tra qualche secolo visto che e' una questione un
tantiniello difficile e che del resto difficilmente dureremo
abbastanza per interessarcene... nei prossimi anni io credo che la
direzione sia andare verso linguaggi sempre piu' dichiarativi invece
che imperativi..

     STeve
Andrea

 
Io metterei la mano sul fuoco che nel 3010 i liguaggi di programmazione, 
cos� come li conosciamo oggi noi,  saranno totalmente scomparsi. 
Esisteranno dei robot antropomorfi che 'capiranno' il liguaggio umano e 
faranno tutto quello che gli si chiede.
Per cui, esisteranno probabilmente solo 'embedded systems' che simulano 
l'intelligenza umana, magari costruiti con reti neurali. Ma chiss� che 
hardware ci sar� a quei tempi.. :-)))

 tanto basta comprare un po' di RAM e la cosa si risolve.
Qual'era quella famosa legge che un processore diventa 'insufficiente' 
18 mesi dopo che � uscito sul mercato ??? ...

 
caro vecchio Turbo-Prolog con la Torre di Hanoi...  :-))

 io non so, ma ci provo lo stesso: questo
Si' e' lui ma se se lo conosci solo per wikipedia allora non hai
capito le implicazioni.
Ciao
  STeve

 che imperativi..
Secondo me, e a quanto pare anche secondo John,  nel futuro non ci
saranno linguaggi di programmazione, come appunto l'idea di Okuda (che
ha fatto molto ma molto di piu' che "disegnare" i pannelli di ST) ma
macchine capaci di interagire con chiunque.
Ovvero lo shift e' che nel futuro tutti e nessuno saranno
"programmatori" di computer.
Gli unici ad esserlo saranno giusto quei pochi che progettano
computer.
C'ya
 STeve

 'insufficiente' 18 mesi dopo che � uscito sul mercato ??? ...
Bisognerebbe dirlo alla macchina su cui sviluppo, che ha 3 anni e mezzo
e che surclassa ancora molti giovincelli... ;-)
-- 
Ciao!
Luca


lo penso anche io! ma gia' che siamo nella "fantainformatica" non
dmentichiamo la possibilita' di "potenziare" gli esseri umani con
impianti computazionali artificiali :)
Chissa' forse in futuro saremo noi il computer !

 impianti computazionali artificiali :)
quello c'� ci� oggi : si chiama BMI (Brain -Machine-Interface)  :-)))
E' quello che permette malati di SLA o vittime di ictus o altre lesioni 
cerebrali, di muovere una protesi, scrivere su un computer, emettere 
suoni attraverso simulatori vocali, etc...