Riflessioni sul futuro

Non è cosa più difficile a trattare, né più dubia a riuscire, né più periculosa a maneggiare, che farsi capo a introdurre nuovi ordini; perché lo introduttore ha per nimici tutti quelli che degli ordini vecchi fanno bene, e ha tepidi defensori tutti quelli che degli ordini nuovi farebbero bene.

Niccolò Machiavelli (Il Principe, 1513)

Presentazione

Una prima versione di questo articolo è stata presentata durante la conferenza dei programmatori Amiga (IPISA), tenutasi a Milano nel novembre 1995. Sono note scritte da uno sviluppatore di software che nella comunità Amiga ha avuto il privilegio di confrontarsi con tecnologie avanzate da una parte, e problematiche esistenziali dall'altra. Con Amiga, queste riflessioni sul futuro hanno in comune la continua ricerca dell'eccellenza, mentre si lanciano in un futuro dove piattaforme diverse si interconnettono e si sovrappongono sempre più.

Introduzione

I pionieri della Silicon Valley sono nati nel posto giusto, al momento giusto. In Italia, società come Apple, Commodore e Sinclair hanno portato la democrazia nel campo dell'informatica. Macchine accessibili a tutti. La possibilità di esplorare e costruire mondi nuovi. Fare tanto con poco. Nuovi orizzonti. Crescere.

Se acquistare un calcolatore è dunque diventato facile, scrivere software sta diventando sempre più difficile e incerto. Occorrono anni per conoscere bene un sistema. Anni per portare a compimento un progetto. E intanto ci può venire meno il terreno sotto ai piedi. Quello che un giorno pare tecnicamente vincente, il giorno dopo può essere già morto. Siamo ancora nel turbine di un'evoluzione imprevedibile quanto esplosiva. Certo è che la complessità è aumentata, e tende ad aumentare ancora.

Sistemi come Amiga facevano sembrare tutto più facile, 10 anni fa. L'hardware migliore insieme al software migliore. Tutto costruito da zero, senza compromessi legati al passato. E che parola magica, il multitasking. Quanti sogni ha ispirato in chi non l'aveva, e quanti discorsi questa parola sostiene ancora oggi.

Chi programma per studio o per passione potrà sempre chiudere gli occhi di fronte alle incertezze del mercato. E magari sognare di riaprirli davanti a una BeBox, o dietro a un paio di occhiali in cui il reale e il virtuale si confondono. E se il giorno dopo non si trova neanche un pezzo di ricambio, poco male: era solo un'avventura. Sistemi come Amiga sono un'ottima nave scuola, e come tale ci lasciano comunque liberi di guardarci intorno e vivere altre esperienze, senza troppe preoccupazioni per il futuro.

Per coloro i quali programmare è diventata una professione, o un impegno per costruire un futuro migliore, il discorso si fa più serio. I giovani programmatori di oggi saranno presto meno giovani, e avranno più responsabilità. È facile sentirsi spiriti liberi, e fare le cose per scelta e con entusiasmo. Ma forse domani, per assicurare un futuro ai loro figli, tanti spiriti liberi saranno costretti a scrivere l'ennesimo programma gestionale su un sistema che disprezzano, o dovranno fare manutenzione a dei programmi scritti in COBOL prima della loro nascita. Forse non è questo il futuro a cui un giovane programmatore di oggi aspira.

Sarebbe bello, facile ed entusiasmante fermarsi a dipingere un quadro tutto rosa del futuro. Ma parlare del futuro può essere appassionante anche quando vanno considerate alcune ombre. Questo articolo intende inoltre unire qualche considerazione di fondo ai discorsi più tecnici, così frequenti nel campo della programmazione. Computer e sistemi operativi si evolvono in un mondo «vero», come molti appassionati Amiga hanno avuto (tristemente) modo di imparare da vicino.

Se siamo programmatori per hobby o di mestiere, o anche solo semplici appassionati di informatica, non potrà che farci bene tenere gli occhi aperti su quanto accade fuori: il mondo dei computer è in ogni caso molto stimolante. Forse conosciamo il computer su cui lavoriamo come le nostre tasche. E magari ci piace sentirci almeno in parte superiori a Microsoft, la più grande software house del mondo. Ma pochi sanno chi è e che cosa fa la società al secondo posto nella graduatoria, o per che cosa sia più noto il SAS Institute, il cui nome compare sul compilatore C per Amiga. Forse non ci domandiamo neanche se il futuro dei sistemi operativi verrà deciso da entità politiche come la Object Management Group, o se dipenderà invece da quello che si sta preparando in centri di ricerca più o meno discreti. In che misura sappiamo che cosa chiede il mercato? È facile venire avvolti in una visione scintillante, ma limitata e un po' sbilanciata del mondo del software. Eppure basterebbe poco. Nel momento in cui prendiamo coscienza di un possibile limite, abbiamo già messo un piede nella direzione giusta.

A costo di generalizzare e semplificare al limite del lecito, questo articolo vuole essere un piccolo tributo alla forza delle idee. Pensieri da condividere, prospettive personali, la ricerca dell'equilibrio tra l'ideale e il pratico, idee da scambiare e da cui far nascere altre idee. Anche facendo qualche confronto tra i vari sistemi operativi, e traendo spunto da diversi sistemi emergenti.

L'importanza di pianificare

I paesi del Nord Europa hanno avuto una «fortuna» che noi non abbiamo: inverni freddi hanno costretto generazioni e generazioni a prepararsi a una stagione avversa, pena l'estinzione. Anno dopo anno, questi popoli hanno dovuto prevedere, calcolare, organizzare, imparando bene a pianificare. Gli abitanti dei paesi con un clima più caldo, invece, sono sempre stati liberi di improvvisare soluzioni veloci ai problemi che si presentavano di giorno in giorno. Ne è risultata una specializzazione nel modo di porsi di fronte ai problemi. In Italia ci riconosciamo in quello stereotipo che ci vuole fantasiosi, creativi, abili improvvisatori, e diciamo che i popoli nordeuropei sono più «freddi» e calcolatori.

Ogni specializzazione ha i suoi vantaggi. Osservava un medico (italiano) che preferirebbe farsi aprire il cervello da un neurochirurgo napoletano, piuttosto che da uno tedesco. Mentre quest'ultimo avrebbe probabilmente preparato meglio tutto l'intervento a tavolino, l'italiano avrebbe forse saputo reagire più rapidamente qualora fosse comparsa una goccia di sangue non prevista. E così potrebbe essere per un programmatore che deve finire un lavoro poche ore prima di un'importante dimostrazione. Di recente inoltre l'Italia ha visto la massiccia introduzione di un nuovo tipo di «lubrificante» per una migliore gestione dell'improvvisazione: il telefono cellulare.

Ma guardiamo ai possibili problemi. Il nostro è un paese capace di coniare monete da 100 lire in tre misure diverse e incompatibili tra loro nel giro di quattro anni. E questo accade in molti altri campi. Amiga ha rischiato la morte in un sistema dove i conti venivano fatti da banchieri di sei mesi in sei mesi, dedicando sempre meno agli investimenti a lungo termine. Con i risultati che conosciamo.

Intorno a noi è in atto una tendenza che in ogni campo privilegia sempre più chi fa progetti a lungo termine. Dall'economia, all'industria, alla scienza, al software. Pare che l'informatica di domani sarà molto più orientata agli oggetti. Questi oggetti vanno definiti con molta cura, prima di essere usati (e riusati). E questo approccio è più vicino a una mentalità nordica, con cui probabilmente dovremo competere sul mercato.

Metodi tradizionali di programmazione prevedono fino a un 30% del tempo complessivo dedicato alla pianificazione iniziale, con almeno un 20% di programmazione e la seconda metà del lavoro interamente dedicata a rifiniture e prove. Ma esistono già oggi metodi di programmazione di successo in cui non si prevede di scrivere una sola riga di codice prima di aver svolto il 60% del lavoro. Per molti programmatori, invece, pianificare vuole dire «scomporre in funzioni mentre si scrive il codice».

Nei sistemi object-oriented emergenti un'accorta pianificazione consente di avere gruppi di lavoro ad altissimo rendimento, in cui solo il 5% di «superprogrammatori» definisce framework e regole (e dovrà conoscere perfettamente il sistema), mentre al 95% viene richiesto un grado di conoscenza generale molto basso rispetto alle aspettative più tradizionali. Ciò è possibile solo dando grande importanza al rispetto da parte del gruppo di «implementatori» delle specifiche definite in fase di pianificazione.

I sistemi che da noi hanno reso accessibile l'informatica a tutti hanno una triste fama di attirare programmatori bravissimi quanto solitari e «smanettoni». Di quelli che si siedono al computer e iniziano a scrivere codice dalla sera alla mattina, spesso fermandosi a pensare solo quando si presentano dei problemi. È probabile che organizzando di più prima, si potrebbe lavorare molto meglio. E ciò varrà ancora di più con i linguaggi e le metodologie di programmazione che verranno. Soprattutto in un mondo in cui non si lavora da soli, ma in gruppo. L'università (anch'essa una forma di «pianificazione») ci prepara a questo e ad altro, mentre da autodidatti siamo liberi di correre un po' di più, ma a rischio di avanzare su pericolose distorsioni. La passione è un ingrediente di vitale importanza, ma è importante indirizzarla nelle direzioni giuste.

Se dunque ogni tanto sorridiamo nel sentire un bambino che elenca a memoria i nomi dei linguaggi di cui ha appena sentito il nome, «quindi sa programmare», guardiamoci tutti indietro: Smalltalk, uno dei primi ambienti di sviluppo veramente orientati agli oggetti, è nato presso il centro di ricerca Xerox di Palo Alto (PARC) negli anni 70. Quasi dieci anni prima del «PC», e quindici anni prima di Amiga. Se oggi, in qualità di programmatori ancora a digiuno di oggetti, parliamo con chi afferma di «respirare e masticare» C++ da ben nove anni, non ci viene forse da chiederci che cosa abbiamo fatto in questi anni, quasi come uno che si sveglia e si accorge di aver perso il treno? Abbiamo investito bene nel nostro futuro?

Oggi abbiamo il tempo di scegliere come lavorare domani. Se vorremo programmare con successo per sistemi come Java, Cairo e CommonPoint, probabilmente dovremo pianificare molto di più di quanto madre natura e i sistemi operativi più diffusi ci abbiano insegnato.

Tendenze

Qualsiasi cosa noi sviluppiamo, se sapremo costruire sulla cresta di un'onda che avanza potremo vedere moltiplicate le nostre energie senza alcuno sforzo aggiuntivo, grazie alla spinta di un mercato in espansione. Al contrario, tutte le nostre fatiche potrebbero essere vanificate da un'onda avversa.

Vale la pena abituarsi a osservare le tendenze del settore in cui lavoriamo. Ad esempio, come programmatori, oggi potremmo notare:

• Realizzazione di una «grande rete» comprendente: dati, video (videotelefono, conferenze, TV interattiva, ecc.), audio (musica, telefono, ecc.), sistemi di comando e controllo (apparecchiature, luci, allarmi, ecc.)
• Architetture client/server e network-centric immerse in Internet
• Informatica sempre più diffusa e nascosta: calcolatori e microcontrollori in automobili, televisori, telefoni, orologi, giocattoli, elettrodomestici, ecc.
• Dispositivi portatili «Personal Intelligent Communicator»
• Riconoscimento del parlato e sintesi vocale
• Globalizzazione del software (con particolare espansione dei mercati asiatici)
• Nuovi modi di prendere in mano la situazione: integrazione e reengineering
• Aumento di priorità di valori come qualità, etica, ecologia
• Maggiore importanza dell'investimento a lungo termine
• Aumento dell'età media della popolazione: nuovi bisogni e politiche sociali

In una sorta di quiz, sono state citate nell'introduzione alcune organizzazioni che forse dalla finestra dei sistemi più diffusi notiamo poco.

La seconda società di software dopo Microsoft è Oracle. È il leader mondiale nel campo della gestione dei dati (soprattutto sistemi client/server). Si sta espandendo nel settore delle reti, mostrando interesse anche verso i sistemi meno costosi. Qualche mese fa era vicina ad acquistare Apple, mentre di recente ha raggiunto un accordo con Acorn (di cui la Olivetti detiene il 58% di proprietà) per la realizzazione di un terminale Internet a basso costo (circa 500 $). In una simile visione verrebbe semplificato il personal computer, che caricherebbe la maggior parte dei programmi dalla rete invece che dal disco rigido, e verrebbe valorizzato il ruolo dei calcolatori più potenti (i server) che stanno a monte della rete.

L'altra ditta, il SAS Institute «del compilatore Amiga», è all'ottavo posto tra le società di software indipendenti. Il suo prodotto di punta è il SAS System, uno dei più usati sistemi di gestione delle informazioni finalizzate al supporto decisionale. Per molti è difficile anche solo concepire quali esigenze possa soddisfare un simile sistema. Eppure, SAS Institute ha più di tre milioni e mezzo di utenti.

Tra i prodotti «interessanti» varrebbe la pena citare Lotus Notes, che ha cambiato radicalmente il modo di lavorare di chi lo usa, permettendo di organizzare e condividere in modi nuovi l'esperienza all'interno di un'organizzazione. Se non fosse stato per questo prodotto, IBM non avrebbe investito più di tre miliardi di dollari per acquisire la Lotus. Anche l'avanzata impetuosa dei servizi Internet, potenzialmente una concorrenza a basso costo, è stata per ora gestita da Lotus come una nuova opportunità per Notes.

Anche in Europa non mancano i giganti del software, come la tedesca SAP, che produce una suite di prodotti gestionali come R/3, che sono talmente richiesti da coinvolgere investimenti nell'ordine dei 10 miliardi di dollari all'anno.

Microsoft invece si accontenta dell'80% di... tutto. Se la presenza di una società come Microsoft è talmente ingombrante da fare stare tutti più stretti nel campo dei personal computer, si consideri che in altri sistemi la sua presenza è tuttora impercettibile. Nel campo del software orizzontale (i pacchetti standard che si vendono nei negozi) è già stato inventato quasi tutto e la concorrenza è feroce, ma per le soluzioni verticali (programmi «su misura» in settori molto specifici) sono ancora tempi da pionieri. E generalmente non solo c'è meno concorrenza, ma è più facile scegliere la piattaforma con gli strumenti di sviluppo migliori.

Ma già si prospettano nuove tendenze. Da una parte, è indubbio che la prossima ondata di software vedrà un uso più diffuso di componenti (concettualmente simili agli oggetti, ma più ad alto livello). D'altra parte stanno emergendo velocemente nuovi modi di distribuire, connettere e far funzionare le applicazioni, come Internet e Java.

Ideato dalla Sun, Java è sia un linguaggio (simile a un C++ semplificato) che un computer virtuale, in grado di coesistere con qualsiasi sistema operativo ospite. Sono in corso di realizzazione processori Java a basso costo (come picoJAVA e microJAVA, di Sun), da inserire nei più disparati prodotti elettronici, dal telefono al forno, e anche per questi apparecchi società come Novell stanno progettando la possibile connessione in rete. Questa è una delle tante indicazioni di come il software avrà una presenza sempre maggiore nelle cose di tutti i giorni. Così come, a parità di disponibilità economica del mercato, il personal computer toglie da anni terreno alla vendita di automobili, l'informatica sta entrando in modo sempre più diffuso nel mondo del consumo.

Più volte rappresentanti Microsoft hanno lanciato messaggi agli sviluppatori lasciando intendere quanto sia meglio puntare sul verticale, perché nessuno avrebbe speranza di successo con un nuovo prodotto come una videoscrittura. Eppure anche un'azienda come Microsoft potrebbe perdere terreno, se non riuscisse a scomporre le proprie applicazioni grandi e monolitiche in componenti più piccoli da distribuire e usare anche separatamente, in base alle necessità dell'utente. Se poi si considera che sistemi come Java consentono di caricare dalla rete quando necessario i programmi (o delle semplici interfacce di accesso) insieme ai dati, è facile osservare che potrebbero essere contati i giorni in cui si devono acquistare in anticipo dei programmi che offrono molto più del necessario e restano legati un singolo sistema operativo. In sintesi, si intravede uno scontro tra una generazione di «suite» (interi ambienti di lavoro) e una fatta di componenti e «applet» (piccoli programmi caricati dalla rete in base alle necessità del momento).

La Object Management Group (OMG), citata nell'introduzione, è un comitato che sta lavorando a uno standard industriale per condividere oggetti attraverso piattaforme diverse. Questa specifica si chiama CORBA (da Common Object Request Broker Architecture), e si propone come un ponte tra tecnologie diverse. Se questo standard dovesse avere successo, si potrà, tra le altre cose, fare un «drag and drop» di oggetti tra architetture che oggi sono incompatibili tra loro (come Java, OLE/COM/DCOM di Microsoft, e OpenDoc usato da Apple, IBM e altri).

In un certo senso, anche tecnologie apparentemente complementari potrebbero competere tra loro, rallentandosi un po' a vicenda. Non è semplice, infatti, per chi investe come per chi acquista, mettere a fuoco attenzione, energie e risorse su tanti obiettivi diversi. È più facile lottare per una sola rivoluzione alla volta. Internet e il World Wide Web, per esempio, stanno distogliendo interesse da altre tecnologie software. È un mondo che indubbiamente si sta ancora complicando, invece di semplificarsi. Però sarà anche pieno di nuove opportunità.

Considerazioni hardware

I calcolatori da scrivania negli ultimi anni sono diventati così potenti da poter ospitare sistemi operativi prima riservati a macchine che occupavano un'intera stanza con aria condizionata. Finché non si assesterà l'evoluzione dell'hardware, è difficile che inizi a stabilizzarsi e a convergere lo sviluppo del software. Intanto, la frammentazione dei sistemi operativi è stata tale da separare l'evoluzione dell'hardware da quella del software. Oggi è possibile acquistare un calcolatore e scegliere a parte uno o più sistemi operativi.

Tra le piattaforme emergenti vi è lo standard hardware PReP, con cui Apple, IBM, Motorola e altri si sono accordati su una specifica basata sull'uso di processori PowerPC (scelti anche da Amiga Technologies per la linea Power Amiga). Le specifiche PReP comprendono aspetti come la sequenza di boot, il bus di espansione e le connessioni con il mondo esterno. Oggi sono disponibili per le piattaforme PReP diversi sistemi operativi, tra cui Windows NT, AIX, OS/2 e Solaris.

Gli attuali sistemi PowerPC di Apple non sono PReP-compatibili. Apple ha inoltre preferito legare il proprio sistema operativo a un minimo di circuiteria custom, come degli zoccoli ROM, per cui Mac OS ancora non funziona (almeno ufficialmente) su sistemi PReP. In realtà diverse ditte hanno trovato delle soluzioni per aggirare questi ostacoli aggiungendo delle interfacce software. Evidentemente IBM è interessata, in quanto i suoi clienti potrebbero usare il Mac OS su sistemi PowerPC IBM in produzione oggi. Lo stesso vale per la comunità Amiga. Un'apertura di Apple all'uso di interfacce di compatibilità di terze parti permetterebbe a numerosi utenti di emulatori Mac di entrare nella legalità, acquistando una licenza approvata da Apple.

Nel corso del 1995 è stata definita la specifica Common Hardware Reference Platform (CHRP, o più semplicemente PowerPC Platform): un'estensione a PReP che verrà adottata anche da Apple. I primi sistemi sono previsti per i prossimi mesi. Con un hardware del genere, gli utenti saranno ancora più liberi di scegliere un sistema operativo senza dover riconsiderare il calcolatore. E con la contemporanea adozione del bus PCI (previsto da CHRP), anche le schede di espansione diventano compatibli tra sistemi diversi. Anche BeBox, la novità del momento costituita da un sistema multiprocessore per «tecnofili, lunatici e capelloni» (parole di Jean-Louis Gassée, fondatore della società) è compatibile con CHRP. E anche Amiga Technologies sta facendo i conti con queste prospettive. Quando tutto gira su tutto, pochi possono permettersi di essere tagliati fuori.

Sia Intel che il seguito dei costruttori di «compatibili» non sono stati a guardare immobili. L'avanzata dei sistemi PReP/CHRP è stata più lenta del previsto. Confrontarsi con uno standard costituito da 15 anni di storia di PC e più di 100 milioni di utenti non è facile, soprattutto quando le ultime generazioni di sistemi Pentium rendono più sottile la superiorità del PowerPC in termini di rapporto prezzo/prestazioni.

Un'altra tendenza hardware poco considerata è legata alla possibilità di sostituire gran parte dei sistemi fissi (desktop) con dei computer portatili. Ormai si possono scegliere configurazioni e tastiere senza compromessi. Sistemi del genere sono poco ingombranti e hanno schermi piatti che non sfarfallano e non emettono radiazioni; consumano poca energia, hanno un sistema di backup incorporato, e si portano a casa o al sicuro quando serve.

Un fiume da attraversare

Nell'evoluzione di un programmatore, si potrebbe immaginare un fiume che separa la realtà di oggi da quello che probabilmente sarà il modo di lavorare di domani. Al di là del fiume, il mondo è composto di oggetti. Vista con il distacco del tempo, questa potrebbe essere una moda passeggera. Ma molti, oggi, hanno già iniziato a bagnarsi in questo fiume.

Dall'altra parte del fiume, la produttività del programmatore sarà immensamente superiore. Sarà possibile comprendere e riusare con più facilità il codice scritto da noi o da altri (se i pezzi non fossero comprensibili, sarebbe troppo grande la tentazione di riscriverli). Si potranno costruire programmi molto complessi assemblando per tre quarti componenti già pronti, e costruendo solo il quarto che resta, concentrando l'attenzione e il lavoro su quello che si sa fare meglio. Questi componenti potranno essere presi dall'ambiente operativo, da terze parti, o dalle proprie librerie personali. Sarà come poter costruire un grattacielo usando interi piani prefabbricati.

Esisteranno dei grandi magazzini online di componenti. Sarà possibile vendere e comperare componenti e soluzioni complete attraverso Internet. Il pagamento potrà essere legato all'acquisto o all'uso effettivo («a ore»), anche tramite funzioni incorporate nei nuovi sistemi operativi. I piccoli sviluppatori potranno appoggiarsi a dei centri di servizi che metteranno a disposizione del pubblico versioni dimostrative e prodotti completi. Se per esempio gli utenti non avranno bisogno di un'applicazione ultraprofessionale, potranno acquistare solo i componenti necessari a costruire un programma più semplice. Componenti aggiuntivi saranno disponibili anche da terze parti, e potranno comunicare tra loro.

La diffusione dei componenti renderà più facile la configurazione di un sistema, e consentirà di soddisfare meglio le esigenze dell'utente. Anche la differenza tra software orizzontale e verticale potrebbe venire ridefinita in termini di componenti: qualche componente in più o in meno, e il software cambia da generico a specializzato. Così la videoscrittura potrebbe diventare parte di un pacchetto per notai, e il programma di elaborazione di immagini si presterebbe a un'integrazione in un sistema di radiologia. Lo stesso metodo sarebbe applicabile al software scalabile (ad esempio, ove esistono versioni «light», «personal» e «professional»).

Se da una parte tutto ciò tenderà a ridurre la duplicazione di sforzi (e quindi la domanda di lavoro), aprirà anche nuovi mercati, in parte simili agli ambienti di sviluppo tipici dell'Italia di oggi: piccole software house e progetti medio-piccoli (da 1 a 5 programmatori). Sarà invece un po' più faticoso per le grandi software house adattarsi a gestire applicazioni più piccole, dal momento che oggi impiegano centinaia di persone per costruire applicazioni molto complesse. Gran parte del mercato del software potrebbe venire riallineato su nuove basi.

Se già le metodologie object-oriented incrementano notevolmente la produttività del programmatore, l'efficienza sarà ulteriormente migliorata dal fatto che singoli progetti più piccoli comportano meno persone che devono coordinarsi tra loro. Ci sono molti motivi per cui 100 programmatori non sono neanche lontanamente 100 volte meglio di un singolo bravo programmatore, o anzi per cui a volte è vero il contrario. Considerando solo gli sforzi e le perdite di tempo legate alla comunicazione «uno a uno» all'interno di un gruppo di n programmatori, notiamo che questi sono proporzionali a (n²-n)/2: 10 programmatori devono parlarsi 45 volte più di due programmatori.

Vi è dunque una tendenza verso metodologie object-oriented, e un'altra che vede applicazioni basarsi su componenti sempre più piccoli. L'effetto combinato di questi due fattori potrebbe portare a risultati sorprendenti sulla produttività e sul piacere di lavorare. Per alcune aziende potrebbe essere cruciale il solo fatto di poter lanciare sul mercato un prodotto in meno tempo. Ma anche se i miglioramenti fossero per ipotesi solo minimi, nessuno potrà permettersi di restare al di qua del fiume, quando la concorrenza è già dall'altra parte.

È ragionevole che alcuni di questo concetti siano più difficilmente apprezzabili da chi non programma, o da chi ha lavorato sempre a progetti gestibili da una singola persona, magari anche completabili in pochi mesi di lavoro. Si può però riassumere che probabilmente i programmatori di domani saranno fortunati: potranno lavorare meglio e produrre di più. La programmazione a oggetti è già qui. Il software a componenti sta arrivando. Mentre sembrava prossimo un futuro in cui i giganti del software avrebbero dominato, in quanto unici a poter costruire applicazioni sempre più complesse, vi è una nuova tendenza verso applicazioni basate su componenti, alla portata delle organizzazioni più «piccole». Ci sarà spazio anche per i programmatori solitari e per nuove professioni, come l'integratore di componenti. Per i programmatori la curva di apprendimento sarà molto ripida. Imparare a lavorare bene con tecniche object-oriented è difficile e richiede tempo. Gli aspetti più tecnici e la complessità in generale, invece, tenderanno a diminuire, essendo concentrati verso chi è più qualificato per un dato compito.

Ambienti operativi

L'evoluzione, la competizione, il timore del grande e il semplice desiderio di qualcosa di «diverso» hanno dato la luce a una miriade di nuovi sistemi operativi. Da quelli più conosciuti come NextStep, Plan 9 e Spring, a quelli limitati all'ambito accademico come Exokernel, Flux, Scout e Spin. Da quelli recentissimi come Be OS, a quelli già morti (ma molto istruttivi) come PenPoint. Da quelli per sistemi verticali come Geos, Magic Cap, OS/9 e QNX, ai progetti non conclusi, come il Workplace OS. In un altro contesto, sarebbero indubbiamente degni di attenzione il sistema operativo del Newton (nel campo dei piccoli «assistenti digitali») e di TAOS, interessante per chi scrive giochi (ma non solo).

NextStep merita una menzione particolare se non altro perché ha raggiunto l'altra sponda del fiume con diversi anni di vantaggio sugli altri. Il sistema operativo di NeXT ha per ora anche l'interfaccia utente più elegante e gli strumenti di sviluppo più evoluti. Ma la società fondata da Steve Jobs, per sua stessa ammissione, non ha né l'ambizione, né la tecnologia, né l'apertura verso il mondo dei nuovi sistemi di IBM/Taligent e Microsoft. Anche negli Stati Uniti, ove i prodotti di NeXT sono più diffusi che altrove, NextStep (e l'equivalente OpenStep per piattaforme come Intel) resta un sistema consigliato a chi sviluppa software a diffusione limitata.

Apple e il Macintosh, una volta così innovativi, con gli anni hanno perso in tecnologia e in identità. Nel futuro del Mac forse ci saranno presto delle sorprese, perché Apple ne ha bisogno. Lo stesso per OS/2, più moderno, ma con una quota di mercato ancora più piccola (intorno al 5% dei PC). La pratica ha dimostrato che nessun sistema operativo, per quanto tecnologicamente eccellente, può sopravvivere a lungo al di sotto di una certa quota del mercato generale (se non dominando almeno in un settore di nicchia).

A conclusione di questa panoramica sui futuri possibili, citiamo ad esempio un ambiente operativo (CommonPoint di IBM/Taligent) e un sistema operativo (Cairo di Microsoft), tra i pochi già «al di là del fiume». Entrambi potrebbero funzionare su un sistema da scrivania (Pentium, PowerPC o altri) di oggi, e nel contempo dare indicazioni su come potrebbe o dovrebbe essere un sistema operativo del futuro.

Si è tracciata una sfumata distinzione tra un più generale «ambiente operativo» e un più specifico «sistema operativo»: un ambiente operativo come CommonPoint può coesistere con il sistema operativo ospite (così come Windows 3.1 si appoggia al DOS, o Java risiede nell'ambiente ospite). Un sistema operativo, invece, oltre a essere un'entità completa e a sé stante, è più legato all'hardware e non è integrabile con altri sistemi operativi (salvo, al momento, con l'uso di emulatori).

Taligent CommonPoint

Taligent è stata fondata nel marzo 1992 da Apple e IBM, con l'obiettivo di creare degli standard di fatto nel campo della tecnologia object-oriented. In seguito si è aggiunta Hewlett-Packard. Nel 1995 la società è stata trasformata in una unità di ricerca e sviluppo (denominata Taligent Object Technology Center) controllata da IBM.

L'ambiente operativo sviluppato da Taligent si chiama CommonPoint, e ha ereditato gran parte del progetto Pink di Apple. Il nome Pink deriva dagli appunti relativi a un ipotetico System «post-7», scritti su fogliettini di colore rosa (pink) nel corso di una riunione presso Apple, molti anni prima di Taligent. Nato dunque per essere un nuovo sistema operativo per il Macintosh, CommonPoint è oggi entrato a far parte di un progetto con cui IBM compete con gli standard di Microsoft.

Il lancio ufficiale di CommonPoint al pubblico è previsto per la seconda metà del 1996, nella versione che i progettisti chiamano Olympic. In seguito potrebbe essere reso disponibile un microkernel, o altre soluzioni che permetterebbero di usare CommonPoint da solo (senza ulteriori sistemi operativi).

Taligent nel corso degli anni ha fatto una selezione delle migliori metodologie di programmazione, e avrebbe molto da insegnare a qualsiasi programmatore. CommonPoint ha tutte le funzionalità di un moderno sistema operativo orientato agli oggetti, frutto di anni di lavoro senza compromessi né legami con il passato. Al momento ha più di 100 framework che coprono le necessità più disparate, dalla grafica alla telefonia, dalle reti ai database, dal debugging alla gestione delle licenze software.

CommonPoint è «cross platform»: funziona su diversi sistemi operativi, come OS/2, Windows 95, Windows NT, AIX e il futuro Mac OS. Da questo punto di vista, rappresenta un elemento unificante in un mondo frammentato. CommonPoint usa principalmente le funzioni di basso livello del sistema ospite, quindi non aggiunge strati appesantendo la velocità di esecuzione delle applicazioni. Per fare un esempio, una gestione di finestre CommonPoint potrebbe usare direttamente i driver video del sistema ospite, invece delle funzioni dell'interfaccia utente.

Avvantaggiato dall'esperienza di IBM nella gestione di grandi organizzazioni, CommonPoint è più aperto agli standard e ai sistemi esistenti di altri sistemi operativi. Dalle reti, ai protocolli, agli oggetti, ai dati: sono previste interfacce per comunicare con virtualmente tutti i sistemi esistenti in un'attività moderna.

L'ambiente è decisamente «task-centered computing»: molto drag and drop e un modello «saveless» per i documenti. Per fare un esempio pratico, in una videoscrittura non ci sarebbero comandi per caricare o memorizzare un testo. Esiste solo il documento, con una sua storia. Il documento potrebbe essere preso e buttato sull'icona della videoscrittura, della stampante, della posta o del fax. Sono naturalmente possibili ulteriori funzioni per limitare la storia delle revisioni del testo, o per fare una stampa direttamente dal programma di videoscrittura. Ma non sono necessarie. I programmi stessi tendono a essere nascosti, e attivati automaticamente quando un oggetto viene selezionato. Anche se l'oggetto sta dentro ad altri oggetti (come gli oggetti di grafica e testo nelle pagine di un giornale).

Il primo impatto di un programmatore con CommonPoint può essere traumatico, soprattutto per chi non ha esperienza in programmazione object-oriented con C++. Anche all'interno dell'ambiente operativo, il riuso degli oggetti è tale che il codice è grande appena una frazione di quello di un equivalente sistema operativo tradizionale. Pur essendo molto elegante, CommonPoint resta vasto. E utilizzando componenti molto interconnessi (dove non è immediato capire chi influenza chi), a volte è meglio ricompilarlo tutto. E per ricompilarlo ci vogliono 25 ore. Su 32 macchine collegate in rete. Questa è destinata a rimanere una curiosità, in quanto presto verrà utilizzato e reso disponibile un sistema basato su database per gestire la compilazione incrementale dei componenti modificati (e delle relative reazioni a catena). Anche il debugging richiede strumenti complessi, che tengono conto delle gerarchie degli oggetti.

Chi non conosce CommonPoint tende inizialmente a chiedersi il motivo di tante regole che vanno rispettate. Le ragioni si fanno più chiare quando si vedono alcuni vantaggi: il rispetto delle regole porta con sé risultati inaspettati e graditi. Leggere e capire il codice proprio e di altri può diventare facile quanto bere un bicchiere d'acqua. Inoltre, si ottengono «gratis» e senza complessità aggiuntiva delle funzionalità che altrimenti richiederebbero molto lavoro, come l'undo e il redo multilivello, la condivisione di dati e la possibilità di lavorare contemporaneamente e a distanza sullo stesso documento (anche da sistemi operativi diversi). Il tutto per il solo fatto che il codice è stato scritto in un certo modo, seguendo delle direttive che lasciano aperte molte porte.

Microsoft Cairo

Per Microsoft, la terra al di là del fiume si chiama Cairo. Questo nome in codice inizialmente era stato associato all'ormai prossimo Windows NT 4.0, che sarebbe dovuto essere un sistema operativo completamente object-oriented con un'interfaccia utente simile a quella di Windows tradizionale (oggi rappresentato da Windows 95). In pratica, Windows NT 4.0 non comprenderà tutte le funzioni del progetto Cairo, che nel frattempo è stato ridefinito come un'insieme di tecnologie, più che un sistema operativo in senso stretto.

Microsoft propone due ponti paralleli per una transizione graduale a Cairo (prevista non prima del 1998): un ponte ripido, che passa attraverso Daytona (Windows NT 3.5x, disponibile oggi) e si congiunge direttamente a Cairo, e un ponte più agevole per i rimanenti 100 e più milioni di utenti Windows, che passa attraverso le versioni (o estensioni) di Windows denominate Nashville (in previsione per il 1996) e Memphis (1997). Idealmente, alla conclusione di tale periodo, Microsoft vorrebbe lavorare con un unico sistema operativo. È utile ricordare che già oggi Microsoft pone la compatibilità con Windows NT (su piattaforma Intel) tra i requisiti per la certificazione di compatibilità con Windows 95. Quindi il software non dovrebbe mancare, e gli investimenti degli sviluppatori resterebbero tutelati. Resta possibile l'emulazione del codice Intel anche su piattaforme Windows NT non-Intel.

Come anche CommonPoint, con cui ha in comune molti dei concetti già esposti, Cairo prevede di cambiare il modo in cui il software viene acquistato e venduto: applicazioni suddivise in componenti, utilizzabili separatamente. Anche Cairo racchiuderà in un unico file system virtuale e orientato agli oggetti la gestione dei file, delle applicazioni, dei dati, della posta, della rete locale e di Internet.

In quanto evoluzione di Windows NT, Cairo sarà un sistema operativo di rete potente e sicuro. L'interfaccia utente ereditata ed evoluta da Windows 95, che per allora sarà probabilmente il sistema operativo più diffuso, dovrebbe rendere facile e poco traumatica la migrazione degli utenti. Le fortune di Cairo dipendono quindi anche dal successo di Windows NT e di Windows 95 nei rispettivi campi (fascia alta e fascia bassa), dal momento che entrambi i sistemi dovrebbero convergere in Cairo. Ma vale anche il contrario: Windows NT 3.5x e Windows 95 sono costretti già oggi a crescere nell'ombra di Cairo, e ciò è fonte di incertezze.

In Cairo, Microsoft sta facendo sue le migliori tecnologie informatiche. Per molti osservatori questa è una novità. Dietro le quinte, Microsoft da anni investe in alta tecnologia i frutti del successo di prodotti spesso criticati per il loro legame con il passato. Per Microsoft come per Intel, 100 milioni di utenti possono essere un freno all'innovazione quanto sono un vantaggio in termini di mercato. Oltre a estendersi in territori nuovi, Microsoft intende venire incontro ancora di più agli utenti di oggi, imparando anche dalle funzioni migliori dei concorrenti. Indubbiamente, potrà trarre vantaggio dall'esperienza di sistemi come CommonPoint.

Prima che sia pronto Cairo, CommonPoint e il sistema operativo di NeXT hanno il tempo di conquistare quote di mercato. Ma Microsoft sa giocare bene sulle anticipazioni di prodotti in via di sviluppo. Molti terranno presente che «è in arrivo Cairo», piuttosto che investire in qualcos'altro. Inoltre, Microsoft può avvalersi dell'esperienza dei concorrenti, evitando di ripeterne gli errori. Nel frattempo, spetta principalmente a organizzazioni come IBM/Taligent e NeXT il difficile compito di promuovere una nuova tecnologia e una nuova cultura.

Il successo di Cairo, come quello di CommonPoint, non è ovvio né scontato. Ma Cairo porta il marchio Microsoft, e per numerosi utenti e sviluppatori questo è sufficiente a giustificare una scelta («per andare sul sicuro»). Altri, invece, preferiscono ricordare che nel 1987 Microsoft promise al mondo che OS/2 sarebbe stato il sistema operativo del futuro. In questo campo è tutto molto relativo. Chi accetta di lavorarci, e soprattutto chi lo vuole fare come innnovatore, deve per ora rinunciare a ogni pretesa di stabilità.

© 1995-1998 Michele C. Battilana