… Si, magari posso essere anche un pò d’accordo (anche se ho il forte sospetto che in termini pratici quel guadagno sarà comunque trascurabile), ma avete creato un mostro (da mantenere) solo per questo motivo? Poi probabilmente si è stizzito e mi ha lasciato senza una risposta.
Se qualcuno si sta chiedendo per caso come è la documentazione si metta l’anima in pace: le poche funzioni che sono documentate non coprono certamente la vastita del progetto (spesso e volentieri vengono listati i parametri ma senza speficarne l’uso) e i commenti al codice sono come pietre preziose… rare (ma soprattuto non preziose visto che in parecchi casi sembrano dei messaggi ad altri sviluppatori).

Insomma come progetto open mi aspettavo certamente una cura maggiore (lo stesso OFAPI, è doveroso ammetterlo, soffrirà parecchio di questa fragilità… in pratica modifiche interessanti al codice del core dovranno essere riportare in ofapi che in diversi casi non fa altro che duplicarle).  Spero invece che vbulletin sia curato maggiormente da questo punto di vista.

Tutto il mio rispetto per un progetto così famoso ed usato… ma per pietà fate un passo in avanti, gli anni del PASCAL sono finiti da un pezzo (con tutto il rispetto per il PASCAL).

ShareThis

Questa volta non parleremo di Mac, ma di come spesso la storia si ripeta sempre uguale a se stessa (nel bene, ma anche nel male). Oggi parliamo di Google Android e di iPhone.

Il mercato dei cellulari, sebbene negli ultimi mesi abbia avuto un notevole rallentamento (dovuto più alla mancanza di nuovi servizi in grado di far desiderare l’ennesimo nuovo acquisto, piuttosto che ad una normale e prevedibile contrazione fisiologica) rimane comunque uno dei mercati tecnologici attualmente più redditizi.

Le statistiche per il 2005 (uno degli anni di maggior crescita per questo mercato) parlano di almeno 700 milioni di unità vendute; lo stesso anno i PC (intesi in senso largo, quindi parliamo di laptop ma anche di desktop) non hanno neanche sfiorato le 200 milioni di unità vendute.

Già da questo possiamo incominciare a pensare quanta e quale importanza rivestirà questo device negli anni a venire.

A rafforzare ulteriormente questa tesi ci sono gli eventi di questi ultimi tempi come lo sbarco di iPhone e quello di Google, ma anche più recentemente l’acquisto da parte del colosso finlandese Nokia di Symbian OS (che attualmente rappresenta, con le sue diverse incarnazioni, oltre il 60% del parco dell’installato).

Tuttavia ci troviamo ancora oggi a navigare in quello che sembra un medioevo informatico per il settore della navigazione mobile; a ben pensarci possiamo ritrovare un parallelo nello scontro tra titani per la conquista del mercato dei pc.

A questo punto devo ammettere una cosa. Nello scontro tra Android (di Google) e iPhone (di Apple) tifo per il primo. Pur essendo prima uno sviluppatore Mac e poi iPhone, non ho mai nascosto un certo prurito all’idea di un software controllato totalmente da Apple (che questa volta non si limita ad un assetto chiuso come quello nel desktop, ma ad un unico punto di commercializzazione che come tutte le cose di questo genere viene fatto passare sotto la scusa di voler dare sicurezza all’utente finale - non so voi ma a leggere queste press release incomincio a sentir puzza di trusted rincarnato).

Tuttavia è doveroso ammettere come ad oggi sia stata Apple a fornire tutte le soluzioni migliori per il mobile: è innegabile infatti che la volontà di controllare sia hardware e software abbia portato gli indubbi vantaggi che scopriamo ogni giorno con il nostro Mac; inoltre parlando nelle vesti di programmatore (per quanto si tratti ancora di questioni fumose e soggette ad possibili radicali cambiamenti) non c’è paragone tra il software di sviluppo a corredo di iPhone e quello attualmente disponibile per Android.

Il grosso vantaggio di Apple è quello di controllare iPhone dal basso verso l’alto, ogni singolo chipset, il case, l’OS, l’interfaccia utente e tutto il resto. Apple conosce esattamente come apparirà l’interfaccia all’acquirente finale. La dipendenza di Google dai diversi produttori hardware e dai carrier di telefonia (che in tutta questa storia rappresentano il vero male) le toglie inesorabilmente il controllo del prodotto mettendolo nelle mani di chi, fino ad oggi, non ha fatto altro che peggiorare la situazione.

Di contro il motto del team di sviluppo Android “programma ciò che vuoi, installalo dove vuoi” (”code what you want to code, install what you want to install”) è innegabilmente più attraente (sebbene poi mi siano giunte voci, tutte da confermare, che anche Google avrà un suo negozio per Android).

In un mondo ideale sarebbe facile dare Google come il vero vincitore, ma ad oggi è difficile riporre nel progetto più aspettative di quanto non se ne possano dare a Symbian (anch’esso sulla strada, quasi obbligata, dell’open source).

In un certo senso sembra d’essere ritornati ai primi anni dell’informatica consumer (e in verità due dei protagonisti sono ancora lì) con in più l’elemento sorpresa dei carrier. Quando penso al controllo che gli operatori vorrebbero continuare ad avere sulle proprie reti (sono notizie di questi giorni le tariffe, ridicole, proposte dalle telco italiane per iPhone) mi immagino una ENEL qualsiasi che cerca di imporre agli utenti come utilizzare i propri elettrodomestici soltanto perchè l’energia la produce lei (in questo senso l’opera di Google in america è più che lodevole).

Ma lasciamo stare per ora la disastrosa politica protezionista che assumono le telco all’alba dell’internet mobile, e torniamo a parlare di Google ed Apple.

Ad un anno dall’uscita di iPhone (e più o meno lo stesso periodo dall’uscita della prima -rudimentale- SDK per sviluppare sotto Android) la situazione sembra volgere benone solo per la prima.

Mentre su iPhone si accapigliano come donnicciole tutte le telco, l’opera di Google stenta ancora a prendere quota (si vocifera, dopo la presentazione di un primo modello al CES di questo anno, che il primo modello Android-based non vedrà la luce prima di fine anno… e si tratta, a mio parere, di una stima fin troppo ottimistica).

Un altro punto critico per Google, come abbiamo già accennato precedentemente, riguarda gli sviluppatori.

Il Journal di qualche tempo fa riporta alcuni stralci di interviste che recitano più o meno così:

“Dopo aver incassato il si di alcuni tra i più grandi sviluppatori mobile, Google è costretta a fare i conti con le critiche piovute su un SDK ancora non pronto e in costante evoluzione”

e ancora

“Qualche sviluppatore asserisce che sviluppare con i tool Apple sia molto più facile grazie anche alla quasi compatibilità con lo sviluppo Mac”

e infine

“Andy Rubin, direttore della piattaforma mobile di Google, afferma che l’impegno nello sviluppo del software accomunato alla necessità di dare ai carrier la possibilità di creare guadagni chiede del tempo - ‘E’ qui che ci sono i guai’”

Così mentre si allunga in maniera impressionante la fila di carrier disposti a fare “faville” per accaparrarsi l’esclusiva di vendere iPhone (a tal proposito volevo ricordarvi come gli stessi Apple Store che vendono iPhone non vengano riforniti da Apple stessa, ma dalle telco che hanno vinto la gara nei rispettivi paesi), la piattaforma di Google stenta a prendere il volo.

Un’altra notizia importante, come avevo accennato ad inizio articolo, è la recente acquisizione del 52% di Symbian, la casa che sviluppa l’omonimo OS che attualmente fa la voce grossa nel settore del mobile.

La notizia, accompagnata anche dal fatto che a breve Symbian diventerà un progetto open source (e questo non può che far bene al mercato) non farà certo di Nokia un’azienda dai gadgets più “sexy” (come Apple) ma permetterà comunque un più rapido sviluppo della piattaforma e una migliore integrazione con i device del suo più grande cliente.

Ad ogni modo, vale la pena ricordare come Apple e Google non possano essere considerati come rivali in senso stretto, più o meno nella stessa maniera in cui non si può confrontare il mercato Mac con quello Windows.

Apple, come al solito, ha deciso di puntare tutto sull’integrazione e l’ottimo connubio che soltanto soluzioni proprietarie ad hoc possono permettere, mentre Google sta facendo la parte di MS (con l’enorme differenza che non si tratta di riuscire a derivare profitti dalla vendita di Android stesso, quanto più riuscire a creare un nuovo mercato dove farla da padrone) sviluppando una soluzione software utilizzabile - sperabilmente - su una moltitudine di apparecchi.

Attutalmente va dato atto ad Apple di aver iniziato una sostanziale modifica dell’assetto nel settore mobile sia dal punto di vista della gerarchia (abbiamo per la prima volta visto compagnie telefoniche “piegarsi” - in parte almeno - dietro ad apparecchi anzichè dettar regole) sia dal lato tecnico (con una interfaccia che per la prima volta rende più comodo interagire con dispositivi mobili - vi sfido ad usare Windows Mobile sull’HTC che ho qui in tasca senza dove ricorrere ad una pennetta e degli occhiali).

Guardando il mercato globale spero comunque che Android possa dire la sua contrastando quello che è sempre stato terreno di Symbian, e minor parte di Windows Mobile. Le intenzioni ci sono sicuramente sebbene i numerosi ritardi e lo sviluppo ancora grezzo dell’ambiente stesso possano far perdere alla piattaforma quel grande hype che s’era conquistata appena dopo l’annuncio un anno fa (sebbene poi, dal punto di vista tecnico, Android non abbia molto da invidiare all’OS di iPhone).

Nelle prossime settimane inizierò a sviluppare un progetto che vedrà la luce come applicazione web, per iPhone e per Android. Conto quindi di tenervi informati su tutti quelli che sono i miei commenti a riguardo di entrambe le piattaforme.

ShareThis

Se non avete un client IRC potete sempre seguirci via web a partire da questo link (per il keynote) e qui per fare quattro chiacchiere.

Vi aspettiamo!!

ShareThis

Questo major update dovrebbe concentrarsi su stabilità e sicurezza, anche se appare improbabile che non arrivino novità nella GUI.

Non ho mai visto una major release (di qualunque software, forse ad eccezione di debian) che facesse dei fix un punto chiave; non che questa non sia una buona notizia ma di solito per questa roba ci sono le minor release e comunque difficilmente riesco ad immaginarmi uno Steve Jobs che si mette a chiacchierare quaranta minuti buoni sulla sicurezza.

Se proprio vogliamo dirla tutta stabilità e sicurezza (soprattutto la prima) dovrebbero essere fatti assodati per chi presenta del nuovo software (anche se con l’avvento di internet per le masse parecchie software house preferiscono farsi betatestare - sotto compenso - i propri software) e comunque mi rimane difficile far passare per marketing roba che “non si vede”. Il marketing dovrebbe attirare le persone. Chi non ci capisce di informatica non va a vedere se finalmente quel cavolo di fix nel modulo del kernel [...] è stato patchato (ok forse gli utenti linux si, qualche programmatore pure, ma noi parliamo della persona “normale”) perchè a lui non frega una cippa (o meglio ancora, frega nel senso che si tratta di cose scontate… o quando comprato un’auto incominciate a fare le analisi a tutte le parti? … tra l’altro vi sfido ad trovare il motore nelle nuove auto, ma questo è un altro discorso).

E poi c’è anche la storia di All Things Digital di cui abbiamo parlato nel post precedente. Quando Ballmer e $ocio (con la S rigorosamente grande e rigorosamente dollarosa) hanno presentato l(a)e novità di Windows 7 (per cui stando alle ultime dichiarazioni, o paurosamente ottimistiche o clamorosamente (di nuovo) fallate), ovvero il multitouch, hanno dato in pasto la pubblico la notizia di un futuro prossimo venturo dove il touch sarà parte del desktop (*): crediamo davvero che Apple (che per prima lo ha introdotto nell’ormai blasonato iPhone) non vorrà metterci le mano prima?

In ultima analisi credo che il 10.6 sarà anche l’occasione di rinnovare (se non altro parzialmente) una GUI che (personalmente ritengo ancora un perfetto esempio di pulizia) incomincia a soffrire un pò del tempo (marketing) che passa.

Insomma non credo che le novità del Lion che verrà saranno “ridotte” a un ammasso di bugfix, ma dubito che anche una presentazione anticipata al WWDC possa avere tutte le novità di cui ha bisogno il nuovo OS (negli ultimi mesi molti sforzi sono stati passati all’iPhone OS o mac mobile come preferite).

* la cosa di per se non mi convince ancora molto, a dirla tutta credo che le interfaccie touch dovrebbero essere pensate in maniera opportuna per questi dispositivi… altrimenti va a finire che ti ritrovi in mano un HTC touch con Windows (Mobile) che senza pennino è un martirio

ShareThis

Tutto questo, come avrete certamente capito, è Windows Vista, che ad oltre un anno dalla sua (sofferta) uscita ufficiale sembra dato per morto anche dalla sua stessa mamma.

In questi giorni Microsoft, nella importante (e occhialuta) figura di William Gates III (l’ormai non-pensionato), ha presenziato ad una nota trasmissione americana (D: All Things Digital) annunciando le (la?) novità di Windows 7 che verrà rilasciato (presumibilmente) nel 2009.

Il prossimo Windows supporterà il touch. Nel 2009 Windows permetterà all’utente di utilizzare tutte e dieci le dita per interagire sullo schermo… a patto che il sistema riesca a non collassare (a solito) su se stesso come è (in alcuni casi) la tradizione.

Ma questo articolo non vuole assolutamente porre l’accento su quello che potrebbe essere il Windows che verrà, quanto più analizzare cosa ha portato Microsoft ha ritrovarsi in casa un gallina stitica (gli analisti come Gartner prevedono, in maniera forse fin troppo drammatica, un collasso dell’intero sistema e della Microsoft).

Lo faremo in un (piuttosto lungo per un post di un blog) viaggio in cui le scelte e i destini delle due aziende più rilevanti del settore informatico di questi anni (Apple e Microsoft) sono stati messi a confronto e giudicati. Errori e strategie vincenti che spesso sono trascurate perchè poco visibili.

SIAMO SICURI CHE IL PROBLEMA E’ IL PRESENTE?

Come abbiamo detto, in questi ultimi giorni parecchi si sono cimentati nella critica delle scelte Microsoft nella progettazione e lancio del suo nuovo sistema operativo. L’errore che parecchi hanno fatto è stato però quello di guardare alle scelte presenti come fonte di tutti i mali: ma i problemi di Windows non vanno cercati ostinatamente nel suo futuro (perchè quella è solo una parte e probabilmente neanche così fondamentale), ma nella sua storia.

La necessità di coniugare 25 anni di decisioni cercando nel contempo di innovare (sono esagerato?) cercando una nuova rotta verso il futuro: è un pò come cercare di evitare un muro schiacciando il pedale dell’accelleratore (il che, come avrete intuito, non è proprio il miglior modo di salvarsi).

Queste decisioni sono state ammassate le une sulle altre, spesso si è trattato di idee che negli anni hanno contrastato con le precedenti (per motivi tenici o di marketing), o si è resa la necessità di creare delle vere e proprie pezze per mantenere una (necessaria) compatibilità con tutta una serie di vecchi applicativi.

Ad oggi, dando uno sguardo alla (maggior parte delle) applicazioni Windows ci si ritrova davanti ad un panorama di desolante confusione, dove al meglio si sono implementati set di controlli visuali personalizzati (ad esempio pulsanti stile Vista in XP e viceversa) ma al peggio ci si ritrova difronte a delle vere e proprie incosistenze del codice.

E se ogni male ha una radice quella di Windows è proprio la sua stessa azienda che è diventata la principale promotrice di software di sicuramente non eccelsa fattura (personalmente - lasciatemelo dire - sono ancora “scandalizzato” dallo scambio di posizioni tra barra dei menu e toolbar di pulsanti in Explorer).

Ma quando questi fatti erano ancora lungi dall’essere appena ipotizzati c’era un’altra azienda in grossi guai. Apple nella metà degli anni 90 si ritrovava con un sistema operativo (tecnologicamente e non solo) vecchio che non andava da nessuna parte e che aveva bisogno di un profondo e radicale cambiamento. Windows nello stesso periodo era parecchi passi avanti (multi-tasking preventivo, memoria protetta, la non necessità di allocare memoria per ogni applicazione e in generale una buona stabilità).

Il supporto agli sviluppatori, al contrario di Apple, era buono (a partire dalle copie in pre-release inviate fino alla completa MSDN library, supporto imprescindibile per chiunque volesse entrare nel mondo della programmazione win) e c’erano delle vere e proprie roadmap.

Tutto questo e altro faceva si che lo sviluppo e gli sviluppatori Windows venissero letteralmente coccolati: il sistema in poche parole era in una enorme fase di crescita.

IL TRAGUARDO DI APPLE

Anno 2001: Apple finalmente si libera dal groviglio in cui era stata invischiata da ormai più di cinque anni e acquista NeXT (il che vuol dire Jobs di nuovo in casa ma anche e soprattutto un sistema operativo nuovo di zecca). L’idea di creare da zero un nuovo sistema operativo viene definitivamente accantonata e si sceglie di utilizzare NeXTstep come base per il nuovo OS.

Mac OS X entra così dalla finestra e per diverso tempo è costretto a convivere come il fratello scomodo (e ancora bebè) del più datato e meno dotato OS 9.

Mentre OS X incomincia a crescere gli sviluppatori iniziano a guardare con interesse alla nuova via: Quartz, Postiscript a video, core BSD Unix, Cocoa, Objective-C e tutta una serie di strumenti completi e moderni fanno (e faranno) di OS X una piattaforma di nuovo competitiva.

Nel frattempo viene presa una decisione di fondamentale importanza per gli anni a venire: la compatibilità con gli applicativi di OS 9 viene relegata ad una sorta di macchina virtuale, una sorta di sondbox in grado di isolare tutte le scomodità della vecchia guardia.

In compenso si offre (sebbene più che una scelta sia stata una necessità, comunque ben congeniata) ai programmatori di convertire le vecchie applicazioni in native con pochi aggiustamenti del codice (diverse presentazioni fanno i conti in termini di giorni o poche settimane) mentre le nuove avranno la possibilità di avvantaggiarsi utilizzando tutta una serie di strumenti e tecnologie moderne.

Questo tipo di approccio ribalta le carte in tavola e porta Apple in una posizione forte e nuovamente competitiva: il nuovo OS è libero da tutto il vecchio ciarpame, le vecchie applicazioni sono messe in una nicchia, chi vuole aggiornarsi può farlo con pochi passi mentre chi vuole guardare al futuro può farlo grazie a strumenti più semplici e moderni.

XP venne rilasciato più o meno in quegli stessi anni: era la personale risposta di Microsoft, una risposta che sarebbe dovuta durare (nelle intenzioni) per i successivi cinque anni.

Cinque anni che dall’altro lato della barricata sarebbero stati pieni di novità e di release. Mac OS X 10.1, 10.2, 10.3 e infine 10.4.

In questo periodo Apple non ha guardato solo alla superficie del proprio OS (tant’è vero che l’interfaccia, tranne alcuni ritocchi è rimasta per lo più la stessa - e probabilmente questo sarà uno dei punti alla base del prossimo 10.6) ma aggiunto e svecchiati definitivamente molteplici componenti: Core Audio ha offerto un moderno framework a bassa latenza per l’acquisizione e la manipolazione di segnali audio, Core Image ha introdotto tutta una serie di strumenti per la manipolazione anche complessa di immagini e così via.

Tutti questi componenti hanno permesso alla stessa Apple ma anche e soprattutto agli sviluppatori di poter creare software di grande qualità potendo contare su basi solide, professionali e di grande qualità (un nome su tutti che si può fare è Final Cut, ormai uno standard nel proprio settore).

Quello che in definitiva ha fatto Apple è stato creare una infrastruttura completa per supportare attivamente I propri sviluppatori, abbandonando deliberatamente il proprio ecosistema di compatibilità nel giro di pochi anni e rinnovando così tutto quanto.

LA PASSIONE COME PUNTO CHIAVE

Quello che ha fatto Windows nello stesso periodo è stato generare solo una maggiore confusione. 

L’ecosistema di strumenti e oggetti di terze parti per Win è davvero vasto - molto più vasto di quello Mac - ma anche pieno di parecchie schifezze (progettualmente e qualitativamente parlando).

Ci sono poi parecchi sviluppatori ma in pochi si curano davvero di fare scelte oculate; molti di loro creano programmi gestionali in Visual Basic o siti in ASP/.net senza mettere passione nel proprio lavoro. Lo fanno perchè è un modo per essere pagati e tanto basta.

Queste affermazioni potrebbero sembrarvi stupide, ma la passione è una componente importante (non solo nello sviluppo di programmi ma anche e soprattuto in ogni aspetto della nostra vita); non c’è nessun interesse nell’usare nuove tecnologie, nel curare quello che si crea e non c’è nessun interesse nel progredire senza qualcosa che ci spinge a farlo. E probabilmente la miglior cosa che può fare questo (non sono i soldi) è la passione.

Gli sviluppatori Mac, la stragrande maggioranza di loro almeno, spesso non fanno software per grandi aziende e in generale non dimostrano lo stesso disinteresse. Questo significa che sicuramente per il mondo businness la piattaforma non offre tutto quel vasto repertorio di soluzioni che invece ha Microsoft, ma al contrario di questa ci si ritrova difronte a software di grande qualità.

Analizzando i movimenti di Microsoft in questi anni addietro si trova un peccaminoso immobilismo che è sfociato nella creazione di un OS [Vista] che non è poi così male, ma che sicuramente non è in grado di tracciare un solco che rimarrà nel tempo (è invece piuttosto probabile che Vista venga accantonato quanto prima).

Sviluppare software per Windows, secondo parecchi sviluppatori, è diventato ormai una pena e il ricordo dei bei giorni passati è ormai sfumato. Windows ha perso parecchio appeal verso i suoi sviluppatori e questo è in gran parte determinato da come Microsoft ha fatto crescere la sua creatura.

WINDOWS VISTO DA UN PROGRAMMATORE WINDOWS

Quella che segue è l’opinione di Peter Bright intervistato da Ars Technica qualche mese addietro. Peter è un programmatore Windows, o meglio lo è stato per parecchi anni, fino a quando un bel giorno si è trovato difrontre alla necessità di fare un cambiamento.

Ho creduto fosse un elemento importante per completare questa prima parte del racconto e per rafforzare le convinzioni che fin qui ho esposto (personalmente non sono un programmatore Windows e parlare per bocca mia sarebbe stato un crimine).

Nella storia di Microsoft per trovare un cambiamento che almeno in parte (una parte piuttosto piccola, difficile da mettere a confronto) sia simile a quello di Apple con OS X, dobbiamo risalire alla metà degli anni 90 e in particolare alla nascita di Windows NT.

Windows NT fu progettato come un sistema operativo moderno ma con la necessità di mantenere una compatibilità verso I suoi predecessori: fu questa la ragione per la quale le sue API (ovvero tutto il set di componenti e funzioni a supporto del programmatore) furono progettate tenendo a mente prima quelle di Windows a 16 bit, poi più avanti quelle a 32 (Win32).

Questa decisione si trascina a tutt’oggi e quindi Win64 continua a riflettere scelte ormai occorse 20 anni prima.

Lo stesso Peter Bright ha parlato a lungo in questo articolo circa Windows Vista, definendo ad esempio lo stack grafico come un modulo ancora fortemente ancorato al passato, e per questo ovviamente parecchio vecchio.

Tutto questo per far si che il vecchio riesca a coesistere ancora nel nuovo, castrando letterlamente la possibilità di innovare.

Ma quello che rende il tutto più problematico secondo Bright è l’inconsistenza che si trova in tutte le API da Windows 16 a, e soprattuto, Win32.

Le API Win32 raccolgo molte centinaia di funzioni ma la maggior parte sono inconsistenti.

Bright prende ad esempio alcune funzioni che richiedono che il chiamante dia un buffer alla funzione, che verrà usato da questa per salvare alcuni dati (e quindi la dimensione del buffer stesso sarà dinamica). Generalmente la funzione può sapere quanto deve essere grande questo buffer… ma non è così.

E se pensate che dentro Win32 questo problema sia risolto in un modo e sia lo stesso ogni volta (sperabilmente anche il migliore a disposizione), ebbene vi sbagliate di grosso.

Senza entrare troppo nel metodo ci sono almeno 4 soluzioni diverse utilizzate dagli sviluppatori MS.

Ma questo è solo uno dei tanti esempi che rendono la programmazione Win decisamente poco attraente e sicuramente a volte anche problematica.

.NET

Ma Win32 non è certamente l’ultima creatura di Microsoft in ordine di tempo. Durante gli anni di staticità di XP, mentre OS X cresceva e OS 9 entrava ormai a far parte della storia, la società di Redmond iniziò a pensare ad una nuova piattaforma di sviluppo. Il suo nome, come avrete intuito, è .NET e merita sicuramente un discorso a parte.

Il framework .NET esce nel 2002 ed è per Microsoft una rivoluzione: finalmente gli sviluppatori si trovano davanti ad un prodotto organico e aggiornato coi tempi.

Ma soprattuto potrebbe segnare un punto di svolta dalle vecchie API Win16,Win32.

.NET è stato ed è a tutt’oggi molto appoggiato da Microsoft; le campagne pubblicitarie a partire dal 2002 si sono fatte molto insistenti e la stessa Microsoft ha cercato di dare il buon esempio sviluppando parti di XP proprio in .NET.

Ma il problema di .NET non è il suo linguaggio C# (che per quanto sia simile a Java è comunque un ottimo passo avanti) e neanche la sua macchina virtuale (che in quanto a performance non se la cava male), quanto più la libreria stessa: .NET Library.

Un altro grosso problema di .NET è il pubblico si rivolge, un pubblico di programmatori che non sono tutti uguali.

Ma per capire meglio questo devo entrare più nel dettaglio.

Provate a pensare a tutte quelle persone, tecnici di laboratorio, analisti o ricercatori che usano Access, Excel o VB6 per creare le proprie applicazioni. Tutte queste persone non sono veri programmatori, a loro non interessa scrivere del buon codice, curarsi dell’interfaccia ne tanto meno di creare un buon prodotto: il loro obiettivo non è sviluppare nel senso stretto. E in questo ambito I tre tool appena citati sono il massimo.

Poi ci sono tutti quei programmatori che lo fanno per lavoro e quindi nel bene o nel male hanno una certa familiarità con quello che usano. Questa gente non ama certamente le novità e non la vedrete mai fagocitare libri tecnici per aggiornarsi. Loro usano VB6 e probabilmente non vanno oltre perchè non ne hanno bisogno ne tanto meno voglia.

Il loro codice non sarà certamente arte ma funziona e poi il basic è pure facile. Questa gente lavora a programmi gestionali, quelli per PA o per aziende private. A nessuno di loro importa fare dell’ottimo codice, e I loro utenti sono ancora meno interessati a quello che dovranno usare.

Anche se il loro software non è gran che questo è il bacino più grosso di Microsoft: si tratta di applicazioni chiave fatte in VB che girano solo e soltanto su Windows.

Alla fine troviamo invece tutti quelli che sono I programmatori veri. Questo genere di persone sono conscie di quello che usano, si aggiornano e quando programmano cercano di dare il massimo. Di solito programmano in C++ e il software finale è molto curato e sicuramente di gran lunga superiore ai precedenti.

In un mondo pre-.NET tutto questo non sarebbe stato un problema: ad ognuno il suo e così  l’analista crea macro per excel, il secondo gioca con VB e il terzo fa il mago del C++.

Ma l’obiettivo di .NET è far stare tutti dentro .NET.

L’idea di base è quella di dare un set comune a tutti questi programmatori: così mentre I primi due gruppi trovano parecchio (anche troppo rispetto a quello) di quello di cui hanno bisogno, gli esperti si scoprono tutte le magagne e limitazioni.

Cosa ancora più grave, molte delle soluzioni adottate in .NET (come ad esempio I Windows Form) sono progettate e integrate strettamente con le relative funzioni di Win32, affossando così quello che sarebbe potuto essere ma non è questo nuovo framework: un taglio definitivo con il passato.

Il SECONDO CHECKPOINT

Dopo aver visto .NET è tappa obbligata fermarsi su un altro punto cruciale della storia di Redmond. Win64, la versione riscritta delle API per sistemi a 64-bit.

Portare un programma a 32 bit in Win64 significa almeno ricompilarlo e, in alcuni casi, effettuare i necessari cambiamenti affinchè possa funzionare senza problemi e sfrutti appieno le nuove potenzialità.

Questo potrebbe portarci a pensare che forse questa volta MS abbia deciso di rendere le API più compatte (almeno un pò), ma in realtà non è stato così.

Per chiarire meglio proviamo a fare un esempio. In Windows esiste una funzione che restituisce la dimensione di un file; I file in windows sono limitati a 2 alla 64 bytes e quindi per essere espressi facilmente hanno bisogno di 64bit. Per risolvere questo su sistemi a 32 bit li si combina in una maniera particolare; su Win64 ci si aspetta invece ragionevolmente un intero di 64bit. Speranza persa.

Quello che voglio dire è che la necessità di supportare API deprecate (alcune fin da Win16) ha fatto si che Microsoft non riuscisse a tagliare in maniera adeguata i ponti con il passato, contribuendo a rendere tutto l’ambiente pieno di questi piccoli problemi che alla fine danno solo grattacapi ai programmatori come Peter.

Si è sacrificato quindi il design - e la pazienza dei programmatori - a favore di una forte retrocompatibilità.

Questo fatto si riflette sia sui programmi esterni che sulle applicazioni di Microsoft stessa, alcune delle quali (soprattuto nel settore business) non sono state più aggiornate e spesso incappano in problemi dovuti ai cambiamenti interni del sistema intercorsi nei vari aggiornamenti.

Per cercare di mantenere un ambiente il più possibile amichevole con queste applicazioni Microsoft ha inserito in windows tutta una serie istruzioni che non si sa bene come funzionano (nessuna di queste è documentata quindi la loro stessa funzionalità non è garantita da nessuno) e che tendono a rendere più fragile l’intero sistema.

Peter racconta anche un piccolo aneddoto per farci capire meglio le cose: in Windows a 16bit la cartella di sistema dove vengono inserite tutte le librerie è chiamata “system”. In Win32 il suo nome è cambiato in “system32”; in Win64 il suo nome è cambiato in… “system32”(!). Solito problema di retrocompatibilità, anche se quella cartella contiene tutta roba per il 32 bit.

I file per il 64 bit sono in “syswow64”.

Esatto, una cartella con 64 nel nome, ma che contiene file per il 32bit. Riuscite a darci un senso?

LA SITUAZIONE DI OS X

Ma lasciamo per un attimo Windows. Quello che Microsoft non è riuscita a fare, ovvero troncare in maniera netta col passato - innovando - pur mantenendo una certa retrocompatibilità, lo ha fatto Mac OS X.

Un ottimo set di API ha facilitato la creazione di applicazioni di grande qualità; le applicazioni della stessa Apple (se lasciamo di conto alcune scelte intercorse tra 10.3 e 10.4) hanno creato una pista seguita da tutte le altre perchè hanno fatto si che nell’utente si insediasse il desiderio di poter utilizzare dei buoni prodotti (buoni nel codice ma anche nella loro resa grafica).

VISTA

Quello che non si è materializzato con Windows XP Microsoft ha cercato di renderlo realtà con l’arrivo di Windows Vista; in particolare si è cercato di creare un intero set di funzionalità per .NET in grado di essere utilizzate in applicazioni chiave quale, ad esempio, lo stesso Explorer.

.NET per Longhorn (nome in codice di Vista) sin dalle prime versione ha trasmesso nel programmatore l’idea che finalmente era possibile tornare a programmare per Windows in maniera decente avendo addinittura un look&feel consistente.

Purtroppo però quell’idea è andata perdendosi tra una build e l’altra, tra un taglio e l’altro e il sogno anche questa volta è svanito. Il risultato è stato Windows Vista.

Siamo tornati così al punto iniziale del nostro viaggio, ed è finalmente giunto il momento di parlare di questa (in)voluzione.

Durante la progettazione di Vista gli ingegneri hanno lavorato parecchio sulle linee guida dell’interfaccia; l’ovvia ispirazione viene da OS X, ma la realizzazione pecca ancora di parecchi buchi.

Pensiamo ad esempio alle finestre di dialogo che in Windows sono sempre state bistrattate. Queste finestre riportano quasi tassativamente I due pulsanti “Si” “No” oppure “OK”, “Cancel”; questo significa che è necessario leggere l’intero messaggio per avere solo la vaga idea di quello che succedere.

In un mondo perfetto non ci sarebbero problemi, ma gli utenti di solito cliccano a caso e sopra le due righe di testo perdono la concentrazione.

Così in un documento di testo non ci sarà ad esempio “Save” “Don’t Save” ma “Yes”, “No”.

Dopo 20 anni Microsoft ha capito questa cosa.

L’idea delle linee guida è ottima; lo abbiam visto con OS Classic e lo vediamo con OS X. La necessità di rendere le applicazioni omogenee con l’intero sistema non è semplicemente una questione di look ma anche di semplicità e immediatezza nell’uso.

Quando neanche Microsoft rispetta le proprie linee guida ne in Vista, ne in Office, come si può pretendere che qualcuno le legga?

Window Explorer e Internet Explorer sembrano uguali, alcuni pulsanti sono simili, ma se guardate bene ci sono differenze deliberate ovunque. Non c’è nessuna consistenza. E questo si riflette sia sull’interfaccia sia sull’implementazione dei controlli (che non è la stessa e condivisa ma che ricalca scelte personali dei programmatori).

E così si ritorna di nuovo indietro.

Piccoli e grandi cambiamenti, piccole e grandi differenze che contribuiscono a rendere l’esperienza d’uso da potenzialmente buona a…sicuramente mediocre.

Se neanche Microsoft si prende cura di rispettare le proprie linee guida perchè dovrebbero farlo I programmatori? E anche volendolo fare a quale genere di implementazione dovrebbero ispirarsi? Messenger? Office? Explorer?

E per quanto la loro implementazione potrà essere usata se da una versione all’altra viene abbandonata completamente la precedente?

Mac OS X non è certamente un sistema perfetto; chi lo ha usato continuamente durante questi anni avrà sicuramente notato i diversi esperimenti (e follie) che a volta Apple ha deciso di fare sulle proprie applicazioni.

Tuttavia tranne delle piccole differenze l’interfaccia rimane quella. Ad esempio, la menubar è sempre quella, non è messa sotto i pulsanti della toolbar per chi sa quale motivo e non ha un look diverso dalle altre.

Schemi di interfaccia come le HUD (quelle grigie) sono usati da applicazioni di terze parti in ben determinati ambiti e non sfociano in un uso indiscriminato e casuale.

Questo continuo reinventare la ruota senza fare di queste realizzazioni porzioni di sistema (ovvero renderle disponibili alle altre app) ha portato alla creazione di implementazioni customizzate degli stessi che possono di nuovo cozzare col resto di Windows nel momento in cui qualcosa cambia.

La ribbon bar (quella di Office) ha ben due implementazioni, quella interna di Microsoft e quella comprata da sviluppatori di terze parti, e nessuna delle due può essere al momento usata su .NET; solo C++.

La chicca speciale è che sembra ce ne sarà una nuova anche per il prossimo sistema operativo.

CONCLUSIONE

E’ stato probabilmente l’articolo più lungo di questo blog e se siete arrivati fin qui vorrete certamente un piccolo riassunto di quanto detto.

Sono principalmente due i concetti che ho voluto sviscerarvi. Il primo riguarda un ambito che a prima vista può sembrare di poco conto: la passione che i programmatori in Windows metto nelle loro applicazioni. Questo punto è fortemente penalizzato dalle scelte di Microsoft nella sua storia, dalla incoerenza nel perseguire le proprie scelte e nello scarso e frammentato supporto che offre.

L’altro punto chiave è di natura più tecnica e riguarda la necessità sempre più impellente di dare un taglio con il passato; abbiamo visto come Apple sia riuscita perfettamente in questa scelta mentre in Redmond nella corsa a dare manforte al passato ci si è ritrovati a combattere con un futuro più disomogeneo, confusionario e ultimo ma fondamentale, anche più fragile.

Eppure, come abbiamo visto nell’ultima parte, le occasioni non sono mancate; semplicemente le si è ignorate.

Ora che Bill ha presentato le novità più grandi del Windows prossimo venturo (in cui sembra dominerà il touch) ci chiediamo se ancora una volta verranno fatti gli errori di sempre, oppure si guarderà veramente in avanti.

ShareThis

La Quantum System Lab di HP ha annunciato di aver portato a termine la prima realizzazione di un nuovo componente elettronico in grado di aprire un nuovo corso nella storia, non solo delle memorie per computer, ma anche ram. Si tratta del memristore (memory resistor), componente la cui esistenza fu ipotizzata per la prima volta dall’ingegnere Leon Chua nel 1971 durante lo studio dei circuiti non lineari (sono passati 30 anni e a discapito di tutti questi anni passati, Chua è probabilmente uno dei pochi scienziati che hanno visto trasformare in realtà le proprie teorie matematiche).

Il memristore è essenzialmente un resistore (resistenza) con capacità di mantenere il proprio stato. La resistenza atuale del memristore inoltre varia a seconda dell’intensità del voltaggio e dal suo tempo di esposizione.

Una delle prime implicazioni di una invenzione del genere riguarda certamente il campo delle memorie ram: se i computer fossero creati con componenti di questo tipo potrebbero conservare il loro stato (e quindi i dati immagazzinati) anche quando non alimentati da corrente: il risultato pratico porterebbe quindi a non avere più bisogno di “spegnere” il sistema operativo (in maniera simile alle memorie a stato solido) ottenendo così un computer decisamente più reattivo.

Il motivo per il quale soltanto in questi ultimi anni è stato possibile concretizzare la teoria di Leon è dato dal progresso tecnologico: soltanto nel 2008 il team è riuscito a sviluppare una pellicola nanoscopica di diossido di titanio tra due nastri di platino dello spessore di 5 nanometri (un decimillesimo del diametro di un vostre capello).

In particolare il gruppo di scienziati ha scoperto il memristore guardando ad un fenomeno già conosciuto: una resistenza di diossido di tanio varia il suo valore in base all’esposizione con l’ossigeno.Il memristore creato da HP è basato su una pellicola di diossido di titanio in cui mancano alcuni atomi di ossigeno. Questi difetti del cristallo permettono il passaggio della corrente elettrica attraverso il diossido; meno ce ne sono più la resistenza è alta. Questi “buchi” (come per le lacune nei semiconduttori) possono essere “guidati” da una parte all’altra della pellicola simulando i comportamenti di on-off del memoristore e la resistenza variabile.

Ma la più grande implicazione di questa teoria non sta nella capacità di memorizzare il semplice stato ma di poter utilizzare il memristore come un componente analogico nella costruzioni di altri tipi di circuito. Uno degli scopi più probabili sta nella possibilità di creare reti neurali utilizzando i memristori. Costruire un computer analogico significa non è dover utilizzare soltanto 1 e 0 per codificare le informazioni ma fare conto con tutta quella scala di valori intermedia permettendo insieme ad una alta densità di storage anche una forte potenza computazionale.

Così mentre alcuni ricercatori provano a lavorare con l’intelligenza artificiale cercando di emulare i comportamenti di un sistema biologico su un computer digitale col risultato di avere a che fare con la scarsità di potenza che ne deriva (piccole porzioni del nostro cervello richiedono attualmente grandi potenze di calcolo), il computer analogico potrà fare questo in maniera enormemente più rapida e molto più simile a quanto la nostra natura biologica ci permette.

Williams (il capo ricerca del team) a tal proposito ha detto: “Invece di scrivere programmi per computer che simulano il cervello e le sue funzioni potremmo fornire “l’hardware” necessario ad emulare il comportamento del cervello stesso”.

I risultati del team di Williams sono stati pubblicati su Nature di qualche settimana fa (è richiesta l’iscrizione). Per ora i ricercatori hanno fatto alcune prove del memristore come elemento per lo storage. In un centimetro quadrato di componente sono riusciti ad inserire 100gigabits (le memorie allo stato solido attuali arrivano fino a 16) ma questo è solo l’inizio: si pensa infatti che con opportuni affinamenti il sistema potrà contenere terabit e più per centimetro.

ShareThis

ShareThis

ShareThis

Ciao…

ShareThis

ShareThis