Software evolution…

Su Tuttoscienze di oggi c'è un interessante articolo che vi invito a leggere sull'evoluzione del software paragonata a quella dell'hardware negli ultimi decenni.

Per l'hardware viene preso in considerazione come metro di giudizio il numero di cicli (forse era meglio l'ormai classico flops ma tendezialmente l'ordine di grandezza è lo stesso).

E per il software? Come principale dato dell'evoluzione del software viene preso in considerazione la produttività del programmatore, che è rimasta, come viene detto, tendenzialmente inchiodata a 10 istruzioni al giorno.

Sono un pò scettico su questo dati e sul loro significato; cosa vuol dire 10 istruzioni? il termine è un pò troppo generico: 10 istruzioni ad alto livello?

E soprattutto non sono completamente d'accordo con l'assunzione che il metro di giudizio per l'evoluzione del software sia la produttività media di un programmatore: sarei più propenso a vedere l'evoluzione del software come la capacità dello stesso a eseguire "operazioni" non possibili fino a un certo periodo. O piuttosto a permettere all'utente di eseguire delle azioni in campo virtuale che hanno un effetto sul mondo reale.

Ma più ci penso e più mi metto in dubbio, e porgo la domanda: secondo voi come dovrebbe essere valutata l'evoluzione del software?

Segue che come conseguenza del teorema di Godel e Turing la produzione del software è un processo non automatizzabile, come già chi ci lavora si era accorto…. e vari excursus sulla diseconomia del prodotto dovuta alla sua natura non industriale.

Bell'articolo che mi lascia comunque qualche dubbio.

Mazi

10 Responses

  1. Il tema mi affascina molto e mi ricorda da vicino la legge esponenziale di Kurzweil, di cui consiglio a tutti la lettura.

    Proprio leggendo Kurzweil mi sono sempre chiesto come mail il progresso del software sia così lento rispetto all’hardware.

    In realtà ci sono casi dove le due cose vanno abbastanza di pari passo, basta pensare ad esempio ai videogiochi, le consolle diventano sempre più potenti, ma anche il sofware si adatta per sfruttarne le potenzialità.
    Anche in questo caso però il software insegue sempre, lo sapevate che le prime PS2 avevano dentro una PS1 per essere retrocompatibili e che le prime PS3 avranno dentro una PS2 per lo stesso motivo, semplicemente perchè scrivere un software stabile di emulazione di una PS1 o di una PS2 richiede molto tempo.

    L’analisi di Meo, secondo me, non è del tutto campata in aria.

    Però i conti continuano a non tornare, alcuni sostengono infatti che l’hardware altro non è che software solidificato.

    Se questa frase non vi convince, pensate ai processori Transmeta che di fatto sono dei RISC, però tramite uno strato di emulazione in hardware si comportano per il sistema operativo come un CISC X86.
    O se preferite pensate ai set di istruzioni MMX e simili.

    La differenza quindi non sta, secondo me, solo nella numerosità di hardware e software.

    Quante architetture o implementazioni di processori conoscete ?

    Quante architetture o implementazioni di software conoscete ?

    Semplicemente stiamo parlando di numeri con svariati ordini di grandezza di differenza.

    Se nell’hardware c’è una concentrazione di sforzi verso degli standard per produrre milioni di pezzi tutti uguali, nel software spesso si investe anche per produrre un solo esemplare, cioè un’applicazione che girerà sempre sulla stessa CPU.

    Solo che all’apparenza tutto il software è software e invece non è così,
    esistono tantissimi tipi di software, ad esempio:

    – Bios
    – Driver
    – Sistemi Operativi
    – API
    – Server (database, application, etc …)
    – Client
    – Applicazioni di base
    – Applicazioni aziendali
    – Applicazioni dipartimentali
    – Applicazioni personali

    Più si scende (dall’alto in basso) in questa scala più si misura qualcosa di molto diverso dall’hardware.

    Io credo che per accelerare i tempi di produzione e quindi di evoluzione del software ogni livello dovrebbe basarsi solo su quello immediatamente sottostante.

    Spesso e volentieri invece si continua a programmare a basso livello su applicativi di alto livello.

    Come spesso amo ripetere, i framework si programmano, le applicazioni si configurano.

  2. Anche a me non convince misurare il progesso del software come istruzioni prodotte.

    Personalmente misurerei il progesso del sw come l’incremento della sua capacità di saper risolvere problemi reali, e di essere a supporto dell’uomo nelle sue attività. Allo stesso tempo di saper risolvere tali problemi in un lasso di tempo che permetta di essere effettivamente utile a chi ha il problema stesso, e di reagire in modo pronto al cambiamento delle esigenze. Quindi anche un discorso di costi: non può esserci progresso tecnologico senza un’effettiva fruibilità a causa di costi elevati.

    Entra qui il discorso che faceva Tom, e con il quale mi trovo d’accordo. Proprio perché il progesso si misura sulla capacità di essere a supporto dell’uomo nelle sue attività, ne deriva che un eccesso di tecnicismo distoglie dal reale obiettivo: risolvere problemi di dominio! E’ questo il motivo per il quale ho sempre pensato che il software sia molto più complesso dell’hardware.

    Intanto sogno nuove IDE e nuovi Workbench che permettano a noi programmatori di creare linguaggi, e di manipolare e trascinare concetti di dominio…

  3. Che l’hardware sia software solidificato è sicuramente vero; ho avuto una piccolissima esperienza universitaria di progettazione di circuiti e in fondo si tratta esclusivamente di scrivere del codice. Nel momento poi in cui si inserisce l’uso di strumenti come VHDL il parallelismo balza subito agli occhi.

    Sicuramente il software è molto, molto più complesso dell’hardware, che alla fin fine è solamente in grado di eseguire operazioni aritmetiche e loop (dai, facciamo i gentili, aggiungiamoci un po’ di intelligenza per la branch prediction o per la gestione della grafica!). In questo senso andrebbe costruito un monumento ai programmatori di compilatori, che permettono a noi scribacchini di esprimerci usando linguaggi molto espressivi.

    Io comunque non ci provo nemmeno a “misurare” il codice, perchè secondo me non è possibile. L’unico metro che mi viene in mente è la definizione di una “scala di problemi” che un sw è in grado di risolvere o una “scala di funzionalità” che può offrire. Più si sale, più il sw è evoluto (un po’ come la scala Mercalli per i terremoti). Un po’ come si fa con la RoboCup; un robot sarà evoluto quando riuscirà a battere un umano a calcio.

    Detto questo, non ci provo nemmeno ad abbozzarla!😉

  4. Gran post Tom. Colgo l’occasione per commentare alcune affermazioni.

    In realtà ci sono casi dove le due cose vanno abbastanza di pari passo, basta pensare ad esempio ai videogiochi, le consolle diventano sempre più potenti, ma anche il sofware si adatta per sfruttarne le potenzialità.

    In effetti è quello che è venuto in mente anche a me ieri sera non so in che modo: l’hardware corre, ma il software gli corre appresso, tanto che mi verrebbe da pensare che è spesso l’hardware il limite, ipotizzando un software funzione dell’hardware.

    Pensiamo come dici tu al mondo ludico che tra l’altro è uno di quelli dove l’hardware conta veramene molto: spesso oggigiorno capita che per poter far girare l’ultimo giocho 3D a una risoluzione elevata devi avere una scheda grafica dalle potenzialità di ultima generazione, e che magari un hardware di appena 1-2 anni ti limiti l’esecuzione di quel software.
    E’ sicuramente un buon esempio di come certo software necessiti di una dovuta evoluzione dell’hardware per poter essere eseguito.

    Mi viene quindi da pensare che neglio anni i due anche se con metri diversi evolvano all’incirca dello stesso ordine di grandezza.

    Però i conti continuano a non tornare, alcuni sostengono infatti che l’hardware altro non è che software solidificato

    Mi piace questa affermazione e pone l’accento su quello che noi consideriamo software: ad esempio i processori CISC per costruzione hanno un microinterprete che è software.

    Quindi anche l’hardware evoluto, senza un “motore” software non funziona…

    Ma forse ci stiamo discostando dal concetto iniziale.

    Pensavo: forse un software evoluto è un software che riempie sempre di più il gap tra uomo e macchina: e minore è il gap maggiore è la sua evoluzione.

    Se ne potrebbe parlare per ore…. discussione molto filosofica😀

    Mazi

  5. Quello che dici Mazi mi fa venire in mente l’osservazione di un mio amico fisico dell’atmosfera.

    Già 6 o 7 anni fa mi diceva che il lavoro di quelli come lui, ovvero fisici ma anche programmatori di modelli matematici di simulazione per le previsioni metereologiche, era radicalmente cambiato.

    Una volta il loro problema era creare degli algoritmi che fossero abbastanza veloci per l’hardware di cui disponevano, in modo da ottenere una previsione in tempo utile. Puoi avere l’algoritmo più preciso del mondo, ma se ci metti una settimana per elaborare la previsione per il tempo di domani ti serve a poco, solo a verificare la bontà del tuo algoritmo.

    Quando però verso la fine degli anni 90 la potenza di calcolo dell’hardware crescendo esponenzialmente ha superato il software si sono trovati a dover scrivere algoritmi che riuscissero a sfruttare tutta la potenza di calcolo e ad inseguire.
    In pratica gli è esplosa in mano la potenza di calcolo e non erano pronti a sfruttarla al 100%, perchè culturalmente si erano sempre dedicati a fare il contrario, partire da equazioni semplici e trovare il modo per farle viaggiare il più velocemente possibile.

    Sempre da anziano del gruppo ricordo gli esordi di Java nel 95, tutti dicevano che era lento, molto più lento del C e del C++ e quindi lo bollavano subito.
    In realtà era solo questione di tempo, l’hardware ci ha messo poco ad appiattire le differenze e l’incremento della potenza ha permesso anche di scrivere JVM con il compilatore JIT per un ulteriore incremento di performance.

    Per finire un ultimo esempio, quasi 10 anni fa un mio compagno di università, che oggi lavora in Motorola, fece una tesi sul VOIP, la sua conclusione drastica era che non funzionava perchè IPV4 non ha gestisce la qualità del servizio. Il relatore ovviamente gli chiese di smorzare i toni e la conclusione più argomentata divenne che il VOIP per funzionare su IPV4 ha bisogno di molta banda e di hardware in grado di comprimere molto il segnale in tempo reale, tra qualche anno vedremo. Quel giorno immancabilmente è arrivato.

    Morale di tutto questo fuori tema, l’ottimizzazione del software è una pratica molto costosa e spesso rischia di arrivare fuori tempo, perchè nel tempo che ci si mette a ottimizzare le capacità di elaborazione e trasmissione incrementano.

    Ecco anche perchè ritengo che si debba sempre sviluppare appoggiandosi al vertice della pila.

  6. Mi piacerebbe però rientrare nel tema della discussione chiededo a tutti cosa ne pensate della coseguenza del teorema di Turing sulla testabilità del software ?

    Cosa dicono i seguaci di TDD in merito ?

  7. Eheheh bravo Tom hai puntato il dito su un altro macro argomento:

    Neanche i «bachi» più banali, come familiarmente gli informatici chiamano gli errori di programmazione, quelli che determinano l’ingresso del programma in cicli chiusi di calcolo, possono essere scoperti automaticamente. A maggior ragione non si possono scoprire altri tipi di errore e, meno che mai, si può sperare di identificare automaticamente gli errori semantici, ossia verificare se un programma faccia proprio ciò che si sperava facesse.

    Un test unitario non è proprio un programma che testa se un altro programma fa quello che ci si aspetta?

    Turing ha fatto il suo tempo… oppure bisogna interpretare in altro modo le sue parole?

    Mazi

  8. Mazi…la seconda che hai detto.

    Dunque.
    Ci stiamo muovendo su terreni molto delicati, che richiedono precisione, e che hanno fatto prendere svarioni a persone molto più illustri di noi.

    Il teorema di Turing afferma che, dato un qualsiasi programma P, ed un input I, non esiste un programma che, presi in input P ed I, sia in grado di dare una risposta alla domanda P(I), per tutte le possibili coppie (P,I).

    Questo vuol dire che non esiste il programma definitivo che risolva tutti i problemi computazionali. Tale programma -se esistesse- potrebbe venire usato come oracolo (=il Test definitivo) per ogni programma.

    Come penso ora avrete capito, il teorema di Turing non scalfisce affatto un approccio alla TDD, anzi, se proprio vogliamo fare schierare Turing a tutti i costi (dopo averGli chiesto scusa ;)), lo rinforza. Infatti un approccio alla TDD, facendosi guidare dalla specificità dei singoli input ed output, non si pone come obiettivo quello di voler trovare il test perfetto, ma piuttosto fa in modo che una teoria più o meno generale emerga astraendo da singoli e piccoli programmini. Ciò non esclude ovviamente la possiblità di poter scrivere un test in forma più generica ad esempio sotto forma di precondizioni e postcondizioni di un metodo. Ritengo ad esempio un approccio alla Design By Contract assolutamente complementare e non in contraddizione con il TDD.

  9. Bizzare

    jrshnhw auhjlzqvode mxcpeocbme dmcbrzm arjxnjhsa

  10. Blowjob

    dzvgfivhdc epmmwqhtc gqcdfy kymzxqicfk sxwjipgqpk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: