\articolo{Riflessioni sul futuro}{Michele Console Battilana}

\paragrafo{Introduzione}

Tra gli incontri di programmatori, ritengo che IPISA sia in cima a quelli
che richiamano, per spirito e per qualità, i migliori. Proprio come ha fatto
\A, più di 10 anni fa. Commodore sarà anche scomparsa tra le carte dei
tribunali, ma senza Commodore non saremmo qui, oggi. I pionieri della
Silicon Valley sono nati nel posto giusto e al momento giusto. Da noi,
Commodore ha 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 sembrava
tecnicamente vincente, il giorno dopo può essere già morto. Siamo ancora nel
turbine di un'evoluzione imprevedibile ed esplosiva. Certo è che la
complessità è aumentata, e tende ad aumentare ancora.

\A faceva sembrare tutto più facile, 10 anni fa. L'hardware migliore
insieme al software migliore. Tutto costruito da zero, senza compromessi
legati al passato. Era così stimolante che probabilmente ricordiamo bene
quando l'abbiamo visto per la prima volta. E che parola magica, il
\emph{multitasking}. Quanti sogni ha ispirato in chi non ce l'aveva, e
quanti discorsi questa parola ha sostenuto, a difesa di un sistema la cui
superiorità viene sempre più messa in dubbio.

Chi programma su \A solo per passione potrà sempre chiudere gli occhi di
fronte alle incertezze. 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. \A è un'ottima nave scuola, e come tale ci lascia
comunque liberi di guardarci intorno e vivere altre esperienze. Senza troppe
preoccupazioni.

Se invece oggi siamo riuniti in un'aula universitaria soprattutto perché
vogliamo costruire un futuro migliore per noi e per gli altri, il discorso
si fa più serio. Domani saremo meno giovani, e avremo più responsabilità.
Oggi siamo spiriti liberi. Siamo qui per scelta e con entusiasmo. Ma forse
domani, per assicurare un futuro ai nostri figli, saremo costretti a
scrivere l'ennesimo programma gestionale su un sistema che disprezziamo, o
dovremo fare manutenzione a dei programmi scritti in COBOL vent'anni fa.
Forse non è questo il futuro che oggi sognamo.

Oggi vorrei pronunciare parole stimolanti. Credo che parlare del futuro possa
essere appassionante anche quando vanno considerate alcune ombre. In noi non
vedo queste ombre: sono ottimista. E credo che sia sano unire qualche
considerazione di fondo a discorsi più tecnici. Anche \A sta nel mondo vero,
come abbiamo già imparato.

Qualunque sia il motivo che ci ha portato a IPISA, è bene tenere gli occhi
aperti su quanto accade fuori, non foss'altro perché il mondo dei computer è
molto stimolante. Conosciamo \A come le nostre tasche. Ci piace sentirci
almeno in parte superiori a Microsoft, la più grande software house del
mondo. Ma pochi sanno chi è e 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 \A. 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? \A ci ha 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.

Credo nella forza delle idee. Siamo qui per questo. Credo che in poco tempo
e in poco spazio si possano concentrare pensieri interessanti e facilmente
assimilabili. A costo di generalizzare e semplificare al limite del lecito.

Avendo fatto dello sviluppo su \A una professione, sono spinto da anni a
guardarmi intorno. Vorrei condividere alcuni pensieri. Prospettive in gran
parte personali. Idee da scambiare e da cui far nascere altre idee. Anche
facendo qualche confronto tra \A e gli altri, e traendo spunto da diversi
sistemi emergenti. Qualche critica, forse, ma a fini costruttivi. Mi fermo
su alcuni punti che ritengo migliorabili, piuttosto che riposare su quello
che funziona bene. Mi piacciono le sfide, e trovo stimolante la ricerca
dell'equilibrio tra l'ideale e il pratico. \A è anche questo.


\paragrafo{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. Gli abitanti dei paesi con un
clima più caldo, invece, sono sempre stati liberi di improvvisare soluzioni
veloci a problemi che si ponevano di giorno in giorno. 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 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.

Ma guardiamo ai possibili problemi. Il nostro è un paese capace di coniare
monete da 100 lire in tre misure diverse e incompatibili nel giro di quattro
anni. E questo accade in molti altri campi. \A ha rischiato la morte in
un sistema dove i conti si facevano 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 programmi a medio e 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).

\A ha una triste fama di attirare programmatori solitari e
``smanettoni''. Bravissimi, ma di quelli che si siedono al computer e
iniziano a scrivere codice dalla sera alla mattina, fermandosi a pensare
solo quando si presentano dei problemi. È probabile che organizzando di più
prima, si potrebbe lavorare molto meglio. E ciò varrà probabilmente 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. Avendo lasciato l'università dopo pochi esami, mi sforzo
di esserne sempre cosciente.

Se ogni tanto sorridiamo a sentire un ragazzino che elenca a memoria i nomi
dei linguaggi di cui ha sentito il nome, ``per cui sa programmare'',
guardiamoci indietro anche noi. Smalltalk, uno dei primi ambienti di
sviluppo orientati agli oggetti in senso stretto, è nato presso il centro di
ricerca Xerox di Palo Alto (PARC) negli anni 70. Quasi quindici anni prima
di \A. Quando parlo con programmatori che dicono di respirare e mangiare
C++ da ben 8 anni, mi chiedo che cosa ho fatto, in quegli anni, quasi come
uno che si sveglia e si accorge di aver perso il treno. Ho investito bene
nel mio futuro?

Metodi tradizionali di programmazione prevedono fino a un 30\% del tempo
complessivo dedicato alla pianificazione iniziale, con la seconda metà del
lavoro interamente dedicata a rifiniture e test. 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 (\A e non), 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.

Oggi forse abbiamo il tempo di scegliere come vorremmo lavorare domani. Se
vorremo programmare con successo per sistemi come Cairo e CommonPoint
(magari su un \A RISC), dovremo pianificare molto di più di quanto \A
e madre natura ci abbiano insegnato sino ad ora.


\paragrafo{Tendenze}

Qualsiasi cosa noi sviluppiamo, se sapremo costruire sulla cresta di un'onda
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 fare l'abitudine ad analizzare le tendenze del settore in cui
lavoriamo. Ad esempio, come programmatori, oggi potremmo notare:
\begin{itemize}
\item reti a larga banda e televisione interattiva;
\item network-centric computing;
\item calcolatori sempre più potenti nelle automobili;
\item sistemi sempre più diffusi e nascosti: in telefoni, orologi,
giocattoli, elettrodomestici ecc.;
\item dispositivi ``Personal Intelligent Communicator'';
\item riconoscimento del parlato e sintesi vocale;
\item globalizzazione del software;
\item espansione dei mercati asiatici;
\item integrazione;
\item reengineering;
\item aumento di priorità di valori come qualità, etica, ecologia;
\item maggiore importanza dell'investimento a lungo termine nell'utenza;
\item aumento dell'età media della popolazione: nuovi bisogni e politiche
sociali.
\end{itemize}

\noindent In una sorta di quiz, ho citato nell'introduzione alcune organizzazioni che
forse dalla finestra \A 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 molto nel settore delle reti, e qualche mese fa era molto
vicina ad acquistare Apple.

L'altra ditta, il SAS Institute ``del compilatore \A'', è 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. Difficilmente riusciamo anche solo a
concepire quali esigenze può soddisfare un simile sistema. Eppure, SAS
Institute ha più di tre milioni e mezzo di utenti. Più di quanto una
software house per \A possa sognare. Con un prezzo per unità che potrebbe
in alcuni casi essere sufficiente a rilevare una software house per \A.
Il ``nostro compilatore C'' non è costato loro il battito di un ciglio.

È un peccato che siamo così lontani da programmi come 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 quel prodotto, IBM non avrebbe
investito più di tre miliardi di dollari per acquisire la Lotus.

E potrei continuare con delle ditte europee, come il gigante tedesco SAP,
che produce una suite di prodotti gestionali come R/3, che sono talmente
richiesti da coinvolgere investimenti pari a cinque volte il fatturato della
ESCOM.

Microsoft invece si accontenta dell'80\% di\ldots  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: al cliente può importare poco se sul computer che in fabbrica
controlla una macchina c'è scritto \A o meno.

Ma già si prospettano nuove tendenze. La prossima ondata di software vedrà
un uso sempre più diffuso di componenti (concettualmente simili agli
oggetti, ma più ad alto livello). I rappresentanti di Microsoft lanciavano
volentieri messaggi agli sviluppatori lasciando intendere quanto fosse
meglio puntare sul verticale, perché nessuno avrebbe avuto speranza di
successo con un prodotto come una videoscrittura. Ma la stessa Microsoft
potrebbe perdere terreno, se non riuscisse a scomporre le proprie
applicazioni grandi e monolitiche in componenti più piccoli da distribuire,
usare e riusare anche separatamente, in base alle necessità dell'utente.

Di certo, le nuove opportunità non mancheranno.


\paragrafo{Considerazioni hardware}

A parlare di hardware, basterebbe citare nomi come il Power
Indigo$^{\text{2}}$ Maximum
Impact per fare avere qualche istante di incertezza anche agli Amighisti più
convinti. Al momento pare un evoluzione senza fine.

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 che si incroceranno sempre più spesso con \A
vi è lo standard PReP, con cui Apple, IBM e Motorola si sono accordati su
una specifica comune basata sull'uso di processori PowerPC (scelti anche da
Amiga Technologies). Le specifiche PReP comprendono aspetti come la sequenza
di boot, il bus di espansione e le connessioni con il mondo esterno. Tra gli
altri, oggi sono disponibili per le piattaforme PReP i sistemi operativi
Windows NT e AIX, e versioni beta di OS/2 e Solaris.

Gli attuali sistemi PowerPC di Apple non sono PReP-compatibili. Apple ha
inoltre preferito legare comunque il proprio sistema operativo a un minimo
di logica custom, come degli zoccoli ROM, per cui Mac OS ancora non funziona
(almeno ufficialmente) su sistemi PReP. Ciò dovrebbe cambiare presto:
diverse ditte hanno infatti trovato delle soluzioni per aggirare questi
ostacoli, un po' come fanno ShapeShifter ed Emplant su \A. Evidentemente
IBM è molto interessata, in quanto i suoi clienti potrebbero usare il Mac OS
su sistemi IBM in produzione oggi. Lo stesso vale per la comunità \A.
Un'apertura di Apple all'uso di interfacce di compatibilità di terze parti
permetterebbe a numerosi utenti di emulatori Mac su \A di rientrare nella
legalità, acquistando una licenza approvata da Apple.

Quest'anno è stata finalmente definita la specifica Common Hardware
Reference Platform (CHRP): un'estensione a PReP che verrà adottata anche da
Apple. I primi sistemi sono previsti per l'inizio del 1996. Con uno 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 (consigliato da CHRP), anche le schede di espansione
diventano compatibli tra sistemi diversi. Anche la novità del mese, un
sistema multiprocessore per ``tecnofili, lunatici e capelloni'' (parole di
Jean-Louis Gassée) chiamato BeBox, è compatibile con CHRP (e quindi con
PReP). Certamente anche Amiga Technologies sta facendo i conti con queste
prospettive. Quando tutto gira su tutto, pochi possono permettersi di essere
tagliati fuori.

Un'altra tendenza hardware poco considerata è legata alla possibilità di
sostituire gran parte dei sistemi desktop con dei computer portatili. Ormai
si possono scegliere configurazioni e tastiere senza compromessi. 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. Chissà se Amiga Technologies
ci farà questo regalo. Molti sarebbero disposti a pagare il prezzo. Per
alcuni è una necessità che taglia sempre più i ponti con il mondo \A.


\paragrafo{Un fiume da attraversare}

Nella nostra evoluzione di programmatori, si potrebbe immaginare un fiume
che ci separa da come probabilmente lavoreremo domani. Al di là del fiume,
il mondo è composto di oggetti. Vista con il distacco del tempo, questa
potrebbe essere una moda passeggera. Ma per noi, oggi, è un fiume in cui
abbiamo iniziato a bagnarci.

Una volta dall'altra parte del fiume, la nostra produttività di
programmatori sarà immensamente superiore. Potremo comprendere e riusare con
più facilità il codice scritto da noi o da altri (se i pezzi non fossero
comprensibili, saremmo tentati di riscriverli). Potremo 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 sappiamo fare meglio. Questi componenti potranno essere presi
dall'ambiente operativo, da terze parti, o dalle nostre librerie personali.
Sarà come poter costruire un grattacielo usando interi piani prefabbricati.

Esisteranno dei grandi magazzini \emph{on line} 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''),
con l'aiuto di funzioni dei 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 del calibro di PhotoShop,
potranno acquistare solo i componenti necessari a costruire un programma del
tipo Personal Paint. Componenti aggiuntivi saranno disponibili anche da
terze parti, e potranno comunicare tra loro.

Se da una parte ciò tenderà a ridurre la duplicazione di sforzi, aprirà
anche nuovi mercati, in parte simili all'ambiente \A di oggi: piccole
software house e progetti medio-piccoli (1-5 programmatori). Sarà infatti
più faticoso per le grandi software house, che impiegano centinaia di
persone per costruire applicazioni molto complesse (e fuori dalla portata di
sviluppatori \A), adattarsi a vivere di prodotti più piccoli. Gran parte
del mercato del software verrebbe riallineato su basi più piccole. Gli
sviluppatori \A sono già abituati a lavorare in questi ordini di
grandezza.

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, con sforzi e perdite di tempo proporzionali a
$(\text{\textit{n}}^{\text{2}}-\text{\textit{n}})/\text{2}$. L'effetto combinato di questi due fattori (metodologie
object-oriented e applicazioni basate su componenti) potrebbe avere effetti
sorprendenti sulla produttività e sul piacere di lavorare. 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.

Mi rendo conto che alcuni di questi concetti sono difficilmente apprezzabili
da chi non ha mai lavorato a un progetto medio o grande in cui lavorano più
programmatori. Posso però riassumere che probabilmente saremo fortunati:
potremo lavorare meglio e produrre di più. La programmazione a oggetti è già
qui. Mentre sembrava che in futuro 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 del programmatore \A di oggi. Ci sarà spazio anche per i
programmatori solitari e per nuove professioni, come l'integratore di
componenti. Per i programmatori la curva di apprendimento per attraversare
il fiume 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 più
concentrati verso chi è qualificato.


\paragrafo{Ambienti operativi}

A conclusione di questa personale panoramica sui futuri possibili, vorrei
brevemente fare il punto su un ambiente operativo (CommonPoint di Taligent)
e un sistema operativo (Cairo di Microsoft), tra i pochi ``al di là del
fiume''. Entrambi potrebbero funzionare sull'\A di domani, o comunque
dare indicazioni su come potrebbe o dovrebbe essere un futuro sistema
operativo per \A.

La distinzione tra ambiente operativo e sistema operativo è sottile: un
ambiente operativo come CommonPoint può coesistere con il sistema operativo
ospite (così come Windows 3.0 si appoggia al DOS). Un sistema operativo,
invece, oltre a essere un'entità completa, non è integrabile con altri
sistemi operativi (salvo, al momento, l'uso di emulatori).

Esclusi quelli vecchi (in senso lato) e noti, ho considerato diversi sistemi
operativi in qualche modo innovativi, prima di limitarmi a due. Da quelli
più popolari come NeXTStep, Plan 9 e Spring, a quelli limitati all'ambito
accademico come Exokernel, Flux, Scout e Spin. Da quelli nuovi come BeBox, a
quelli già morti (ma istruttivi) come PenPoint. Da quelli per sistemi
verticali come GeoWorks, QNX, Magic Cap e OS/9, ai progetti mai conclusi,
come il Workplace OS. Avrei voluto parlare del sistema operativo del Newton,
nel campo dei piccoli ``assistenti digitali'', e di TAOS, interessante per
chi scrive giochi, ma non solo. Per il futuro del Mac forse ci saranno delle
sorprese, perché Apple ne ha bisogno. Lo stesso per OS/2, più moderno ma con
una quota di mercato ancora più piccola. Forse CommonPoint darà una mano a
entrambi. Ho escluso \A non perché ``vecchio'', ma perché spero
sempre che tutto il mondo già lo conosca.


\paragrafo{Taligent CommonPoint}

Taligent è stata fondata nel marzo 1992 da Apple e IBM (in seguito si è
aggiunta Hewlett Packard). L'ambiente operativo sviluppato da Taligent si
chiama CommonPoint, e ha ereditato gran parte del progetto Pink di Apple
(chiamato Pink dagli appunti relativi a un futuro System 8, scritti su
fogliettini rosa nel corso di una riunione). Il lancio ufficiale di
CommonPoint al pubblico è previsto per l'autunno 1996, nella versione
attualmente denominata Olympic.

CommonPoint ha tutte le funzionalità di un moderno sistema operativo
orientato agli oggetti, risultato da anni di lavoro senza compromessi né
legami con il passato. 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, su \A per la gestione delle
finestre CommonPoint potrebbero venire usate direttamente le primitive
grafiche, invece di Intuition.

Influenzato da IBM, CommonPoint è più aperto agli standard di qualsiasi
altro sistema operativo. Dalle reti, ai protocolli, agli oggetti, ai dati.
Ci sono interfacce per comunicare con virtualmente tutti i sistemi esistenti
in un'organizzazione.

Il primo impatto di un programmatore esterno con CommonPoint è traumatico,
soprattutto per chi non ha esperienza in programmazione object-oriented con
C++. Pur essendo molto elegante, CommonPoint è vasto. Gli oggetti sono così
riutilizzati e interconnessi tra loro che il codice è grande appena una
frazione di quello di un sistema operativo tradizionale. Comunque, per
ricompilarlo, ci vogliono 25 ore. Su 32 macchine collegate in rete. Questo
dovrebbe cambiare in meglio non appena verrà utilizzato un database che sarà
in grado di 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 poi a chiedersi il motivo di tante regole
che vanno rispettate. Ciò risulta evidente quando si vedono i risultati: il
rispetto delle regole porta con sé tanti risultati inaspettati e graditi. Il
``task-centered computing'' è applicato alla lettera. Per i documenti vale
un modello ``saveless'' senza operazioni di memorizzazione o caricamento:
solo drag and drop. L'undo e il redo multilivello sono automatici e
trasparenti all'applicazione. E così la condivisione di dati e la
possibilità di lavorare a distanza sullo stesso documento. Il tutto anche
attraverso piattaforme con sistemi operativi diversi. Sono piccoli esempi di
grandi cose per cui il programmatore non deve scrivere una riga di codice.

Taligent nel corso degli anni ha fatto una selezione delle migliori
metodologie di programmazione, e potrebbe insegnarci molto.

Il fatto che \A sia incompatibile con gli altri sistemi è un peso sia per
chi acquista hardware \A, sia per chi investe tanto tempo per realizzare
software \A. Se CommonPoint venisse portato su \A, risolverebbe questo
e tanti altri problemi. Per esempio, potrebbe estendere l'evoluzione di un
sistema operativo che è fermo da anni e che ha perso quasi tutti i suoi
autori. E potrebbe calzare come un guanto su \A, in quanto aggiungerebbe
le funzioni ad alto livello che a noi mancano, sfruttando appieno le
potenzialità di basso livello, che invece abbondano. Naturalmente, essendo
solo un'estensione (opzionale) non toglierebbe nulla alla possibilità di
usare \A per giocare. Sarebbe una bella stazione di lavoro. Per ora è un
bel sogno.


\paragrafo{Microsoft Cairo}

Per Microsoft, la terra al di là del fiume si chiama Cairo. Questo è il nome
in codice di quello che probabilmente verrà commercializzato come Windows NT
4.0, un sistema operativo completamente object-oriented con un'interfaccia
utente simile a quella del Windows tradizionale.

Microsoft propone due ponti paralleli per una transizione graduale a Cairo
(prevista per il 1998): un ponte ripido, che passa attraverso Daytona
(Windows NT 3.51) e si congiunge direttamente a Cairo, e un ponte più
agevole per i rimanenti 80 milioni di utenti Windows, che passa attraverso
le versioni di Windows denominate Nashville (1996) e Memphis (1997).
Idealmente, alla conclusione di tale periodo, Microsoft vorrebbe lavorare
con un unico sistema operativo.

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.
Sarà più facile configurare un sistema per soddisfare esattamente le
esigenze dell'utilizzatore.

Come 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, renderà
facile e poco traumatica la migrazione degli utenti. Certamente, le fortune
di Cairo dipendono dal successo di Windows NT e di Windows 95 nei rispettivi
campi.

Come i propri concorrenti, Microsoft è abile ad acquisire le funzioni
migliori ispirate da varie fonti. Certamente Cairo farà sue le migliori
tecnologie informatiche, incorporerà le funzioni migliori dei concorrenti, e
potrà trarre vantaggio dell'esperienza di CommonPoint.

Il successo di Cairo, come quello di CommonPoint, non è per nulla certo, ma
Cairo porta il marchio Microsoft, e per molti utenti e sviluppatori, questo
è già un buon motivo per ``andare sul sicuro''. Tutto dipende in gran parte
dalla misura del successo dei diretti concorrenti: NeXTStep/OpenStep e
CommonPoint.

Mi piace pensare che con qualche sistema operativo in più, \A avrebbe
anche qualche carta in più da giocare. Tanto più che la concorrenza ne sta
mettendo insieme un bel mazzo. Nel caso di CommonPoint ho ipotizzato un
porting su \A. Per Cairo, ovvero Windows NT, non è necessario fare
ipotesi. Infatti Windows NT girava in gran segreto su \A già diversi anni
fa. Ma del resto, con due versioni di Unix su \A, sapevamo che portare un
sistema operativo nuovo è solo questione di volontà. E questa, agli
sviluppatori \A, non è mai mancata\footnote{Una versione aggiornata di questo
articolo è disponibile via posta elettronica contattando l'autore.}.

\autore{%
Michele Console Battilana\\
Cloanto Italia srl\\
Via G.B. Bison 24\\
33100 Udine UD\\
Tel.:~(0432)545902
}{Internet: mcb@cloanto.it}

\citazione{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 (\emph{Il Principe}, 1513)}