Programmare Bene, Programmare Male - Messaggi spsostt da:"Flusso In Ladder ... Ma Dai!"

[walterword]

x livio :

"Gli animali si riuniscono in gregge, gli uomini si riuniscono in comunità "

in comune abbiamo le stalle

[Nicola Carlotto]

il microprocessore se ne fotte di come venga fatto il codice prima della compilazione,

cop, awl, fup sono solo interfacce create per creare un codice che poi viene compilato ed inviato alla lettura del processore del plc.

Il programma perche' sia funzionante deve essere solo quello giusto, non puo' esistere un programma mal fatto , quindi noi umili programmatori di plc non possiamo che essere tecnici individuatori dell' unica soluzione possibile per far si che l'automazione funzioni autonomamente.

tutta la storia della struttura del programma ,quella interpretata per la nostra comprensione da un eventuale programma plc omron o siemens o altro, dipende dal programmatore e dalla maniera che ha per ordinare le cose e renderle riconducibili tra loro.

se sono ben fatte sono anche ordinate di conseguenza.

A volte i programmi vengono fatti incasinati anche solo per far si che non siano capiti di proposito.

Ciao a Tutti

NICA

[walter.r]

Esiste solo un programma ben progettato e ben scritto o un programma mal fatto.

La soluzione perfetta non esiste.

Scusa se non ho forse capito bene, Livio, ma non ti pare di contraddirti ??

Chiariamo una cosa: è ( per me...) ovvio che alla programmazione bisogna anteporre l'analisi: se non hai chiaro il problema, come scrivi la soluzione ??

C'è differenza tra la grossa azienda, dove l'analista e il programmatore sono due entità diverse, e il free lance come sono io, perchè faccio l'analista e il programmatore, e come dici giustamente tu, a volte in contemporanea ( sai, da anni programmo solo PLC multitasking, anche la mia mente si è abituata.. )

Da quello che scrivi arguisco che tu non abbia mai lavorato in un gruppo.

No, Livio, non è così. Ripensa un attimo a cosa ha scritto Batta: lavorando in gruppo il concetto fondamentale è lo scambio di informazioni, i "confini" comuni entro i quali le cose funzionano, NON gli specifici contenuti. E' come la storia infinita dei software per PC: la cosa importante non è l'applicativo che usi, ma il formato di file che generi, se non vuoi essere tagliato fuori per .....mancata comprensione dei tuoi lavori.

....programmare non deve e non può essere un fatto artistico.

Io invece sono convinto che quando una certa routine ti riesce particolarmente bene, oppure quando riesci a risolvere con 10 righe di codice un problema che con un diverso approccio richiederebbe molto più spazio, provi una intima soddisfazione. Non sarà "artistico", possiamo discutere sui termini, ma di certo non è neanche fredda esecuzione di schemi già noti.

Siamo umani, caspita !!!

E, per concludere.....

Diffido sempre dei programmatori "artisti". O sono personaggi che, per costituzione, rifiutano disciplina e rigore, oppure saltano bellamente la fase di analisi, o rifiutano che ci sia qualcun altro che la esegua.

Posso capire la tua posizione, in certi ambienti è quasi obbligatorio ragionare così, ma per fortuna non in tutti.

Disciplina e rigore: per me sono concetti usuali. Io li applico sempre nei rapporti con i clienti, se do' una data, è quella, se dico che faccio una cosa, è quella.

Poi, il come scrivo i miei programmi è una cosa che riguarda solo la mia serietà professionale, e una volta che il lavoro è consegnato, funzionante, commentato, etc.... io sono soddisfatto, il cliente anche.

E se nel lavoro c'è anche qualche "bella" soluzione di programmazione ( o di analisi applicata, se preferisci..), meglio ancora !

[Nicola Carlotto]

Io invece sono convinto che quando una certa routine ti riesce particolarmente bene, oppure quando riesci a risolvere con 10 righe di codice un problema che con un diverso approccio richiederebbe molto più spazio, provi una intima soddisfazione. Non sarà "artistico", possiamo discutere sui termini, ma di certo non è neanche fredda esecuzione di schemi già noti.

Siamo umani, caspita !!!

hai solo trovato la soluzione tecnica piu' efficace non ti sei inventato niente di nuovo, creativo , unico ..

Ciao NICA

[walterword]

ciao NIKa

quello che dici e' vero , solo che però c'e' un piccolo particolare ,

e cioe che e' fuori luogo (quello che dici )

Il discorso era basato su concetti molto semplici e a pelle.

Quello che dici e' comunque vero

ciao

walter

p.s. quello che dici e' sempre vero , ma in parte non lo e' te lo dimostro con un semplice esempio :

voglio indicizzare una tabella , utilizzando diversi indici o puntatori .

Lo posso fare in kop o fup ?

No , quindi gia questo piccolo esempio dimostra che non sono la stessa cosa

Che poi la logica compilata in awl e poi hex per il plc sia uguale ok , ma nel mio esempio non si puo fare

Modificato: 8 ottobre 2006 da walterword

[TravelMen]

Io invece sono convinto che quando una certa routine ti riesce particolarmente bene, oppure quando riesci a risolvere con 10 righe di codice un problema che con un diverso approccio richiederebbe molto più spazio, provi una intima soddisfazione.

Concordo pienamente xchè è un qualcosa che ti piace vedere e rivedere e mentre lo vedi ti senti soddisfatto, se mi consetite un paragone forte ma a tema, e come x un cultore d'arte quardare il quadro della Gioconda!!

P.S. io quando ho visto la Gioconda non mi ha fatto ne galdo ne freddo

Aggiungerei che quando trovi la strada/soluzione ad un problema, come se ti col**e un fulmine a cel sereno, il codice lo scrivi di botto senza pensarci su troppo, ed il debug è cosa da poco, e mentre lo fai (scrivi la soluzione) dentro te si fa strada la consapevolezza di essere in gamba e di ta stimoli x continuare a dare il meglio di te.

In questi casi provo un emmozione intensa che mi fa aprezzare il mio lavoro, e mi da soddisfazione e mi ripaga ti tutta la m***a che ricevo quando arrivo su di un impianto, con il cliente In*******a alla n+1 potenza.

Modificato: 9 ottobre 2006 da TravelMen

[mynameisrex]

Ciao Nica,

scusa ma riesco a essere d'accordo con te solo su un punto : ovvero [...che il microprocessore "se ne fotta" di come venga fatto il codice prima della compilazione...].

Questo è vero, è indubitabile ma... quando qualcun'altro si ritrova a dover mettere mano al tuo programma (o magari tu stesso dopo diversi mesi/anni) di certo non si mette a fare ragionamenti con il microprocessore...

No. Si mette semplicemente a leggere "quel" codice che, se scritto correttamente, seguendo una logica coerente e magari con un discreto commento risulterà facilmente comprensibile, altrimenti...

E, forse nessuno ci ha mai litigato, ma c'è anche una cosa che si chiama "tempo ciclo" e a volte ti tocca farci i conti : un problema - come è stato detto in più punti - ha molteplici modi per essere affrontato e, pertanto, propone molteplici soluzioni; ma non dimentichiamoci che INNANZITUTTO stiamo andando a realizzare un processo produttivo e, a volte, anche la soluzione più "bella" non è necessariamente la più "veloce" (in termini di elaborazione).

Quindi, se è vero che "...tutte le strade portano a Roma..." ricordiamoci anche che esiste la strada più breve, la più veloce, la meglio segnalata...

Buona settimana a tutti !

[batta]

Questo non dovrebbe appartenere alla programmazione, bensì all'analisi. Mi rendo conto che, come sempre, alla base di tutto c'è un problema di semantica. probabilmente non sei abituato a dividere le due fasi, o lo fai in modo automatico.

Quando parlo di sviluppo di un programma non mi riferisco solo alla scrittura del codice, ma a tutto quello che comporta. Non riesco quindi a vedere l'analisi come qualcosa non facente parte della programmazione.

In ogni caso, anche lasciando l'analisi (che non si è ancora definito se possa sessere considerata o meno artistica e/o creativa) ad altri e pensando solo alla scrittura del codice, rimane il fatto che per ottenere lo stesso risultato (apparente) ci sono strade diverse. E' come la foto del pargoletto fatta dal papà oppure fatta da un artista della pellicola. Sono entrambe foto di un pargoletto. Posso chiedere a chiunque cosa sono e mi risponderanno tutti: la foto di un pargoletto. Una però, probabilmente, susciterà emozioni solo nel suo papà, mentre l'altra sarà in grado di suscitare emozioni in più persone.

Lo stesso si può dire per due programmi che fanno funzionare una macchina nello stesso modo. Quando guardi il codice ti accorgi delle enormi differenze che ci possono essere.

Insomma, a me capita di mettere le mani in programmi fatti da altri e di pensare: "Questo è proprio una schifezza di programma". Oppure: "Ca**o! Chi ha fatto questo programma? Questo sì che ci sa fare!" Questo vuol dire suscitare emozioni. E' qualcosa che va oltre al semplice giudizio sul fatto che il programma sia fatto più o meno bene.

Per me si può notare, se c'è, una certa eleganza in un codice. Sicuramente si può parlare di stile. Se per un programma posso usare termini come eleganza e stile, posso ritenere che si tratti di qualcosa che si può almeno avvicinare ad una certa forma d'arte.

Per Nica

hai solo trovato la soluzione tecnica piu' efficace non ti sei inventato niente di nuovo, creativo , unico ..

Ragionando così si può anche dire che Leonardo da Vinci ha solo fatto un bel ritratto, o che il fotografo professionista che ha scattato la foto al pargoletto è riuscito a fare in modo che guardando la foto riconosco il soggetto fotografato. Questo era, in fondo, l'obbiettivo da raggiungere. Non c'è nulla, quindi, che differenzi questa foto da qualla fatta dal papà: entrambe hanno raggiunto l'obbiettivo.

Se vogliamo considerare la programmazione un puro fatto tecnico, che dire della musica?

Nella musica ci sono regole ferree da rispettare. Le frequenze delle note sono ben definite. Usiamo una divisione in toni e semitoni (se non sbaglio, nella musica araba usano anche i quarti di tono). Note combinate assieme in modo opportuno (non casuale, ma anche qui dettato da precise regole) creano armonia.

Eppure, con sette note e regole molto precise guardate, anzi, ascoltate, cosa si può fare.

[ifachsoftware]

Personalmente ritengo che scrivere un programma decentemente significhi

1) Aver fatto un'attenta analisi del problema

2) Aver considerato il caso peggiore e quello migliore.

3) Scrivere del codice semplice e comprensibile utilizzando oltre che i commenti ovunque sia possibile (sequenze logiche) una strutturazione Grafcet oppure flow-chart per gli altri casi.

4) Personalmente prediligo la leggibilita' del codice alla velocita' di esecuzione e se quest'ultima e' fondamentale meglio fare delle funzioni le piu' piccole possibili (focalizzandosi solo su quelle che incidono maggiormente sui tempi di ciclo).

5) Aver fatto un programma che funzioni in tutte le possibili combinazioni

Ciao

[Livio Orsini]

walter.r

Se tu considerassi tutto il periodo:

La soluzione migliore è quella che, dopo avere analizzato pragmaticamente tutte le esigenze, adotta il miglior compromesso tra di esse. La soluzione perfetta non esiste.

, e non solo l'ultima frase, ti accorgeresti che non c'è contraddizione.

Poi puoi continuare a considerarti un artista. Sono affari tuoi.

Io insisto che ritenere che la programmazione non è un fatto artistico, secondo il mio concetto di arte. Concetto che torno a ripetere: artistico è qualche cosa che trascende il razionale ed interagisce con la sfera emozionale.

Sarà la vecchiaia, saranno gli oltre 40 anni di professione, ma a me un bell'algoritmo od una bella funzione non procurano nessuna emozione.

Se risolvo un certo problema in modo brillante ritengo di aver svolto il mio lavoro al meglio. Idem se riconoosco che la soluzione di un collega è migliore della mia.

E con questo vorrei chiudere la diatriba sul fatto che la programmazione sia un fatto artistico o meno. Il vero argomento è: come deve essere progettato un programma per essere considerato esiguito secondo le regole dell'arte (secondo la 5.a definizione di arte riportata da Batta )

Io continuo ad esere convinto che una buona programmazzione debba rispettare ferree regole di impostazione ed organizzazione.

Questa convinzione non è una mia invnezione ma, al contrario, è la base degli insegnamenti di tutte le scuole di informatica degne di questo nome.

Scrivere apposiamente male un programma per renderlo poco comprensibile è un mezzuccio da ladri di polli che si ritorce solo contro l'autore.

Se voglio analizzare e capire un programma altrui lo posso fare sempre e comunque; l'unica condizione è che la mia conoscenza professionale sia suffiicente. Se invece chi "analizza" il programma cerca solo di copiare pedissequamente, anche se lo scrivi bene non lo capirà.

Se anche per i programmi di PLC si cominciassero ad applicare seriamente le Regole di Qualità del Software molti programmi sarebbero buttati nel cestino.

Purtroppo fino a che si manda la macchina al cliente finale senza aver scritto una riga di software, perchè tanto lo si scrive durante la fase di messa in servizio, parlare di qualità del software è una bestemmia.

Modificato: 9 ottobre 2006 da Livio Orsini

[batta]

Se anche per i programmi di PLC si cominciassero ad applicare seriamente le Regole di Qualità del Software molti programmi sarebbero buttati nel cestino.

Purtroppo fino a che si manda la macchina al cliente finale senza aver scritto una riga di software, perchè tanto lo si scrive durante la fase di messa in servizio, parlare di qualità del software è una bestemmia.

Su questo, purtroppo, penso non si possa che essere assolutamente d'accordo.

Io continuo però a vedere un programma come qualcosa di più di una fredda sequenza di istruzioni logiche. Facciamo un paragone con la fotografia, considerata un'attività artistica (almeno a certi livelli). Per fare una bella foto si deve prima di tutto conoscere la tecnica. Devi sapere come inquadrare un soggetto, qual è l'obiettivo più adatto ad un certo tipo di ripresa, lavorare su tempi e diaframmi (legati tra loro da formule matematiche) per ottenere la giusta profondità di campo, saper correggere l'indicazione dell'esposimetro in base alle condizioni di ripresa, e molto altro. Tutte cose estremamente tecniche. Però due fotografi, con la stessa attrezzatura e le stesse conoscenze tecniche, faranno inevitabilmente (per fortuna) foto diverse.

Lo stesso si può dire di due programmatori di pari livello tecnico: scriveranno inevitabilmente (per fortuna o purtroppo?) software diversi.

Con questo smetterò di fare considerazioni su eventuali risvolti artistici del software e seguirò il tuo giusto invito a tornare sull'argomento principale, sicuramente più importante. Molto più importante.

[walter.r]

Poi puoi continuare a considerarti un artista. Sono affari tuoi.

Livio, non credo di avere mai detto che IO mi considero un'artista, ho detto che il saper fare in modo riuscito ed originale una cosa ( non solo la programmazione, estendiamo pure il concetto ), è in qualche modo una forma di arte.

E qui chiudo anch'io l'argomento.

Io continuo ad esere convinto che una buona programmazione debba rispettare ferree regole di impostazione ed organizzazione.

Certo, anch'io condivido. Ognuno di noi credo già segua delle proprie regole.

Per dirla tutta, quello che non credo è che le regole possano essere totalmente condivise.

Prendiamo ciò che dice Ifachsoftware nel post #34. Sono cose assolutamente sottoscrivibili, ma mi domando: siamo sicuri che la definizione " codice semplice e comprensibile " abbia per tutti lo stesso significato?

Io penso di no: chi ha studiato programmazione all'università avrà di certo un approccio diverso dal quadrista evoluto, che ha sostituito l'elettromeccanica con il PLC. Sono questi i due poli estremi del modo di scrivere e leggere un software, ma entrambi validi, nel loro campo di applicazione.

Il fatto che un quadrista non sappia cos'è il C# o il Grafcet, e che un ingegnere non sappia cos'è il Ladder ( qualcuno l'ho conosciuto...) non significa che entrambi non sappiano fare bene il loro lavoro.

Secondo me non c'è un metodo, un sistema migliore in assoluto di tutti gli altri, e qui nasce la capacità dei tecnici di individuare fra tanti il giusto modo di affrontare un determinato problema.

[Livio Orsini]

Per dirla tutta, quello che non credo è che le regole possano essere totalmente condivise.

Questa è la vera divergenza di impostazione tra noi due.

Che si pensi alla programmazione come fatto artistico o meno è molto secondario, puòm essere, eventualmente, un interessante argomento di dibattito quando non si ha di meglio da fare.

Invece sulle regole la questione non è secondaria.

Che tu codifichi usando il Pascal classico o il ladder diagram le regole della buona programmazione non mutano.

Un programma può essere assolutamente mal fatto usando il Pascal, oppure può essere ottimamente organizzato usando il ladder diagram.

La qualità del software è indipendente dalla brillantazza delle soluzioni.

Considera il caso limite di programma in cui tutte le funzioni sono state ottimizzate al massimo, se il programma è mal organizzato sarà sempre un pessimo programma.

Cosa significa mal organizzato? All'organizzazione dei programmi sono dedicati interi testi, riassumere il concetto in poche righe è impossibile. Faccio solo un esempio banale, ma molto frequente, di disorganizzazione.

Consideriamo l'esempio precedente: programma estremamente ottimizzato, tutto gira perfettamente. Durante il periodo di messa in servizio ci si rende conto che la macchina necessita di una modifica nel ciclo di lavorazione. Ovviamente questa modifica coinvolgerà anche il programma del PLC. Qui cominciano i guai. Risulta praticamente impossimbile effettuare la modifica se non ritoccando, modificando e magari riscrivendo la gran parte delle funzioni.

Questo è un pessimo programma perchè manca uno dei requisiti fondamentali: la manutenibilità.

Ripeto il concetto fondamentale: al qualità del programma è indipendente dal linguaggio usato.

Ho visto ottimi programmi scritti in ladder diagram. Programmi dove, a distanza anche di anni, era posibile aggiungere, modificare, togliere funzioni intervenendo solamente sul software di interfaccia.

Ho visto pessimi programmi, scritti in "C" da presuntuosi e paludati informatici, dove non era possibile modificare alcunchè senza il terrore che crollasse tutto.

...siamo sicuri che la definizione " codice semplice e comprensibile " abbia per tutti lo stesso significato?

Deve avere il medesimo significato per tutti. La lingua italiana è piuttosto precisa.

La comprensibilità, dato per scontato che il lettore conosca il linguaggio, è incontrovertibile. Se, per assurdo, devi ragionare tre giorni per capire una riga di codice, sicuramente l'aggettivo comprensibile non è applicabile. Se il codice è comprensibile, automaticamente è anche semplice, mentre non vale il viceversa (semplice non smepre è comprensibile).

Modificato: 9 ottobre 2006 da Livio Orsini

[Livio Orsini]

Lo stesso si può dire di due programmatori di pari livello tecnico: scriveranno inevitabilmente (per fortuna o purtroppo?) software diversi.

Anche due tornitori, di pari capacità professionale, eseguendo le medesime lavorazioni dei medesimi pezzi, daranno prodotti con differenti caratteristiche. Diciamo che è arte? Possiamo anche dirlo, basta mettersi d'accordo sulla semantica. Possiamo dire che è creatività? Forse in modo molto forzoso.

Se consideriamo arte la programmazione, qualsiasi lavoro che richieda impegno intellettuale è arte. Anzi, per esperienza personale, considero molto più artistica la progettazione di circuiti con componenti discreti. Anche se quest'attività è quasi estinta per cause di progresso tecnologico.

Però mi ero ripromesso di smetterla e sono ricaduto nell'erore. Mi cospargo il capo di cenere, chiedo perdono e prometto di non farlo più. Almeno fino alla prossima occasione

[Water]

se volete risolvo il problema "artistico"

la programmazione bella o bellissima che sia, NOn può essere arte!

il perchè ve lo spiego subito rubando una definizione (mai definita)

di un amico carissimo nonchè artista e professore di storia dell'arte

ovviamente non è farina del mio sacco e la riporto stringata:

l'arte è quella cosa che si fa per il solo piacere di farla

se fai qualcosa per essere venduta non è più arte ...

un cavatappi può essere un opera d'arte ma se se lo crei per venderlo

diventa un oggetto di designe, e quindi tu, sei solo un "bravo artigiano"

si sono scritti fiumi d'inchiostro sull'argomento, libri, incontri ..

ma il nocciolo è che l'arte non nasce come prodotto ma come piacere,

è vero che gli artisti vendono le loro opere, ma queste,

"non dovrebbero" nascere come prodotti da mettere sul mercato ...

altra cosa rimanendo in tema, è l'ingeno o l'originalità di un prodotto

buona serata, Giuseppe

[batta]

La voglia di rispondere è tanta, ma l'argomento (mi riferisco al discorso arte, non tecnica di programmazione), al di là delle pure considerazioni filosofiche, non ha rilevanza alcuna da un punto di vista tecnico. Quindi, come mi ero ripromesso, evito.

E' come discutere sul sesso degli angeli

Non usarla tutta la cenere, conservane un pò anche per me

[Luca Bab]

l'arte è quella cosa che si fa per il solo piacere di farla

se fai qualcosa per essere venduta non è più arte ...

Me la sono salvata e la conserverò

molto bella

grazie Walter/Giuseppe

ciao

Luca

[batta]

Per Water

Scusate, ma non resisto.

Allora un cantante non è un artista, un attore non è un artista, Picasso non era un artista. Solo chi canta, recita o dipinge per hobby può essere considerato un artista. Insomma, se io sviluppo un programma per il puro gusto di farlo, divento un artista.

Sai quante volte, per parecchi anni dopo il diploma, per il puro gusto di farlo, ogni tanto prendevo un libretto con una raccolta di problemi di elettrotecnica e mi mettevo lì a risolverli? Ero un artista?

Ogni tanto strimpello la mia vecchia chitarra. Lo faccio per il puro piacere di farlo ma, essendo le mie doti musicali estremamente scarse, non mi considero un artista nel suonare la chitarra.

Attenzione, non mi sono mai definito artista perché scrivo programmi. Tra l'altro preferisco di gran lunga la definizione di tecnico. Solo ritengo che per sviluppare software ci voglia anche creatività, non solo tecnica.

[walterword]

TAGLIATE IL POST

FINE

[Pietro_1]

Io faccio solo programmi a completa regola d'arte.

E quindi sono un artista.

[walter.r]

Scusate, ma non resisto.

Allora un cantante non è un artista, un attore non è un artista, Picasso non era un artista. Solo chi canta, recita o dipinge per hobby può essere considerato un artista. Insomma, se io sviluppo un programma per il puro gusto di farlo, divento un artista.

Sai quante volte, per parecchi anni dopo il diploma, per il puro gusto di farlo, ogni tanto prendevo un libretto con una raccolta di problemi di elettrotecnica e mi mettevo lì a risolverli? Ero un artista?

Ogni tanto strimpello la mia vecchia chitarra. Lo faccio per il puro piacere di farlo ma, essendo le mie doti musicali estremamente scarse, non mi considero un artista nel suonare la chitarra.

Attenzione, non mi sono mai definito artista perché scrivo programmi. Tra l'altro preferisco di gran lunga la definizione di tecnico. Solo ritengo che per sviluppare software ci voglia anche creatività, non solo tecnica.

E' la prima volta che "quoto" un intero post. Il problema è che Batta ha scritto esattamente quello che volevo scrivere anch'io, solo che è arrivato mezz'ora prima !!

Per Livio: attenzione, non vorrei che non ci trovassimo in accordo, al di là dei concetti artistici, semplicemente per diversa interpretazione del termine "regola".

Ti posso dire che approvo ciò che scrivi nel post #38, su questo siamo d'accordo.

Il mio concetto creatività è relativo agli specifici particolari di un software, all'approccio ad uno specifico particolare funzionale. Esempio: se si lavora in due su un progetto, e ci mettiamo d'accordo per appoggiare su una DB determinati dati, questa è una regola.

Il "come" ognuno va a scrivere la suddetta DB è indifferente al funzionamento.

Se entrambe le parti hanno scritto in modo comprensibile, etc....... non vedo nessun problema se sono impostate in modo diverso.

Non so se sono riuscito a spiegarmi, fammi sapere.

[Nicola Carlotto]

per programmare bene ci vuole una dose di intuizione non indifferente , tipica dei dislessici .

ciao

NICA

[batta]

NICA,

potresti spiegarti meglio? Non si capisce se la tua sia un'affermazione, una battuta, una provocazione o cos'altro.

walterword,

se l'argomento non ti interessa, non lo leggere. Perché devi chiederne la chiusura?

[mynameisrex]

Giusto Batta : NICA cosa volevi dire ???

[ifachsoftware]

l'arte è quella cosa che si fa per il solo piacere di farla

se fai qualcosa per essere venduta non è più arte ...

Penso che il 90% di chi fa automazione faccia tale mestiere per il piacere di farlo ... poi il fatto che le macchine vengano vendute e facciano guadagnare principalmente i titolari da un verso fa girare le ba..e dall'altro e' una soddisfazione ....

Ciao