Link alla notizia: http://www.hwupgrade.it/news/telefonia/i-produttori-android-vogliono-la-frammentazione-e-ostacolano-android-silver_54537.html

Android Silver avrebbe avuto l'obiettivo di eliminare la frammentazione di Android e facilitare lo sviluppo di applicazioni, se i produttori terzi non l'avessero boicottato

Click sul link per visualizzare la notizia.

Frammentazione o varietà? No perchè la proposta Silver consisteva nel creare catene e legacci per gli OEM, i quali avrebbero avuto sempre meno possibilità di differenziazione.

L'unico neo dell'ecosistema Android è la mancanza di un supporto serio da parte degli OEM, ovvero la mancanza di aggiornamenti ( o in alternativa fornire i sorgenti per i kernel custom che usano, così che la comunità possa creare rom custom e fornire supporto anche ai vecchi terminali ).

Credo che Android nel bene è nel male è così. Purtroppo è frammentato e ci sono case che ormai hanno preso il sopravvento sul sistema. Non so se Google avrà mai la forza di dire la sua in questo senso e staccarsi definitivamente. Gli interessi sono troppi, e le perdite sarebbero altrettanto.

Frammentazione o varietà? No perchè la proposta Silver consisteva nel creare catene e legacci per gli OEM, i quali avrebbero avuto sempre meno possibilità di differenziazione.

L'unico neo dell'ecosistema Android è la mancanza di un supporto serio da parte degli OEM, ovvero la mancanza di aggiornamenti ( o in alternativa fornire i sorgenti per i kernel custom che usano, così che la comunità possa creare rom custom e fornire supporto anche ai vecchi terminali ).

No il neo di Android è che è scritto da cani. :D

No il neo di Android è che è scritto da cani. :D

Argomentazioni a sostegno della tua interessantissima tesi ne hai? :rolleyes:

Argomentazioni a sostegno della tua interessantissima tesi ne hai? :rolleyes:

Ci hai mai sviluppato sopra?

Una classe: http://developer.android.com/reference/android/media/MediaPlayer.html

Evidentemente chi l'ha scritta non sa neanche cosa voglia dire "incapsulamento".

Chiunque abbia un minimo di basi di ingegneria del software ma anche di programmazione object oriented sa che lo stato andrebbe incapsulato nella classe e non esposto all'utente.

E questo è solo un esempio base. Se andiamo a vedere i cicli dell'Activity o l'interazione tra i thread c'è da uscire pazzi.

No il neo di Android è che è scritto da cani. :DPiù che ad Android, darei la colpa alle varie case che ci "appiccicano sopra" la loro UI/il loro software alla "viva il parroco".

Più che ad Android, darei la colpa alle varie case che ci "appiccicano sopra" la loro UI/il loro software alla "viva il parroco".

Quello sicuramente, ho un Moto G (prima serie) che da questo punto di vista va una spada e probabilmente è il miglior terminale in quella fascia di prezzo.

Tuttavia parlo proprio della libreria Android.

Bisogna sempre considerare che Google ha acquisito Android, non l'ha sviluppato in casa, e secondo me questa cosa si riflette su ciò che dicevo.

Frammentazione o varietà? No perchè la proposta Silver consisteva nel creare catene e legacci per gli OEM, i quali avrebbero avuto sempre meno possibilità di differenziazione.

L'unico neo dell'ecosistema Android è la mancanza di un supporto serio da parte degli OEM, ovvero la mancanza di aggiornamenti ( o in alternativa fornire i sorgenti per i kernel custom che usano, così che la comunità possa creare rom custom e fornire supporto anche ai vecchi terminali ).

Si, ma se non metti qualche paletto come puoi pretendere che gli OEM vadano contro i loro (supposti) interessi e rilascino aggiornamenti?

O li obblighi a rilasciare il kernel, lib e framework vari o metti paletti sull'HW e sulle personalizzazioni in modo da rendere i terminali compatibili con android AOSP (o al prezzo di piccole modifiche).

Gli OEM hanno la malsana (quanto campata per aria) idea che non aggiornare di proposito un terminale spinga l'utenza a cambiare dispositivo.
In realtà non funziona così visto che chi è interessato agli aggiornamenti vede un simile comportamento come mancanza di serietà e supporto e si rivolgerà ad altri brand (quindi si provocano un danno), chi se ne frega degli aggiornamenti non riterrà certo il mancato update come incentivo al cambio di terminale.

La solita pessima pensata di Google. Dal niente al tutto. Esagerati.
Quello che è da forzare è un core layer che permetta aggiornamenti ufficiali e centralizzati tramite gli update ufficiali di Google, i layer superiori legati all'interfaccia etc che caratterizzano le varie "distro" Android da parte dei costruttori invece non dovrebbero subire restrizioni.
Tutti contenti.

ragazzi voi pensate sul serio che la massa di acquirenti samsung, htc, sony o altro sia sensibile al discorso aggiornamenti? parlo della massa, non del singolo individuo che come noi si informa nei forum etc.

credo che su 100 colleghi che ho con un telefono samsung serie galaxy, 99 non hanno mai nemmeno tappato una volta su aggiornamento di sistema nelle impostazioni.

per loro l'importante è che vada su feisbuc e che whatsapp funzioni, se poi sotto c'è il compilatore ART piuttosto che Dalvik, se ci sono API di livello XYZ, se c'è il Kernel XYZ non gliene può fregare di meno. E se vedono qualcosa di minimamente diverso dalla touchwiz vanno in panico.

E Samsung & c. i margini li fanno con loro, non con noi utenti "evoluti".

P.s. dico samsung a titolo puramente esemplificativo

La solita pessima pensata di Google. Dal niente al tutto. Esagerati.
Quello che è da forzare è un core layer che permetta aggiornamenti ufficiali e centralizzati tramite gli update ufficiali di Google, i layer superiori legati all'interfaccia etc che caratterizzano le varie "distro" Android da parte dei costruttori invece non dovrebbero subire restrizioni.
Tutti contenti.

Si è già mossa in questa direzione da almeno un anno: Play Services, che include tutti gli aggiornamenti più importanti (chiaramente minor update) per TUTTI i telefoni che montano Android, qualsiasi sia la personalizzazione degli OEM.
Se si può utilizzare la ricerca vocale google su tutti i dispositivi è grazie a questo sistema (ad esempio), ma anche la gestione remota dei dispositivi (con wipe in caso di furto)... unito al fatto che stanno portando fuori dal sistema tutte le gapps rendendole disponibili sul play store...

edit

Si è già mossa in questa direzione da almeno un anno: Play Services, che include tutti gli aggiornamenti più importanti (chiaramente minor update) per TUTTI i telefoni che montano Android, qualsiasi sia la personalizzazione degli OEM.
Se si può utilizzare la ricerca vocale google su tutti i dispositivi è grazie a questo sistema (ad esempio), ma anche la gestione remota dei dispositivi (con wipe in caso di furto)... unito al fatto che stanno portando fuori dal sistema tutte le gapps rendendole disponibili sul play store...

Ok ma delle app non interessa (opinabili). Io parlavo di aggiornamenti di sistema, ad esempio in fatto di falle. Android andrebbe reingegnerizzato in modo da mantenere separato il core layer legato al kernel, quindi seguito da Google e sempre aggiornato su qualunque dispostivo, lasciando libertà ai produttori nella realizzazione di soluzione personalizzate per quanto riguarda l'interfaccia e altre feature.

non sono un programmatore, ma credo che le UI dei produttori siano legate a doppio filo con il kernel, ammesso e non concesso che il tema principale è l'aggiornamento del kernel.
Perchè se andiamo a vedere cosa introduce Lollipop, in termini di funzionalità utente (quindi escludo il compilatore di default, il kernel, le api etc) ci sono alcune cose che in realtà la touchwiz (faccio riferimento a samsung perchè ho avuto galaxy s ed s3) già aveva, ad esempio l'opzione non disturbare, il widget per la torcia etc...
Questo per dire: all'utente medio, se la touchwiz già gli da quello che "vuole" (notare virgolette), perchè dovrebbe andare in sbattimento per avere la release successiva? Contando che in caso di bug etc gli OEM li rilasciano eccome gli aggiornamenti, e anche velocemente (in primis samsung)

e il playservices "esternalizzato" serve proprio a google per garantire agli utenti android, indipendentemente dalla personalizzazione del produttore, la massima esperienza d'uso sulla piattaforma.
Cito alcune cose introdotte dagli ultimi aggiornamenti del playservices, e pertanto disponibili su TUTTI i telefoni Android:
Supporto Android Wear
Gestione dispositivi Android
API Google Drive, Google Play Games, Street View
Material Design
Supporto Google Fit

etc etc

Oggi non l'ha detto nessuno quindi lo dico io: il solito titolo fuorviante alla Nino Grasso! :doh:

I produttori di telefoni vorrebbero mantenere la frammentazione? E da dove si evince? Da quale dichiarazione di Samsung, Sony, Lg o chicchesia? (Anzi Sony aggiornerà tutta la gamma Z, news di oggi) :confused:

I produttori vogliono poter personalizzare le interfacce e vogliono mettere loro programmi preinstallati nei telefoni (utili o meno non lo sto a giudicare) ed è questo che porta a frammentazione nel momento in cui dei vecchi telefoni se ne infischiano o comunque ci mettono più tempo ad aggiornare. Ma da qui a dire che vogliono e cioè che perseguono come fine la frammentazione di Android ce ne passa....

Ninooooooooooooooooooooooooooooo:banned:

Si, ma se non metti qualche paletto come puoi pretendere che gli OEM vadano contro i loro (supposti) interessi e rilascino aggiornamenti?

Nel libero mercato è compito del consumatore penalizzare chi si comporta "male".


O li obblighi a rilasciare il kernel, lib e framework vari o metti paletti sull'HW e sulle personalizzazioni in modo da rendere i terminali compatibili con android AOSP (o al prezzo di piccole modifiche).

I terminali sono compatibili, il punto è che forzare gli OEM creerebbe solo un'ecosistema Apple-like. A quel punto meglio l'originale, no!?!


Gli OEM hanno la malsana (quanto campata per aria) idea che non aggiornare di proposito un terminale spinga l'utenza a cambiare dispositivo.

In buona parte è vero, soprattutto visto che i gadget mobile sono visti più come moda che come reale necessità.


In realtà non funziona così visto che chi è interessato agli aggiornamenti vede un simile comportamento come mancanza di serietà e supporto e si rivolgerà ad altri brand (quindi si provocano un danno)

In questo caso il sistema funziona, perchè gli OEM si vedranno costretti a cambiare comportamento.

In questi giorni ho letto varie news ( riguardanti LG e qualche altro ) in cui si diceva che questi OEM hanno intenzione di effettuare l'upgrade ad Android 5.0 sui terminali preesistenti. Forse il messaggio è arrivato e stanno cambiando rotta.

Quello che è da forzare è un core layer che permetta aggiornamenti ufficiali e centralizzati tramite gli update ufficiali di Google, i layer superiori legati all'interfaccia etc che caratterizzano le varie "distro" Android da parte dei costruttori invece non dovrebbero subire restrizioni.
Tutti contenti.

Sarebbe possibile se.....non fossimo nel mondo ARM :D

In realtà si potrebbe fare in maniera banale, ovvero i produttori di SoC dovrebbero rilasciare i sorgenti e il gioco sarebbe fatto.

Viceversa non c'è modo di creare un core unico che permetta a Google di rilasciare direttamente gli aggiornamenti.

Così non va.
Deve esserci un core comune a tutti e aggiornabile direttamente da google, poi i produttori devono avere gli strumenti necessari per fare delle personalizzazioni ma che siano moduli ben distinti.
Le nuove API introdotte con Lollipop potrebbero fare al caso.

No il neo di Android è che è scritto da cani. :D

Allora
MI SCUSO IN ANTICIPO CON I MOD
ma che cazzo di modo è di intervenire in un tread dove si discute della richiesta di Google ai maggiori produttori di Samrtphone Android di trovare una strada comune per minimizzare la frammentazione dell'universo verde?
Ma davvero un paio di classi non scritte secondo i dettami di qualche libro portano a giudicare CANE un OS come Android?
Allora quando ai tempi scrivavamo direttamente codice assembly sull'Amiga accedendo come dei barbari alle risorse a disposizione che eravamo? Dei porci?
Ma per favore.
Android, Windows, *nix, Ios, etc, ognuno ha paradigmi e concept lato developer che possono piacere o meno.
Ma sono gusti e basta.

Edito il resto, per bontà di patria.

Frammentazione o varietà? No perchè la proposta Silver consisteva nel creare catene e legacci per gli OEM, i quali avrebbero avuto sempre meno possibilità di differenziazione.
Frammentazione (http://www.appuntidigitali.it/16204/la-frammentazione-di-android/), senz'altro.
L'unico neo dell'ecosistema Android è la mancanza di un supporto serio da parte degli OEM, ovvero la mancanza di aggiornamenti ( o in alternativa fornire i sorgenti per i kernel custom che usano, così che la comunità possa creare rom custom e fornire supporto anche ai vecchi terminali ).
I sorgenti possono coprire segreti industriali (vedi nVidia, ad esempio), per cui è estremamente difficile che verranno rilasciati.
Allora
MI SCUSO IN ANTICIPO CON I MOD
ma che cazzo di modo è di intervenire in un tread dove si discute della richiesta di Google ai maggiori produttori di Samrtphone Android di trovare una strada comune per minimizzare la frammentazione dell'universo verde?
Ma davvero un paio di classi non scritte secondo i dettami di qualche libro portano a giudicare CANE un OS come Android?
Purtroppo non sono soltanto un paio di classi (http://www.appuntidigitali.it/16175/android-api-stabili-ottimizzate-e-ben-fatte/).
Allora quando ai tempi scrivavamo direttamente codice assembly sull'Amiga accedendo come dei barbari alle risorse a disposizione che eravamo? Dei porci?
Ma per favore.
Ma per favore, non riportare informazioni sbagliate. Sull'Amiga si poteva scrivere tranquillamente codice assembly, senza essere considerati dei porci, purché si rispettassero le linee guida di mamma Commodore. La maggior parte del codice che ho scritto all'epoca era in assembly per l'appunto, ed era perfettamente compliant con le guideline per gli sviluppatori.

Ciò valeva anche nel caso di accesso diretto all'hardware (bypassando il s.o.). In questo caso le guideline erano dettate nel famigerato "Amiga (ROM Kernel) Hardware Manual".
Android, Windows, *nix, Ios, etc, ognuno ha paradigmi e concept lato developer che possono piacere o meno.
Ma sono gusti e basta.
Non è questione di gusti, ma di ingegneria del software. Non stiamo parlando di vendere mele al mercato, e un briciolo d'infarinatura in merito non guasterebbe prima di liquidare la faccenda come questione di "gusti".

Allora
MI SCUSO IN ANTICIPO CON I MOD
ma che cazzo di modo è di intervenire in un tread dove si discute della richiesta di Google ai maggiori produttori di Samrtphone Android di trovare una strada comune per minimizzare la frammentazione dell'universo verde?
Ma davvero un paio di classi non scritte secondo i dettami di qualche libro portano a giudicare CANE un OS come Android?
Allora quando ai tempi scrivavamo direttamente codice assembly sull'Amiga accedendo come dei barbari alle risorse a disposizione che eravamo? Dei porci?
Ma per favore.
Android, Windows, *nix, Ios, etc, ognuno ha paradigmi e concept lato developer che possono piacere o meno.
Ma sono gusti e basta.

Edito il resto, per bontà di patria.

L'Ingegneria Informatica così come l'Ingengeria del Software, che molti snobbano in vero, è una materia decisamente "recente" e per tanto ancora immatura.

Si sta cercando con molti sforzi di fare in modo che quel termine "Ingegneria" non sia solo di contorno, ma che effettivamente sia il plus che renda il software più gestibile e usabile.

Non si parla dei "dettami di qualche libro" ma del futuro dell'informatica, che non può essere in tutto e per tutto in mano agli smanettoni, specie se fare e mantenere un software (anche open) ha dei costi.

Quando si scriveva codice assembly sull'amiga probabilmente si era obbligati a farlo, o comunque era lo strumento migliore per l'epoca.

Ciò non toglie che anche in assembly ci siano delle "regole" (scritte o meno) che andrebbero seguite.

Non si tratta del linguaggio, ma di come viene usato.

I tempi cambiano e le metodologie di sviluppo anche (siamo passati per i modelli a cascata fino ad arrivare ai metodi agile di oggi, vedi scrumm).

Detto ciò ribadisco quello che ho detto, e comunque quella classe era solo un esempio.

Quello che a molti sfugge è che purtroppo NON basta prendere il kernel Linux per avere automagicamente un SO decente.

Altro esempio a mio modo di vedere imbarazzante:

https://code.google.com/p/android/issues/detail?id=2854

Più di 5 anni e ancora nemmeno assegnato a qualche sviluppatore. Complimenti per la tanto strombazzata velocità del fix in quest'ambito...

Ovviamente concordo con tutto il resto. Dovrebbero essere ovvietà per chi lavora nel campo, ma la realtà si dimostra, come al solito, ben diversa.

Ci hai mai sviluppato sopra?

Una classe: http://developer.android.com/reference/android/media/MediaPlayer.html

Evidentemente chi l'ha scritta non sa neanche cosa voglia dire "incapsulamento".

Chiunque abbia un minimo di basi di ingegneria del software ma anche di programmazione object oriented sa che lo stato andrebbe incapsulato nella classe e non esposto all'utente.Esattamente, dove sarebbe esposto lo stato?

Onestamente, non so se sia meglio o peggio. Il fatto è che porta a pro e contro validi da entrambe le parti.

Esattamente, dove sarebbe esposto lo stato?

Ovunque, tant'è che ti mettono in bella vista il diagramma (indecente) degli stati perché secondo loro puoi chiamare determinati metodi solo se il player è in un determinato stato (che devi per forza conoscere).

La cosa peggiore è poi come vengono gestiti gli errori.

Oltre al lancio di un eccezione hanno introdotto uno stato Error, quindi se per caso sbagli l'unico modo per recuperare è fare il reset e re-impostare il brano (magari perdendo buffering e tutto il resto).

Questa è pura follia.

Un sistema decente non dovrebbe fallire su cose stupide.

Se il player è fermo o non è stato specificato un brano per quale motivo chiamare il metodo stop() dovrebbe causare un errore?

Altra cosa senza senso: se guardi il grafo degli stati, una volta che sei andato in Stopped, non puoi più fare start() per fare il playback del brano :asd:

Altra cosa senza senso: se guardi il grafo degli stati, una volta che sei andato in Stopped, non puoi più fare start() per fare il playback del brano :asd:

Devi chiamare prepare(). E dove starebbe questo fantomatico sacrilegio?

Devi chiamare prepare(). E dove starebbe questo fantomatico sacrilegio?

Non è questione di sacrilegio, ma di best practices in un ambito che è quello dell'ingegneria del software (e la cosa si estende in tutti gli ambiti ingegneristici).

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Se poi ci si accontenta di poco e ci si sorbisce tutto perché "eh vabbè che ci fa", è un altro discorso, ma da Google mi aspetto molto di meglio in termini di API verso gli sviluppatori.

Se vogliamo parlare di software ben scritto parliamone, se vogliamo parlare di programmare a pizza e fichi (nulla da ridire sul cibo :D)...

(solo a sottolineare il paradosso di chi ogni tanto si "lamenta" che il software e l'ingegneria informatica non sono maturi abbastanza e poi tollera cose di questo tipo)

Ovunque, tant'è che ti mettono in bella vista il diagramma (indecente) degli stati perché secondo loro puoi chiamare determinati metodi solo se il player è in un determinato stato (che devi per forza conoscere).Tu parlavi di encapsulation ed esposizione dello stato (quindi quello dell'oggetto istanziato), per questo chiedevo dov'era esattamente. Non vi sono variabili di stato pubbliche, quindi non mi sembra che il concetto di encapsulation sia mal implementato. La tua mi sembra più una critica sul design della classe. Non ho particolare esperienza di Android e non ho mai usato quella classe, ma direi che la scelta progettuale deve essere pesata sulla base degli scopi della stessa. L'implementazione come macchina a stati finiti su cui il programmatore ha elevato controllo e quindi responsabilità può essere semplicemente dovuta al fatto che la classe si interfaccia in modo più o meno diretto con l'hardware e quindi ne riflette i meccanismi ad un livello solo lievemente più astratto. Oltretutto, una bassa astrazione non è sempre un male, in quanto lascia maggiori libertà allo sviluppatore senza vincolarlo ad una particolare scelta implementativa.
La cosa peggiore è poi come vengono gestiti gli errori.

Oltre al lancio di un eccezione hanno introdotto uno stato Error, quindi se per caso sbagli l'unico modo per recuperare è fare il reset e re-impostare il brano (magari perdendo buffering e tutto il resto).

Questa è pura follia.

Un sistema decente non dovrebbe fallire su cose stupide.

Altra cosa senza senso: se guardi il grafo degli stati, una volta che sei andato in Stopped, non puoi più fare start() per fare il playback del brano :asd:
Non mi esprimo perchè non l'ho mai usata. Se proprio si vuole una classe con play() e stop() e che si prenda carico in automatico di tutti gli errori, si può sempre implementare un wrapper. Di contro, in questo caso, il programmatore non ha alcun controllo sugli errori e quindi non ha modo di agire opportunamente. Quello che per te può sembrare inutile e mal progettato, potrebbe sembrare necessario e tornare utile a qualcun altro.

Detto questo, Android non è perfetto, come non lo è alcun software di quella complessità. Tra le pochi classi che abbia mai usato, AsyncTask è sicuramente una delle peggio progettate.

Se vogliamo parlare di software ben scritto parliamone, se vogliamo parlare di programmare a pizza e fichi (nulla da ridire sul cibo :D)...


Di software ben scritto ( fino ad oggi ) ho letto solo sui libri. E' una teoria interessante quella del software ben scritto, ma solo una teoria.

Google potrebbe certamente fare di meglio, come del resto tutti gli altri potrebbero fare di meglio ( Apple ha sfornato iOS 8 per poi rilasciare una megapatch dopo una settimana ).

Credo ( e non penso di sbagliarmi ) che l'ingegneria del software sia morta. Il tempo degli hacker che spaccavano il bit e scrivevano software robusto ed elegante è finita.

Brutta cosa certamente, ma è l'amara realtà contemporanea.

Credo ( e non penso di sbagliarmi ) che l'ingegneria del software sia morta.
E' morta per quelli che sono passati troppo in fretta dalla zappa alla tastiera.
Il tempo degli hacker che spaccavano il bit e scrivevano software robusto ed elegante è finita.
Forse quel tempo non c'è mai stato, proprio perché erano troppo concentrati a spaccare il bit anziché progettare meglio il codice.

Tu confondi la ricerca dell'ottimizzazione a tutti i costi con la qualità / bontà / manutenibilità del codice: sono due cose completamente diverse, e non di rado capita che se propendi per la prima la seconda si riduca.

Tu confondi la ricerca dell'ottimizzazione a tutti i costi con la qualità / bontà / manutenibilità del codice: sono due cose completamente diverse, e non di rado capita che se propendi per la prima la seconda si riduca.

Sta di fatto che ovunque ti giri vedi codice fatto male ( tranne rarissimi casi ).

Basta leggere un qualsiasi sito di settore e si noterà che tra vulnerabilità, crash, telefoni brickati dagli updati, non se ne esce.

Che è ancora un altro discorso, e inoltre non direttamente correlato alla qualità del codice (bisognerebbe vedere i singoli casi).

Che è ancora un altro discorso, e inoltre non direttamente correlato alla qualità del codice (bisognerebbe vedere i singoli casi).

Beh l'ingegneria del software dice che un software scritto bene, manutenibile e tutte le cose che sappiamo, permette di ridurre sensibilmente il numero di bug e vulnerabilità di vario tipo.

Quindi ritengo che la correlazione ci sia eccome.

Ma rimane il fatto ( incontrovertibile ) che tutti i progetti software ( soprattutto quelli di grandi dimensioni ) se non partono male, poi lo diventano con l'età.

Certo l'incompetenza che regna nel settore non aiuta, ma non è solo colpa dei contadini divenuti informatici :stordita:

Bug e vulnerabilità non sono necessariamente legati. Un software deve rispettare i requisiti e non presentare bug nel funzionamento (cosa alquanto difficile, causa enorme complessità del codice attuale), ma non necessariamente dev'essere progettato per non essere vulnerabile. Al solito, bisogna vedere gli ambiti di utilizzo.

E non è nemmeno questione di età del software: ciò che conta, in questo caso, è la manutenzione che avevo già citato prima. Estendere le funzionalità di un software NON implica che la sua qualità debba peggiorare.
Visto che hai parlato di "fatto incontrovertibile", hai piena facoltà di dimostrare questa tesi che hai esposto.

Infine, sì: l'incompetenza non aiuta, ma di certo i contadini programmatori non fanno di meglio (tranne le solite eccezioni che confermano la regola).