INTRO

Questo breve articolo introduce alla programmazione in ambiente Apple, in particolar modo in ambiente OSX.

OSX è il nuovo sistema operativo installato su ogni Mac ormai da 4 anni.

La sua genesi è lunga e ne darò qualche spunto qua e là.

Diciamo solo per chi non è familiare con OSX, che è un successore di Unix, stile BSD, e NON è Linux: qualcuno storcerà il naso.. ma non ha mai usato Mac..

A parte gli scherzi, OSX porta quindi con sé tutto il bagaglio di sistemi di sviluppo cari ai guru di Unix. E’ quindi possibile avere shell, gcc, gdb etc.

Ma Mac senza la sua superiore grafica non è Mac: vedremo quindi cosa è possibile creare in ambiente grafico sotto OSX utilizzando le tecnologie di punta della casa di Cupertino.

Talora ripercorro parti della storia di Mac e del suo sviluppo, forse troppo personale, ma la ho vissuta. Mi hanno chiesto di scrivere un articolo: "Come si sviluppa su Mac?" e descrivo anche come si è sviluppata la programmazione sotto la mela negli ultimi 20 anni.

Prima di passare ai linguaggi, un brevissimo glossarietto dei termini appena citati e di quelli che verranno utilizzati più avanti.

shell

il consueto ambiente in modalità carattere di unix in cui si digitano (orrore!! non si fa tutto in modalità grafica??) i comandi e che permette di lanciare tutti i classici programmi di unix.

compilatore

un programma che legge un file di testo (detto sorgente) e produce un file binario (anche se non direttamente eseguibile)

gnu

una iniziativa in ambiente open source di free software.

gcc

Acronimo che sta per GNU C Compiler. È un compilatore open source, free, che compila su tutto e per tutto, ossia esiste per ogni s.o. e produce binario per ogni tipo di microprocessore e ambiente.

Anche se si chiama "C" compiler, compila anche ben altro: C++, Objectve C, asm..

gdb

GNU debugger: un potentissimo debugger a livello di sistema in ambiente Unix.

Aqua

La tecnologia di disegno 2D di Apple per creare le interfacce utente e le finestre.

OpenGl

Tecnologia open source per disegno e rendering 3D

Quarz

La tecnologia 2D di Apple per i documenti: ingloba PostScript e PDF, and many more..

 

LINGUAGGI

Passiamo brevemente in rassegna i linguaggi utilizzabili.

In ambiente OSX esistono un po’ tutti i linguaggi disponibili, meno il Visual basic (evviva!), ma ovviamente la parte del leone la fanno tutti quei linguaggi derivati da Unix.

Il C è il re (quasi) incontrastato dei linguaggi sotto Unix, e ovviamente qui è presente ed utilizzabile.

Il suo successore, (non me ne vogliano i "puristi" dei linguaggi..) il C++ è utilizzato, utilizzabile e comodo, ma va scomparendo.

Il Pascal esiste, ma è poco utilizzato: richiede fra l’altro tool a parte un po’ costosi. É un peccato: lo ritengo un ottimo linguaggio. Su Mac ha poi una storia: è stato per anni il linguaggio ufficiale di sviluppo del s.o.

Orde di programmatori Mac hanno scritto i primi "VAR event: OSEvent;" prima di arrivare al brutto: "OSEvent event;".

L’Assembler puo’essere impiegato sotto OSX, non è pero’ molto in voga: la sua sintassi e la sua logica richiedono skill tecnici elevati. Sarà poco comodo, ma ci sono affezionato: un vero programmatore o sa l’assembler o non sa programmare.. (nda). A parte gli scherzi, l’asm sotto OSX gode di un buon supporto sia come strumenti di scrittura che di debugging. Esistono vari esempi di codice sul sito del supporto Apple, rivolti in particolar modo a chi vuole ottimizzare oltre ogni limite funzionalità p.e.s di calcolo.

Java: è presente, funziona, è allineato e Apple punta non poco su questo linguaggio/sistema/piattaforma. I tool sono buoni, il debugger funziona, il supporto sistemico è adeguato. Apple ha anche deciso di integrarlo pesantemente con QuickTime per il Multimedia ma soprattutto con Cocoa (vedi sotto) per le funzioni di sistema, Applicazioni ibride/JNI.

A mio parere ha alcune pecche, non sotto OSX, ma in generale, fra cui spiccano:

• la lentezza (ok..ok.. non è fatto per scrivere il kernel..)
• la bruttezza delle interfacce utente. Opinabile ma è così.. non è né carne né pesce, non sembra Windows, non sembra OSX, non sembra KDE, non sembra GTK.. mah.
• Per ogni classe un file.. una palla infinita..
• Scarsa integrazione fra interfaccia e codice.

Ne apprezzo invece la estrema pulizia formale della sintassi.

Comunque esiste, funziona, si puo’ sviluppare decentemente.

Fortran: esistono ottimi tool, professionali, che permettono di utilizzare routine di calcolo stra-testate da 50 anni di fortran, con la performance del nuovo G5. Non li ho mai usati, anche perché onestamente il Fortran non mi piace.

Objective C:

Un linguaggio nato dopo il C++, che pretende di aver veramente incarnato la programmazione ad oggetti portando la OOP dentro il C, dopo il tentativo (mal riuscito, secondo i guru di Obj C..) del C++, che a loro dire è un brutto ibrido.

La sintassi di base è la stessa del C, ma sono completamente diversi i seguenti aspetti:

• classi: esistono ma con sintassi differente
• ereditarietà singola (alla java)
• gestione della memoria: a metà strada fra il c (malloc/free.. che incubo!) e java: per chi ci arriva per la prima volta sembra il peggio di entrambi.. ma non è vero.. ObjC tenta un approccio ibrido che, una volta appreso, ci libera del peso del "rilascio", ed è molto efficiente, molto più di java, col suo "monnezzaro" (il garbage collector).
• Risoluzione a run time (late binding) di tipi, chiamate, metodi fra eseguibili diversi.
• Sintassi per le chiamate dei metodi molto bella, lineare, immediata, pulita. Se avete la classe Mamma, all’istanza mamma potete dire:

Mamma mamma;
[mamma butta:lapasta colsugo: vongole];

(dove ovviamente "lapasta " e "vongole" sono parametri)

• La solita miriade di classi già pronte, che ereditano, si subclassano e così via. (iteratori, dizionari, collection, xml..)

..io tifo per objC. (dopo l’assembler.. ovvio).

 

COCOA: it comes from Next Step..

Cosa è veramente? Che definizione dare? Dal mio punto di vista è alla fine una tecnologia. Ma vediamo che dice Apple:

"Cocoa is a rich set of object-oriented frameworks that allow for the most rapid development of applications on Mac OS X."

In definitiva Cocoa è un insieme di tecnologie, di librerie, di header, basati su un approccio OOP per scrivere applicazioni con interfaccia grafica avanzata.

Cocoa implementa il paradigma Interface/Implementation: scrivo l’interfaccia con elementi grafici, menu, bottoni e così via e a parte scrivo il codice di elaborazione. Non mischio mai codice con interfaccia.

La storia di Cocoa è un po’ lunga, deriva dall’ambiente di sviluppo OpenStep che Next creò qualche anno addietro. Quando Apple acquistò la Next, ebbe anche OpenStep, e direi anzi che acquistò proprio per questo Next: Next aveva un sistema di sviluppo basato su un s.o. robusto, a base Unix con un sistema di sviluppo veloce, ad oggetti, potente, ma soprattutto testato.

Questo sistema di sviluppo era nato prima sul mitico cube di Next, a base motorola 68000, poi portato sotto Intel, ma con un approccio diverso: sotto Intel si installava uno strato (appunto un framework) sopra windows ( rigorosamente NT.. per avere un sottosistema affidabile, e per avere posix). Lo ho usato quasi 10 anni fa in Apple ad un corso "per iniziati". Sotto Mac è stato poi portato riscrivendo completamente le parte sottostanti Unix per adattarle al PPC: era nato Rhapsody.

Ho usato anche quello in Apple, ad un altro corso, l’effetto fu strano: l’hw erano dei Mac (pompati a manetta.. per avere prestazioni accettabili..) con su uno strano sistema operativo a finestre, a cui non eravamo abituati, con sotto quelle bruttissime cose, nere, le console..

Caspita, il prompt a noi programmatori Mac che "vivevamo" solo di interfaccia grafica da 10 anni?

Ma ricordo che l’impressione fu di essere dieci anni avanti windows, che nel 96 rilasciava win95! (stendo un velo pietoso su cosa fosse linux nel 96..).

Rhapsody era un bel derivato di Unix, stabile, carino, e sì su esso si sviluppava ad oggetti, appunto in OpenStep, il nonno di Cocoa. Noi programmers della mela avevamo visto negli anni precedenti tecnologie fra le più strane, poteva essere l’ennesimo flop, ma la tecnologia era buona.. Fortunatamente fu così. Grazie, Steve, ora abbiamo OSX.

Tornando ad oggi, Cocoa rappresenta quindi la tecnologia de-facto per sviluppare applicazioni col look and feel di Apple.

I suoi punti di forza:

• Approccio RAD (rapid application development): non scrivo una riga di codice per l’interfaccia: la disegno e poi col mouse la collego al codice.
• Classi, classi, classi
• Possibilità di chiamare routine sia del Framework sottostante, come chiamate nel vecchio stile del s.o. pre osx, diremmo chiamate "classiche" che per 15 anni abbiamo usato.
• Possibilità di chiamare routine dello strato bsd, socket, di shell, tutto quel orribile miscuglio di attrezzi e chiamate di unix
• Possibilità di mischiare il tutto con asm, java, pascal..
• Efficienza. È comunque un linguaggio compilato: le applicazione "pompano". Se devo stimare "a pelle" la velocità di una applicazione Cocoa con una tradizionale, direi che perderà un 10 max 20%, ma soprattutto nella interfaccia: il codice "sotto", quello duro, quello che spreme la cpu è lo stesso, ma avete una interfaccia pazzesca sviluppata in un decimo del tempo.
• Supporto "gratis" per Applescript, il linguaggio di scripting di Apple.

 

TOOL

Passiamo ora ai tool attualmente disponibili.

Cito l’ottimo Metrowerks Codewarrior X, figlio del mitico Codewarrior che ha permesso a tutti noi di vivere in un ambiente decente, ben debuggabile, veloce, a differenza del vecchio kit di sviluppo ufficiale di Apple, MPW (finalmente è morto..).

MW CodeWarrior è un ottimo IDE, compila sia per OS9 che per OSX e fa anche cross-compiling. La versione completa fa anche cross-compiling fra OSX e Windows. Perché non usarlo ancora? Semplicemente perché costa circa 800$ e li varrebbe, ma le alternative sono valide. (vedi sotto.) Ora è stato acquistato da Motorola, e la mia impressione è che finirà per essere un tool per sistemi embedded, non più per Mac.

La vera parte del leone la fa XCode, figlio di Project Builder, nipotino di OpenStep.

Per spiegarne l’adozione, cito quanto mi ha detto uno sviluppatore italiano che vive a Londra, nel corso di "Carbon Kitchen 2001" nella sede di Apple. Alla mia domanda: "Perché non usi codewarrior per osx?" la risposta fu: "Project Builder è gratis e funziona". Non aveva torto. Il primo PB era un po' lento, anche perché era stato un porting da OpenStep. Via via si è raffinato fino ad ora, e si chiama Xcode. Vediamo le caratteristiche salienti:

• E’ un IDE in puro stile OSX, quindi menu contestuali, drag&drop, icone, finestre.
• L’editor integrato ha la classica syntax coloring ed anzi permette (volendo..) di scrivere con font e corpi diversi( !!)
• La sintassi è validata un po’ per tutto: C/C++/Obj C/java, php, HTML
• Legge un po’ di tutto: testo nelle varie codifiche (7 bit ascii sia con a capi Unix che Mac che Win), Unicode UTF, RTF, JPG, TIF ed altro appoggiandosi a editor interni o esterni.
• Supporto per CVS anche via FTP
• Class browser sia per cocoa che per java
• Fornisce comode scorciatoie dal codice ai rispettivi header, ma anche alle definizioni sia di sistema che utente
• Debugger integrato: "sotto" gira il buon gdb per osx, perfettamente integrato. Nelle finestre di debugger si vedono al volo i valori delle variabili e da linea di comando ( eddai..) si possono analizzare anche istanze di tipi di Cocoa. Naturalmente debugga anche java, e se usate JNI fra cocoa e java, si segue fra i due.



• E’ parametrizzabile all’infinito.. troppe opzioni, forse.



• Supporta un po’ tutti i compilatori: una volta configurato con regole opportune (quelle per default sono più che sufficienti per il 90 % dello sviluppo) lancia compilatori (altri tool) per:
• C
• C++
• Obj C
• Java
• Applescript
• Produce project di molti tipi:




• Permette la compilazione su più macchine, in rete. Grazie a Rendezvous, (sotto linux direste: IP zero config) ogni CPU in rete può chiedere e/o fornire potenza di compilazione.
• Zero Link: una tecnica di ottimizzazione del linkaggio che annulla i tempi di relink se si modifica il codice sorgente dentro il debugger: l’exe è istantaneamente rigenerato e rilanciato.
• Usa l’ottimo gcc 3.3 per generare codice per i linguaggi derivati da C già citati.
• Contiene l’ottimo Iterface Builder per costruire interfacce utente. Se scrivete in Cocoa, potete "importare" le classi cocoa dentro IB: IB vi farà vedere i metodi e i data member: lì decidete come collegare Action (interazione con l’utente) a Metodi e Metodi a Outlet ( riferimenti a "campi" dei dialog).

 

XCODE: impressioni d’uso

Lo uso da ormai 2 anni. Le prime versioni erano un po’ "ruvide", l’ambiente non era perfettamente omogeneo. Talora il debugger tracciava su linee di sorgente errate. La versione attuale mi pare proprio professionale.

Notate che per un uso serio dovete avere (obbligatorio al 90%):

1. un monitor almeno 17". (io uso Apple Cinema Display da 22 pollici e le varie finestre mi stanno tutte, insieme alle finestre della applicazione da sviluppare)
2. una macchina recente e decente con un po’ di Ram: il Bi-pro è d’obbligo. Io Uso il G5 Bi pro 2 Ghz. Quando il gcc compila, lo sforzo è enorme: entrambi i processori pompano al 90% e le ventole del mio G5 vanno a palla (nei G5 tutta la parte di energy saving e ottimizzazione delle performance è regolata da un’unica logica). Se usate un iMac potete scrivere piccole applicazioni, ma resteranno un-debuggabili, a meno di scrollar finestre continuamente ed attendere 10 secondi che appaia la vs applicazione.

Xcode: confronti

Confrontiamo Xcode con il "nemico": MSVC 6.0 sotto Windows (non ho paragonabile feedback su dot Net, anche se lo ho usicchiato).

Molte cose sono simili: syntax coloring, scorciatoie utili, ottimo debugger, ottima e produttiva integrazione fra interfaccia e codice. Ho usato per anni MSVC 6.0 e lo ritengo molto bello, utile, produttivo.

Direi che Xcode non è da meno: i tool sono ancor più raffinati.

Ritengo più veloce la integrazione fra codice e interfaccia in Xcode, meno confusiva di quella di MSVC, dove ho ancora da gestire #define.

Forse MSVC chiede meno Hardware per funzionare.

Li ritengo due ottimi tool di programmazione, soprattutto efficienti e produttivi.

Quando passo a php e devo debuggare con "echo" mi vien male..