di  -  mercoledì 17 dicembre 2008

Non appena vengono annunciate nuove versioni di un programma che utilizza, un buon programmatore comincia a farsi consumare la mente da un tarlo: quello della curiosità. Per prima cosa inizia la spasmodica caccia a ogni dettaglio che fornisca utili informazioni su quali siano le innovazioni apportate e le impressioni d’uso di chi ha potuto metterci sopra le mani.

Dopo l’assimilazione delle notizie si passa all’attesa fortemente onirica e di fantozziana memoria caratterizzata da visioni a occhi aperti in qualsiasi momento della giornata: le meraviglie di cui si è venuti a conoscenza si materializzano improvvisamente e ci si lascia trasportare dal dolce e ammaliante canto delle sirene che osannano questa o l’altra funzionalità di cui ovviamente non se ne può certo fare a meno (ma prima come abbiamo fatto a vivere senza?!?).

Il ritorno alla realtà è doloroso quanto un destro di Mike Tyson: purtroppo passare alla nuova versione non è possibile; almeno non subito. Le motivazioni sono diverse; il costo (per i programmi a pagamento) potrebbe sembrare un (forte) deterrente, ma i fattori più importanti sono rappresentati dalle dipendenze, dall’adeguamento del codice esistente, e dalla schedule da fissare per l’aggiornamento della piattaforma aziendale (che spesso comporta un disservizio temporaneo).

Non è possibile pensare di passare a una nuova versione di un’applicazione senza avere a che fare con questi vincoli.

Le dipendenze sono rappresentate dalle librerie impiegate e/o da altre applicazioni di cui facciamo uso. Esattamente come per i nostri programmi, il loro codice va adeguato, e soltanto dopo che è stato finalizzato e testato si provvederà al rilascio. Inoltre non è affatto scontato che le varie librerie verranno aggiornate e rilasciate.

Ad esempio il 1 ottobre scorso è stato rilasciato Python 2.6, che presenta delle caratteristiche molto utili (il multiprocessing in primis per sfruttare tutti i core presenti nel sistema; ovviamente ha anche tante altre cose utili). Ebbene, a due mesi e mezzo di distanza, tre librerie (di quelle che uso) non sono state aggiornate.

Passi per ClearSilver, che è un piccolo progetto (che ho usato una sola volta, fortunatamente), ma all’appello manca l’usatissimo mod_python di Apache; manca anche Ice che è il framework alla base di tutti i server che finora ho sviluppato. Senza almeno questi ultimi due non possono nemmeno lontamente pensare di aggiornare la mia macchina prima e i sistemi in produzione dopo.

Superati questi scogli c’è l’adeguamento del codice. A volte gli aggiornamenti rendono necessari dei ritocchi, anche se generalmente c’è retrocompabilità. Dico generalmente perché ciò non è affatto scontato. Se prendiamo Python 3.0, come ho già riportato, notiamo che il linguaggio è stato “ripulito” senza garantire una perfetta compatibilità all’indietro. Passare quindi a questa nuova versione richiederà un notevole sforzo per riadattare il codice esistente.

Fortunatamente Python 2.6 è stato pensato per agevolare il passaggio (è possibile abilitare in qualsiasi momento molti dei cambiamenti non retrocompatibili, e quindi testare il codice esistente ed eventualmente modificarlo), e inoltre è stato fornito un tool per automatizzare per buona parte l’aggiornamento. Inutile dire che una buona batteria di test è a dir poco fondamentale onde evitare spiacevoli sorprese.

Si potrebbe pensare che arrivati finalmente a questo punto (librerie e proprio codice aggiornati) la strada sia spianata. Niente affatto. L’aggiornamento delle macchine di produzione è sicuramente l’ostacolo più grande da superare. Ostacolo non in senso negativo, in quanto non c’è nessuno che vuol metterci i bastoni fra le ruote soltanto per il gusto di farlo, ma perché si tratta di un’operazione estremamente delicata e un errore che saltasse fuori potrebbe causare serii danni.

In questa fase è fondamentale convincere gli amministratori di sistema e i propri responsabili che l’aggiornamento comporterà benefici tali da compensare e superare i costi necessari all’adeguamento di tutte le macchine coinvolte, perché ciò può richiedere anche diversi giorni lavorativi. Fatto questo, bisognerà schedulare opportunatamente tutta la fase di adeguamento.

Nulla, quindi, è scontato. Se è vero che a casa magari si ha più libertà nello sperimentare nuove soluzioni, in ambito lavorativo bisogna giustamente fare i conti con tutta una serie di vincoli che non si possono assolutamente ignorare o prendere a cuor leggero.

Quindi in attesa che tutti i questi problemi vengano via via risolti, non ci resta che… continuare a sognare.

15 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Francesco Carucci
     scrive: 

    C’e’ anche l’opzione di abbandonare Python e passare ad un ambiente serio :P

  • # 2
    banryu79
     scrive: 

    Per esempio Java :P

  • # 3
    aesyr
     scrive: 

    in effetti… l’idiozia di rompere la compatibilità perchè il linguaggio “non è esteticamente perfetto” è veramente colossale: obbliga a far riscrivere/ritestare migliaia di righe di codice funzionanti, con un costo enorme a carico degli sviluppatori python.

    Un buon momento per capire che python non va usato per nessun progetto serio/di lungo termine, è gestito da degli incompetenti.

  • # 4
    Bellaz89
     scrive: 

    (Premettendo che non utilizzo Python)

    Beh. Facile sentenziare e accusare di poca serietà . Fatelo voi un linguaggio di programmazione che abbia solo 1/50 dell’ utenza di python e poi se ne riparla. Se hanno deciso di rompere un motivo ci sarà, non penso che Rossum si sia alzato la mattina dicendo ” ok , ora cambiamo le specifiche!”.

    Se a voi non conviene\è utile utilizzare python basta cambiare linguaggio a differenza di certe aziende ‘poco serie’

  • # 5
    Francesco Carucci
     scrive: 

    Bellaz, tipo?

  • # 7
    Bellaz89
     scrive: 

    Tipo queste:

    http://www.python.it/Quotes.html

    Elenco dettagliato:

    http://www.python.org/about/success/

  • # 8
    Francesco Mastellone
     scrive: 

    I componenti rimossi dal Python erano deprecati ormai da lungo tempo, i cambiamenti sintattici sono limitati e corretti efficacemente dal tool di conversione. Lo stesso vale per i cambiamenti strutturali delle librerie standard. I cambiamenti più radicali(es: ridefinizione dei tipi testo e bytes) sono limitati, e richiedono modeste modifiche in generi di codice poco comuni.
    Python 3 è marginalmente più lento di Python 2, ma più semplice e solido che mai.
    Sentiamo qual’è l’ ambiente serio.

  • # 9
    Jacopo Cocchi
     scrive: 

    Evidentemente alla Nasa, Google, agenzie governative e società quotate in borsa (con fatturati valutati in miliardi di dollari) sono parimenti poco seri visto che usano Python con una qual certa produttività.

    Java invece che per le novità che continua a proporre sulla falsariga di altre tecnologie (sì Python compreso) con il sistema di infarcire il linguaggio di librerie perché il re-design comporterebbe proprio una rottura della retrocompatibilità, invece è un ambiente “serio”.
    Eh come no…:)

    Le modifiche sono in cantiere da anni e chi parla di semplici cambiamenti estetici non solo non ha capito NULLA del passaggio e non ha evidentemente seguito le vicende ma non ha nemmeno presente come funzionino i lavori e dei meccanismi di feedback che sono tenuti in grande considerazione in tutti i cambiamenti apportati al linguaggio stesso (e non solo).

  • # 10
    Cesare
     scrive: 

    Come avevo scritto nel precedente articolo, i cambiamenti apportati a Python 3.0 hanno richiesto ben tre anni di lavorazione: nulla è stato, infatti, lasciato al caso.

    Questo non significa che da domani tutti quanti saranno costretti a modificare il loro codice. Infatti è stato rilasciato Python 2.6 ed è in schedule Python 2.7, che nascono in linea di continuità col passato, avendo la retrocompatibilità come obiettivo principale, ma che consentono anche di sperimentare parecchi dei nuovi cambiamenti apportati in modo selettivo e programmatico, cosicché si possa pensare con tutta calma a un passaggio meno indolore possibile alla nuova versione del linguaggio.

    Personalmente apprezzo questa visione, piuttosto che aggiungere pezze a un linguaggio per tenerlo al passo con le innovazioni introdotte dalla “concorrenza”.

    Fornisco qualche link alle opinioni di Bruce Eckel al riguardo:

    http://www.artima.com/weblogs/viewpost.jsp?thread=227728
    http://www.artima.com/weblogs/viewpost.jsp?thread=221903
    http://www.artima.com/intv/aboutme.html

    I primi due su Java e il terzo su Python.

    Ricordo, inoltre, che una società “poco seria” come Microsoft ha avuto il coraggio di fare lo stesso con .NET: dall’1.1 si è passati al 2.0, costringendo i programmatori a utilizzare nuove librerie e classi.

    Accorgersi dei propri errori e correggerli non è grave. E’ grave continuare a perseverare. ;)

    Quanto a Python, fino a quando mi permetterà di scrivere applicazioni anche in un decimo di tempo rispetto ai linguaggi più blasonati, e con un codice elegante, leggibile e manutenibile, incontrerà sempre il mio favore. :D

  • # 11
    thebol
     scrive: 

    Piccolo esempio dal mondo java. Da quando lavoro (3 anni e mezzo) ho sempre lavorato sulla 1.4.

    Questo proprio perché in ambiente di produzione si usano ancora server web che si basano 1.4.

    Oppure basta avere un cliente che sta ancora su 1.4 (come accade dove lavoro adesso), e il framework non può passare alla versione successiva.

    Sic.

    ps.Ho letto che non mettono le closure su java7 :bua:

  • # 12
    Francesco Carucci
     scrive: 

    > Sentiamo qual’è l’ ambiente serio.

    Un qualsiasi ambiente che non si difende religiosamente per partito preso.

  • # 13
    Cesare
     scrive: 

    Allora siamo a posto: non è questo il caso. :D

    Le motivazioni possono essere condivisibili o meno, ma… sono state fornite. ;)

  • # 14
    floriano
     scrive: 

    mah, io propendo per la classica mediocre progettazione.

  • # 15
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non capisco a cosa ti riferisca. Potresti essere più chiaro, cortesemente? Grazie.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.