View Full Version : assembly-generation V java-generation
nuovoUtente86
29-04-2008, 12:12
frequentando assiduamente questo forum ho notato come ci sia un divario( non parlo per carità di preparazione individuale ma di divario generazionale) tra chi si è accostato all' informatica di basso livello(assembly,dos, c.......) e chi lo ha fatto negli ultimi 8-10 anni trovando troppa pappa pronta....da Xp a Java a PHP...Oggi si tende molto a lavorare ad alto livello trascurando cosa realmente avviene nella macchina cosa che le generazioni precedenti hanno dovuto fare, volente o nolente, per via della maggiore vicinanza tra il livello applicativo e quello macchina...questo gli consente di capire, a mio avviso, meglio molte cose....ovviamente c' è di mezzo il fattore esperienza, che però in questa discussione andrebbe trascurato.Cosa ne pensate?
cdimauro
29-04-2008, 12:52
Che si può programmare benissimo senza conoscere i dettagli dell'architettura, o comunque dettagli di più basso livello.
Fortunate le nuove generazioni che si risparmieranno parecchi mal di testa grazie all'uso di sistemi & linguaggi di programmazione managed.
amedeoviscido
29-04-2008, 13:15
E poi tutto dipende da quello che devi fare, come non mi stancherò mai di dire... :)
khelidan1980
29-04-2008, 15:27
frequentando assiduamente questo forum ho notato come ci sia un divario( non parlo per carità di preparazione individuale ma di divario generazionale) tra chi si è accostato all' informatica di basso livello(assembly,dos, c.......) e chi lo ha fatto negli ultimi 8-10 anni trovando troppa pappa pronta....da Xp a Java a PHP...Oggi si tende molto a lavorare ad alto livello trascurando cosa realmente avviene nella macchina cosa che le generazioni precedenti hanno dovuto fare, volente o nolente, per via della maggiore vicinanza tra il livello applicativo e quello macchina...questo gli consente di capire, a mio avviso, meglio molte cose....ovviamente c' è di mezzo il fattore esperienza, che però in questa discussione andrebbe trascurato.Cosa ne pensate?
dipende comunque io ho fatto l'uni negli ultimi anni(sto facendo la tesi ora) e l'approccio a basso livello c'è stato con tanto di programmazione in assembly,ovvio sicuramente il tempo dedicato è decisamente minore di quello di 20 anni fa ma allora non c'era java e compagnia bella da studiare! ;)
E anche una questioni di ottimizzare il tempo in base a ciò che po realmente ti servirà sapere
Secondo me chi non sa cosa succede "dietro le quinte" non può definirsi vero programmatore, ma semplicemente un buon utilizzatore di cose già pronte.
DanieleC88
29-04-2008, 17:04
A volte il fatto di "cominciare dal basso" è utile per comprendere meglio cosa succede (o, più che altro, il perché succede), così come anche lo è fare le cose a mano piano piano sbattendo la testa sui programmi che non funzionano. Lo svantaggio però è che ti toglie parecchio tempo che potresti dedicare ad altro... in fin dei conti, se non c'è la vera necessità di programmare a basso livello, preferisco anch'io pensare più ad affrontare il problema in sé che non a come a affrontarlo (il che è un bene, IMHO).
cdimauro
29-04-2008, 18:04
Secondo me chi non sa cosa succede "dietro le quinte" non può definirsi vero programmatore, ma semplicemente un buon utilizzatore di cose già pronte.
Il "vero" programmatore deve pensare soltanto a una cosa: risolvere problemi. E per far questo NON è necessario sapere cosa succede "dietro le quinte".
Il "vero" programmatore deve pensare soltanto a una cosa: risolvere problemi. E per far questo NON è necessario sapere cosa succede "dietro le quinte".
Quoto in toto :)
Non scrivo una riga di assembly da almeno 7 anni e mi ritengo un programmatore migliore. Trovo inutile perdere una giornata intera per pensare al numero di istruzioni interne del ciclo per far rimanere tutto dentro alla cache di primo livello del processore di turno.
thread irregolare :asd:
Irregolare? :confused:
DanieleC88
29-04-2008, 19:13
Irregolare? :confused:
http://www.hwupgrade.it/forum/showthread.php?t=1649196
...
:D
http://www.hwupgrade.it/forum/showthread.php?t=1649196
...
:D
È una discussione generica questa in cui chiede l'opinione di altri utenti quindi non serve il tag. Leggete bene il messaggio di cionci ;)
MasterDany
29-04-2008, 19:34
[...]cionci
OT(scusate)Ma che fine ha fatto? :stordita:
DanieleC88
29-04-2008, 19:42
Avrà da studiare/lavorare/altro... ca**i suoi, principalmente, suppongo. :D
Il "vero" programmatore deve pensare soltanto a una cosa: risolvere problemi. E per far questo NON è necessario sapere cosa succede "dietro le quinte".
Non è vero, dipende dal problema che devi risolvere ;)
Quoto in toto :)
Non scrivo una riga di assembly da almeno 7 anni e mi ritengo un programmatore migliore. Trovo inutile perdere una giornata intera per pensare al numero di istruzioni interne del ciclo per far rimanere tutto dentro alla cache di primo livello del processore di turno.
Quando dico "dietro le quinte", non intendo per forza il conoscere l'assembler.. Non dico che uno debba conoscere come funziona il processore a livello di transistor, ci mancherebbe. Ma mi sono accorto che molti programmatori, o presunti tali, sanno solo usare le librerie che danno la pappa pronta, e nient'altro. Ecco, quelli per me non sono programmatori. Inb fin dei conti, per saper usare una libreria, basta impararsi il manuale. Per risolvere problemi invece, ci vuole ingegno.
Quando dico "dietro le quinte", non intendo per forza il conoscere l'assembler.. Non dico che uno debba conoscere come funziona il processore a livello di transistor, ci mancherebbe. Ma mi sono accorto che molti programmatori, o presunti tali, sanno solo usare le librerie che danno la pappa pronta, e nient'altro. Ecco, quelli per me non sono programmatori. Inb fin dei conti, per saper usare una libreria, basta impararsi il manuale. Per risolvere problemi invece, ci vuole ingegno.
Avevo interpretato male il tuo messaggio allora. Sul fatto che non ci si debba fermare al solo uso degli strumenti già pronti siamo d'accordo. Un buon programmatore dovrebbe essere in grado di crearsi anche i propri strumenti se quelli che ha non gli permettono di risolvere il problema ma questo richiede un certo livello di preparazione che non tutti hanno ma soprattutto richiede anni di esperienza sul campo.
Secondo me l'unico problema della "nuova generazione" è semplicemente che hanno avuto meno tempo per fare esperienze e non dal fatto che i nuovi linguaggi danno tutto pronto.
DanieleC88
30-04-2008, 12:02
Secondo me l'unico problema della "nuova generazione" è semplicemente che hanno avuto meno tempo per fare esperienze e non dal fatto che i nuovi linguaggi danno tutto pronto.
Che intendi con "hanno avuto meno tempo"? Io in fondo mi ritengo abbastanza della "nuova generazione" (ok ormai non ho più 14 anni, ma non sono un programmatore di vecchia data, insomma :D), però da quando mi sono appassionato alla programmazione ho pensato da solo a scoprire cose nuove, anche a costo di scendere in cose di basso livello. Ora che sto all'università continuo a cercare di imparare cose nuove... insomma, diciamo che il tempo l'ho avuto. :)
Che intendi con "hanno avuto meno tempo"? Io in fondo mi ritengo abbastanza della "nuova generazione" (ok ormai non ho più 14 anni, ma non sono un programmatore di vecchia data, insomma :D), però da quando mi sono appassionato alla programmazione ho pensato da solo a scoprire cose nuove, anche a costo di scendere in cose di basso livello. Ora che sto all'università continuo a cercare di imparare cose nuove... insomma, diciamo che il tempo l'ho avuto. :)
Semplicemente che chi è nato prima ha avuto più tempo. Il mio primo computer è del 17/12/1988 quindi se non sei un alieno io sono partito quei 7/8 ani prima di te. :D
khelidan1980
30-04-2008, 12:32
però da quando mi sono appassionato alla programmazione ho pensato da solo a scoprire cose nuove, anche a costo di scendere in cose di basso livello. Ora che sto all'università continuo a cercare di imparare cose nuove... insomma, diciamo che il tempo l'ho avuto. :)
Questo imho è un requisito di base,ma non solo nella programmazione,in tutto ciò che si fa per hobby,per passione,per lavoro...credo che il topic fosse molto piu preciso,voleva proprio fare un paragone tra chi ha iniziato già nell'era dei linguaggi managed e quelli che iniziarono con l'assembly,perchè c'era quello e al massimo il c,basic....
cdimauro
30-04-2008, 12:39
Non è vero, dipende dal problema che devi risolvere ;)
Se è fra i requisiti, certamente. I requisiti devono essere risolti, ci mancherebbe. :cool:
Quando dico "dietro le quinte", non intendo per forza il conoscere l'assembler.. Non dico che uno debba conoscere come funziona il processore a livello di transistor, ci mancherebbe. Ma mi sono accorto che molti programmatori, o presunti tali, sanno solo usare le librerie che danno la pappa pronta, e nient'altro. Ecco, quelli per me non sono programmatori. Inb fin dei conti, per saper usare una libreria, basta impararsi il manuale. Per risolvere problemi invece, ci vuole ingegno.
Questo è un altro discorso ed è condivisibile. ;)
DanieleC88
30-04-2008, 13:44
Semplicemente che chi è nato prima ha avuto più tempo. Il mio primo computer è del 17/12/1988 quindi se non sei un alieno io sono partito quei 7/8 ani prima di te. :D
Direi che ci hai preso più o meno. :D
Il tuo primo computer è giusto un po' più giovane di me, io ho cominciato a programmare forse a 13 anni. Comunque, be', chi è nato prima fino ad adesso ha avuto più tempo, chiaro, quelli che sono nati dopo lo avranno in seguito. ;)
Questo imho è un requisito di base,ma non solo nella programmazione,in tutto ciò che si fa per hobby,per passione,per lavoro...credo che il topic fosse molto piu preciso,voleva proprio fare un paragone tra chi ha iniziato già nell'era dei linguaggi managed e quelli che iniziarono con l'assembly,perchè c'era quello e al massimo il c,basic....
Sì, certo, solo intendevo dire, ammetto però di non essermi espresso bene, che chi vuole può scavare nei meandri dell'assembly ancora oggi, magari però partendo da linguaggi che permettono una programmazione concettualmente più semplice. Un ragazzino che inizia a programmare adesso con linguaggi più "comodi" raggiunge i primi risultati in breve tempo ed evita di sbattere troppo la testa con cose che possono essere demoralizzanti. Semplicemente, ora c'è più scelta, ma chi vuole può decidere in ogni momento di percorrere la strada più tosta per imparare cosa c'è "dietro". :)
ciao ;)
Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT.
D3stroyer
30-04-2008, 15:11
dipende comunque io ho fatto l'uni negli ultimi anni(sto facendo la tesi ora) e l'approccio a basso livello c'è stato con tanto di programmazione in assembly,ovvio sicuramente il tempo dedicato è decisamente minore di quello di 20 anni fa ma allora non c'era java e compagnia bella da studiare! ;)
E anche una questioni di ottimizzare il tempo in base a ciò che po realmente ti servirà sapere
dai l'assembly universitario è completamente inutile se non per capire piu' o meno cosa succede nei giri tra registridimemoria&friends. Magari ci può essere un vantaggio attuale per chi l'assembly l'ha usato per anni..non per 4 mesi.
cdimauro
30-04-2008, 15:23
Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT.
Beati loro: tanti mal di testa in meno. :p
khelidan1980
30-04-2008, 16:37
dai l'assembly universitario è completamente inutile se non per capire piu' o meno cosa succede nei giri tra registridimemoria&friends. Magari ci può essere un vantaggio attuale per chi l'assembly l'ha usato per anni..non per 4 mesi.
infatti il target è quello e imho deve essere quello,essere da supporto allo studio di un architettura,capire come funziona dietro le quinte un pc,un esempio di come anche adesso si fanno cose a basso livello,ma per l'appunto si fanno a scopo didattico non certo per essere produttivi
Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT. non c'azzecca una sega :asd:
nemmeno chi è incappato in un segmentation fault necessariamente sa cos'è un segmento; per saperlo devi studiare, punto.
e comunque Java non ti protegge affatto dai puntatori nulli (anche se nello specifico prendono il nome di "riferimenti" anziché "puntatori", e nonostante l'incoerenza del nome della NullPointerException).
non c'azzecca una sega :asd:
nemmeno chi è incappato in un segmentation fault necessariamente sa cos'è un segmento; per saperlo devi studiare, punto.
Se uno incappa in un problema e non approfondisce cavoli suoi. Io lo faccio sempre. Più sbatti la testa su un problema e più impari. Quando tutto fila liscio, difficile che uno si preoccupi di tanti aspetti..
e comunque Java non ti protegge affatto dai puntatori nulli (anche se nello specifico prendono il nome di "riferimenti" anziché "puntatori", e nonostante l'incoerenza del nome della NullPointerException).
Non ho mica detto che in Java non possa capitare. Ma di sicuro capita molto più facilmente programmando in C che in Java ;) Le varie librerie che ci sono in giro, per qualsiasi linguaggio, semplificano la vita certamente, ma ti nascondono molte cose. Vuoi un esempio: un mio amico laureato in Informatica, quindi non il primo che passa, mi ha chiesto a cosa serva studiarsi gli algoritmi di ordinamento affermando che tanto lo fanno le librerie! Ecco ditemi voi se questo è il modo rdi ragionare. Quindi se uno usa una libreria può allegramente dimenticarsi tutto quello che c'è dietro? Forse per un mero utilizzatore si, ma non un programmatore. Ma qualcuno dovrò pur farla quella libreria no? Quindi qualcuno dovrà pure impararsi gli algoritmi di ordinamento.
Io ribadisco che chi si limita ad usare le librerie, senza sapere minimamente cosa ci sia dietro, NON è un programmatore. Poi, come tutte le cose, più conosci a fondo lo strumento che usi, meglio è.
Se uno incappa in un problema e non approfondisce cavoli suoi. Io lo faccio sempre. Più sbatti la testa su un problema e più impari. Quando tutto fila liscio, difficile che uno si preoccupi di tanti aspetti.. per quale assurdo motivo della terra uno dovrebbe studiare solo quando c'è un problema? a me per esempio tocca studiare ogni giorno cose che risolvono problemi che non vedrò mai (faccio l'università).
a chi ottiene un segmentation fault in genere gli si spiega che non può accedere ad indirizzi di memoria non allocati, questo è quanto; la nozione di segmento non ha nulla a che vedere ne' col linguaggio C ne' con la soluzione del problema del segfault, e potrebbe non esistere neanche su determinate architetture. alla vittima del segfault non si spiega cos'è un segmento, si dice solamente che se accede ad un indirizzo che punta a memoria non allocata ottiene un generico "errore" (che tra l'altro su Windows non si chiama neanche "segmentation fault", e che tra l'altro credo che su Linux non sia neanche un "segmentation fault").
Non ho mica detto che in Java non possa capitare. Ma di sicuro capita molto più facilmente programmando in C che in Java ;) beato te.
per quale assurdo motivo della terra uno dovrebbe studiare solo quando c'è un problema? a me per esempio tocca studiare ogni giorno cose che risolvono problemi che non vedrò mai (faccio l'università).
Ma chi l'ha detto questo ?:confused: Io ho solo detto che se uno si imbatte in un problema, cerca di capire da dove venga e di risolverlo. Non che sia l'unico modo per imparare quel determinato argomento. Si impara molto anche dagli errori che si commette. Java ha un controllo della memoria migliore di C, quindi ti evita molti problemi che con il C ti ci imbatti per forza.
Ma chi l'ha detto questo ?:confused: Io ho solo detto che se uno si imbatte in un problema, cerca di capire da dove venga e di risolverlo. hai dato un'occhiata a quello che ho scritto dopo le due righe quotate?
Java ha un controllo della memoria migliore di C, quindi ti evita molti problemi che con il C ti ci imbatti per forza. Java ti evita tutt'altra categoria di problemi di memoria dinamica: ti impedisce di creare puntatori dal nulla o di sovrascriverne il valore per errore e ti risparmia dal deallocare gli oggetti, ma i riferimenti nulli non te li toglie nessuno.
io vorrei tanto che esistesse un linguaggio di programmazione basato sui null objects :cry:
cdimauro
01-05-2008, 17:08
Non credo esisterà mai, perché le esigenze sono sempre diverse.
Voglio che quando chiamo un metodo venga sollevata un'eccezione? O che mi venga ritornato un valore "standard" (0, 0.0, '', ecc.)? O una combinazione dei due?
Dipende sempre dal preciso contesto in cui viene usato un null object, e questo... può saperlo soltanto il programmatore. :p
hai dato un'occhiata a quello che ho scritto dopo le due righe quotate?
Java ti evita tutt'altra categoria di problemi di memoria dinamica: ti impedisce di creare puntatori dal nulla o di sovrascriverne il valore per errore e ti risparmia dal deallocare gli oggetti, ma i riferimenti nulli non te li toglie nessuno.
io vorrei tanto che esistesse un linguaggio di programmazione basato sui null objects :cry:
E perche' non direttamente uno dove gli oggetti null non ci sono e basta ? (A meno che uno non lo voglia si intende). Quelli ci sono
Non credo esisterà mai, perché le esigenze sono sempre diverse.
Voglio che quando chiamo un metodo venga sollevata un'eccezione? O che mi venga ritornato un valore "standard" (0, 0.0, '', ecc.)? O una combinazione dei due?
Dipende sempre dal preciso contesto in cui viene usato un null object, e questo... può saperlo soltanto il programmatore. :p si, ma non c'è supporto sintattico per deciderlo: in Java i null objects te li devi creare manualmente, altrimenti il riferimento non inizializzato resta nullo. a me piacerebbe un linguaggio dove ad esempio per ogni metodo che definisci puoi definire anche il comportamento del null object, oppure se non ne definisci uno ne viene adottato uno di default. esempi di comportamenti di default:
tornare 0 per gli interi
0.0 per i numeri a virgola mobile
lanciare eccezione per i booleani
stringa vuota per le stringhe
null object per le classi
E perche' non direttamente uno dove gli oggetti null non ci sono e basta ? (A meno che uno non lo voglia si intende). Quelli ci sono ma immagino non abbiano molto supporto dalla loro... comunque (domando scusa per l'abissale ignoranza), esempi?
cdimauro
02-05-2008, 07:24
si, ma non c'è supporto sintattico per deciderlo: in Java i null objects te li devi creare manualmente, altrimenti il riferimento non inizializzato resta nullo. a me piacerebbe un linguaggio dove ad esempio per ogni metodo che definisci puoi definire anche il comportamento del null object, oppure se non ne definisci uno ne viene adottato uno di default. esempi di comportamenti di default:
tornare 0 per gli interi
0.0 per i numeri a virgola mobile
lanciare eccezione per i booleani
stringa vuota per le stringhe
null object per le classi
Sì, ho capito Alberto ma, come dicevo, un comportamento "standard" non andrebbe bene per qualunque situazione.
Quella che proponi sarebbe un'ottima soluzione: supporto sintattico (magari tramite qualche annotazione, per non appesantire troppo il linguaggio) per specificare il comportamento almeno per quello di default, che potrebbe coprire buona parte dei casi (che è moooolto meglio di niente :D).
Per il resto, vediamo cosa suggerisce Marco. :)
altra idea che mi viene in mente: il programmatore potrebbe non aver bisogno di un null object perché potrebbe sapere a priori che ogni riferimento di quella classe verrà sempre inizializzato; in tal caso il supporto sintattico per questa situazione dovrebbe far sì che il compilatore dia errore per ogni riferimento non inizializzato.
Sì, ho capito Alberto ma, come dicevo, un comportamento "standard" non andrebbe bene per qualunque situazione.
Quella che proponi sarebbe un'ottima soluzione: supporto sintattico (magari tramite qualche annotazione, per non appesantire troppo il linguaggio) per specificare il comportamento almeno per quello di default, che potrebbe coprire buona parte dei casi (che è moooolto meglio di niente :D).
Per il resto, vediamo cosa suggerisce Marco. :)
Ne avevamo gia' parlato tempo fa se non sbaglio. Secondo me il linguaggio i puntatori a null proprio non dovrebbe permetterli, in quanto questa concessione e' semanticamente sbagliata
Foo x;
non indica in realta' un oggetto di tipo Foo, ma 0 o 1 oggetti di tipo Foo. Forse mi sbaglio ma sopprerire a questo in Java (ad esempio con una classe Wrapper scritta dall'utente) non e' banale .In ogni caso il linguaggio dovrebbe favorire il comportamento piu' "safe", lasciando la possibilita' di inserire puntatori nulli solo quando serve. Ovviamente se cosi' fosse ci vorrebbe un modo relativamente semplice per poter indicare la potenziale assenzad del puntatore.
Tra i linguaggi con tipizzazione statica (per quelli dinamici ovviamente la questione non ha molto senso) che si comportano correttamente che io sappia ci sono quelli della famiglia ML, e Haskell, Clean, dove tra l'altro l'indicazione della mancanza di oggetto e' gestita in modo molto elegante con i tipi algebrici.
altra idea che mi viene in mente: il programmatore potrebbe non aver bisogno di un null object perché potrebbe sapere a priori che ogni riferimento di quella classe verrà sempre inizializzato; in tal caso il supporto sintattico per questa situazione dovrebbe far sì che il compilatore dia errore per ogni riferimento non inizializzato.
Esatto, era la mia idea e, secondo me, il modo migliore per gestire la cosa.
cdimauro
02-05-2008, 20:33
Ne avevamo gia' parlato tempo fa se non sbaglio. Secondo me il linguaggio i puntatori a null proprio non dovrebbe permetterli, in quanto questa concessione e' semanticamente sbagliata
Foo x;
non indica in realta' un oggetto di tipo Foo, ma 0 o 1 oggetti di tipo Foo.
Sì, ricordo che ne avevamo parlato, e infatti l'idea è quella di non avere proprio puntatori a null, ma soltanto istanze "particolari" di una certa classe.
Forse mi sbaglio ma sopprerire a questo in Java (ad esempio con una classe Wrapper scritta dall'utente) non e' banale .In ogni caso il linguaggio dovrebbe favorire il comportamento piu' "safe", lasciando la possibilita' di inserire puntatori nulli solo quando serve. Ovviamente se cosi' fosse ci vorrebbe un modo relativamente semplice per poter indicare la potenziale assenzad del puntatore.
Ed è appunto da dove è nato il dibattito: che tipo di Null Object possiamo utilizzare? Domanda non banale, vista la moltitudine di soluzioni allo scopo.
Tra i linguaggi con tipizzazione statica (per quelli dinamici ovviamente la questione non ha molto senso) che si comportano correttamente che io sappia ci sono quelli della famiglia ML, e Haskell, Clean, dove tra l'altro l'indicazione della mancanza di oggetto e' gestita in modo molto elegante con i tipi algebrici.
Ecco, questa è una cosa che non conoscevo e che, a questo punto, merita un approfondimento, visto che sembra una "bella" soluzione al problema.
Lo farò appena avrò un po' di tempo per studiarmi Haskell (che fra i tre è quello che da tempo mi ispira di più). :p
Ed è appunto da dove è nato il dibattito: che tipo di Null Object possiamo utilizzare? Domanda non banale, vista la moltitudine di soluzioni allo scopo.
La maggior parte dei casi in cui si effettivamente vuole gestire la presenza o meno di un oggetto si puo' gestire come una sequenza( lista, array?) di al piu' 1 elemento. In questo modo la soluzione diventa abbastanza naturale.
La maggior parte dei casi in cui si effettivamente vuole gestire la presenza o meno di un oggetto si puo' gestire come una sequenza( lista, array?) di al piu' 1 elemento. In questo modo la soluzione diventa abbastanza naturale. fa schifo :O
anche perché non tutti i metodi ritornano void, anzi quasi nessuno. non è una soluzione implementabile.
Ed e' per questo che esistono le fold e le map... vorrei fare un esempio ma non mi viene in mente un caso decente oggi :p, se riesci a proporne uno vediamo come si potrebbe fare.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.