Friday, 29 October 2010

iPhone SDK Troubles - UIPageController

«I'm sorry if yesterday I didn't post anything, but I was busy. I did first shoots of my first movie with friends of mine, Fabio and Tommaso. We worked well for this project and they gave me their enthusiasm and their grit. Soon I'll show you something about this new job»

«I'm sorry Dave, I'm afraid I can't do that»
First article of my «iPhone SDK Troubles» serie. Today I'll talk about a annoying problem: the impossibility to customize the look of a UIPageController.
Problem is simple: I want to change background color and dots on a UIPageControl. As far as I know, after long search, there's no a way approved by Apple to change UIPageControl dots. This means you can still change their look (on this article there's the explanation), but the application could not be approved in the App Store.
You can still change the background in two way:

  1. if you just want to change the background color, just set it on Interface Builder
  2. if you want a background image, place a UIImageView under the UIPageViewController and set its background with opacity at 0%
I think it's ironic I can change the background and no the dots. They're always white, so a light background make them invisible. I hope in Apple they consider to add an API to manage them.

Wednesday, 27 October 2010

Gosling's Reply

«Ok guys... I've something to say...»
James Gosling is one historical True Hacker. He's famous for his version of EMACS (Gosmacs), for its work at Sun Microsistem and to be known as "Java's Father". Soon after Sun aquisition by Oracle, Gosling resign, because he didn't like Oracle's politics.
Yesterday (october 26 2010), I read from an italian site Gosling's reply to Steve Jobs' declaration about Java remotion from the new Mac OS X (Lion). Googling a bit, I found the original article  at Gosling's blog.

In few words, Gosling said that if Apple is going to remove Java is because Apple wanted to write on their own the official Mac OS X JRE, compliant to Sun's standards. Apple's programmers worked hard and well, but some old design decisions make development a hell. Simply it's hard to continue to support a full Java implementation. Apple has lost interest on Java in a moment where its Macintosh starts to increase in popularity together with its development platform (Objective-C and Cocoa).

Gosling also accused Apple to say a lie when Jobs declare that «Sun (now Oracle) supplies Java for all other platforms». As I said before, there's no version of Java for Mac OS X on Oracle's site.

What to say about? If Apple supported its Java Runtime was mainly because they belived it would become the standard client platform (in a era when converting applications from Windows to Macintosh looks improbable). When Macintosh became more widespread (since 2002), Apple's forces on their Java Runtime were moved elsewhere.

But the Apple development model for Java was right: a JRE wrote from the same software house who write the OS as part of a stack wich starts from hardware, proceed to kernel, continue with OS's APIS and ends with an optimized virtual machine and a well integrated classpath. Apple followed this road, giving us the fastest and best integrated Java experience. Microsoft did the same, but soon started to change some features of Java, making Java programs written on windows incompatible with other Java implementations (who said Embrace, Extend, Extinguish?). Maybe, if Sun would has thought seriously about a politic of openess in Java development (maybe involving IBM and Oracle to define Java new features, standards, ecc.), we would have a Java Kernel, a small and efficient JRE (just 3 Megabyte), a more efficient Java GUI (a DirectX-based Swing? Something similiar to SWT?) and a set of tools to deploy more easily a Java application (Java jar could appear as a Setup.exe on Windows, a .DMG in Mac OS X, a .deb on Debian...).

Let's think about Android: Java is Android's standard development platform. If you look where are located Android applications you'll see the "ideal" situation I described.

Android's architecture. Runtime have the same role of JRE
Unluckly, on desktop systems, a Java client means less differences among various platforms. Can you realize what this means for a market where you want to gain monopoly?

Yeah, you know the answer.

Tuesday, 26 October 2010

HipHop: emotions no-stop

Mhh... there's something strange....

Some months ago, Facebook annunced its new "HipHop" technology, used to speedup its servers. HipHop is a translator: when a page is requested for first time, HipHop transforms PHP source code in to a C++ source and then compiles it into native code with g++.The executable then is launched:its output is passed to the webserver.
Haiping Zhao, senior engeneer and HipHop chief, said HipHop speeds up to fifty percent Facebook servers. No bad, really. So, will we start to develop with HipHop in mind? I don't think so.

HipHop born with a specific target: to increase performances of one of most visited sites on earth. But, after thinking about it for some weeks I realized that better solutions could exist. Assuming as fundamental requisite that is impossible to rewrite ALL Facebook in another language and that most of programmers involved knows only PHP we can:

   1. write a PHP-to-Bytecode interpreter. JVM on server side is great: it's scalable and it has a JIT.
   2. create a front-end to LLVM. LLVM is a Virtual Machine AND a compiler. Apple is founding LLVM project, probably to use it as default compiler for its systems. LLVM supports multithreading.

HipHop technology seems to me as a return to the CGI. After ten years of mod_php (created to avoid CGI), Zope and other ways to reduce the use of CGI, we return to the root of web programming.

In my humble opinion, HipHop looks like more as a "patch" than an "entire solution". Facebook's engineers know well their work and they developed Cassandra DB from ground to up. A great work, well designed and well implemented (Java for scalability and fault-tollerance; replication; choice of a non-relational schema, ecc.). It sounds strange that Cassandra and HipHop came from the same home, because they seem too different. I think Apache Foundation is more coherent: Apache developers work on server-side with Java, with some exceptions in client and C/C  (such as Xerces and log4cxx).

I have no doubts that Facebook's administrators know well what's better for their business and I have no doubts they studied with attention to choose the best solution for their problem. But their solution seems very strange to me, and I would like to understand why they choose to create HipHop.

Monday, 25 October 2010

There's no lions in Java

Alea iacta est

Just after a week of blogging, I decided to start writing in english, to expand my user base. It's a hard decision, because this means to face my ability with this language. But I decided: there aren't more excuses to don't write in english. If I'll do a mistake, I'll learn from it and I'll continue to write my opinions on computer-science and cinema.

Today I'll talk about new Mac OS X (Lion) and its new features: in the last "Mac Event", Steve Jobs presented the Mac App Store (interesting), full-screen applications (less interesting), Mission Controll (a enhanced Exposè), Launchpad (a way to visualize your applications) and... Java remotion.
Well, it's no completly correct: Java now it's "just" deprecated and this means, sooner or later, Mac OS X will be shipped without a pre-installed JVM. This means all Mac users will have to download and install a Java Runtime Environment, exactly as for Windows or Linux.
Jobs justifies this decision saying

«Sun (now Oracle) supplies Java for all other platforms. They have their own release schedules, which are almost always different than ours, so the Java we ship is always a version behind. This may not be the best way to do it.»

Well, looking on Oracle site I see there are JVM just for Linux, Solaris and Windows; FreeBSD have a Java package on its repository of "BSD Ports".
If you can get it for BSD, you can get also on Mac OS X. In worst case, we can compile it from source code (Java is released under GPL).
But tell me the truth: do you really feel the lack of Java on your macintosh? It's about a five months I don't use Netbeans on my MacBook Pro; I haven't installed yet Vuze (Transmission works well too); Runescape... maybe one day I'll play with it.
I said on a precedent post Java habitat is on the server side: clients use AJAX and Flash when you're on web-context; they use C/C++/ObjC on heavy client applications; they use Python, Ruby and Visual Basic for non-intensive CPU applications.
Java on Mac OS X was a wonderful idea, and was the ONLY version of Java shipped on a successful desktop system. The lack of real useful client software was tolerated too long. If Oracle is really interested on Java client, then it must to redesign Java to transform it on a fast, comfortable and elegant development platform.
And if you are concerned about the fate of fussy Macintosh sysadmins, don't panic: they're "pro" enough to install a java runtime environment by themself.

Friday, 22 October 2010

Aggiungi un posto a Valaram?

Ulmo, Vala delle Acque (disegno di John Howe)
Per chi segue il mondo dell'open-source o anche solo quello della programmazione, ricorderà sicuramente il putiferio nato quando alcune distribuzioni iniziarono ad installare di default il framework Mono. La scelta fu ferocemente contestata: il fatto che Mono sia ispirato al .NET di Microsoft  e che, secondo alcuni, ci fossero dei "problemi di licenza", spinse diversi utenti ad alcune iniziative un po' esagerate, tra cui la reimplementare in Java o C++ dei programmi «colpevoli» di essere stati scritti utilizzando Mono (come F-Spot e Beagle)
I più moderati, però, sapevano bene come mai era stato scelto Mono per la scrittura di alcune applicazioni e i motivi erano gli stessi per cui Microsoft realizzò il framework .NET: ossia la possibilità di includere interi pezzi di altri programmi con una facilità estrema: potete includere Firefox come browser nella vostra applicazione usando un import e un Firefox f=new Firefox(). Niente male, eh? E questo può funzionare anche per altri programmi, come Evolution, Pidgin, Nautilus, fogli di calcolo, database ecc. Il motivo per cui si iniziò a lavorare con Mono è questo ed è lo stesso che prima ha spinto gli ingegneri di Microsoft a progettare .NET.
La scelta può essere discutibile, ok. Ma continuare lo sviluppo di Gnome non è facile e non si risolve con prese di posizione "a priori" o coding selvaggio in C++.
Un team separato di programmatori, però, ha iniziato a lavorare in maniera parallela al problema e ideò un altro linguaggio di programmazione,pulito come Java, veloce come C++ e integrato con il sistema a oggetti GObject di Gnome. Il risultato si chiama Vala, ossia "Potenza" e termine generico con cui vengono indicati gli dei presenti ne «Il Silmarillion» di Tolkien.

Io per primo ero dubbioso sulle capacità di questo linguaggio, specialmente per la sua toolchain che, son sicuro, vi farà inarcare il sopracciglio: il programma scritto in Vala viene letto dal compilatore: questo, anziché trasformarlo in codice macchina, lo trasforma in codice C che viene poi compilato dal buon vecchio gcc. Non è poi così strano: i primi compilatori C++ funzionavano esattamente così.
La scelta di creare un nuovo linguaggio non è da prendere a cuor leggero, specialmente in un'era dove se ne possono contare almeno otto di veramente utilizzati e all'epoca liquidai Vala come «l'idea scema di quattro geek»
Invece, contrariamente alle mie previsioni, scopro che Shotwell, il nuovo gestore di foto di Ubuntu, è stato scritto in Vala. E non solo: altri progetti interessanti del gruppo Yorba sono scritti in questo nuovo linguaggio. Pare, insomma, che «l'idea scema» tanto scema non fosse.

Che Vala possa occupare il posto di Mono in Gnome? Potrebbe essere interessante. Che possa cambiare qualcosa nel panorama della programmazione in generale? Improbabile, visto che è pesantemente basato su GLib e GTK; inoltre non sarebbe portabile a livello binario, poiché essendo compilato in codice macchina con gcc.
Sul suo futuro non so davvero cosa dire se non un "staremo a vedere". Però, sicuramente, prima o poi Vala dovrà fare i conti con un linguaggio che concettualmente gli somiglia e che è finanziato dal "solito noto". il linguaggio è Go; il finanziatore Google.

Thursday, 21 October 2010

Intanto, nell'isola di Java....

Il garbage collector osserva attento l'heap di sistema
Apparso nel 1995 col motto di «write once, run everywhere», Java s'è diffuso in diversi dispositivi, con fortune alterne: sui telefonini ha avuto un timido successo eclissato dalla corazzata Android; sui client lo usano pochi coraggiosi e gli sviluppatori che utilizzano Netbeans; le celebri Applet son morte attorno al 2001.
E su server? Beh, Apache Foundation lo usa per praticamente per tutti i suoi progetti; IBM e Oracle lo usano come base delle loro soluzioni software.
Insomma, un successo o un flop?
Dipende. Che Java sia usato è indubbio (i numeri ci sono), ma la destinazione è completamente diversa da quella prevista: nato come piattaforma per i client, Java ha successo solo nell'ambito server. Se pensate a quali sono i VERI programmi client Java, quelli che si usano seriamente, cosa troviamo? Eclipse, Netbeans, Vuze e Runescape. Programmi belli e potenti, ma troppo poco per parlare di un successo. Dal lato server, invece, cosa vediamo? Dando una sbirciatina al sito della Apache Foundation trovo:
e un'altra decina almeno di progetti open che, nel 90% dei casi è scritta in Java.

La celebre Java Virtual Machine
"Java" è il nome "ombrello" sotto cui son raccolte tre cose:
  1. un linguaggio
  2. una Virtual Machine
  3. il classpath (la libreria standard)

La Scimmia Cattiva odia la JVM
 Il linguaggio e il classpath sono apprezzati e ammirati, tant'è che Android usa come piattaforma di sviluppo il linguaggio Java e il classpath reimplementato da Apache (progetto Harmony). Ma se chiedete a uno sviluppatore cosa non gli piace di Java, egli punterà il dito contro l'odiatissima Java Virtual Machine. Nessuno ha mai avuto difficoltà a SCRIVERE un programma in Java, ma quasi tutti si son lamentati della velocità di esecuzione.
In realtà, una volta avviata, la Virtual Machine realizzata da Sun (nome in codice "Hotspot") lavora discretamente bene, con prestazioni generalmente non distantissime a quelle C++, grazie soprattutto alla presenza del JIT. Dai benchmark ricaviamo che i calcoli trigonometrici sono ancora molto lenti, quindi eviteremo di usare Java per applicazioni di calcolo scientifico.
Però vediamo cosa dicono i benchmark di Jake 2, una reimplementazione in Java del motore grafico di Quake 2. Sembrerebbe che Java ne esca con le ossa meno rotte del previsto rispetto al C/C++ dal punto di vista della velocità. Davvero non male, visto e considerato che si può stimare che il codice sia almeno del 20% meno complesso (niente header files e niente puntatori).
Un altro articolo interessante è fatto da uno degli sviluppatori dell'Irrlicht Engine: questi ha scritto un'interessante analisi sulle differenze tra Java e C++ per vedere se poteva essere conveniente scrivere un mototre grafico per la piattaforma di Oracle. I risultati, come dice lui, danno C++ vincitore «anche se Java gli si è avvicinato»; l'autore considera anche che, ricorrendo a ottimizzazioni qui e là, si possono rovesciare i risultati a favore o a sfavore di uno o dell'altro linguaggio; inoltre (onesto e imparziale) ammette che probabilmente i calcoli sarebbero stati più favorevoli per Java se non avesse considerato il tempo di avvio della Java Virtual Machine e avesse utilizzato l'ottimizzazione -server per fare le prove. Le sue conclusioni le trovate sul link che vi consiglio di leggere perché è scritto bene: quel che volevo mostrare è che tutto sommato, le differenze di velocità in esecuzione son sicuramente migliorate.

Alla SUN facevano i server (e si vede)
Sun Microsystems era celebre per i suoi sistemi server di cui curava tutto: il processore (lo SPARC) era progettato da loro; il sistema operativo (Solaris) idem; il sistema di condivisione di file in rete (NFS) l'hanno fatto loro. Insomma, quando si trattava di server, la Sun sapeva perfettamente il fatto suo. E lato client? Non conoscete CDE, NeWS o il progetto Looking Glass? Guardateli bene e forse li troverete familiari. Forse perché
  • le idee di CDE sono riprese e migliorate dal desktop environment XFCE, uno dei più famosi nel panorama open-source.
  • il funzionamento di base NeWS è molto simile al window manager da Mac OS X (che usa PDF anziché postscript)
  • Looking Glass sicuramente ispira uno degli ultimi brevetti registrati da Apple sulle interfacce utente
Insomma, grandi idee, ma forse gestite male. Dopotutto Sun faceva i soldi con i server e l'assistenza. Nel 1993, l'anno in cui si inizia a pensare a CDE, Microsoft stava diventando il colosso che noi tutti conosciamo e Apple, anche se in cattive acque, aveva comunque un nome con cui fare i conti. Questa mentalità da "progettisti software" si riflette anche sulle interfacce utente per la piattaforma Java: se guardate la documentazione di Java2D, vedrete che questa ha una ricchezza e una varietà di classi e di funzioni da far impallidire chiunque; se guardate come è progettata Swing vedrete che è ingegnerizzata così bene che è possibile integrare routine OpenGL come icona di un bottone (guardate qui).
Tecnicamente si tratta di cose impressionanti, ma se lanciate un programma grafico che usi Swing noterete una lentezza imbarazzante (forse Netbeans è l'unico che si salva); se avete programmato con Swing conoscerete bene l'inferno dei suoi layout. Se poi realizzate che abbiamo dovuto aspettare il 2008 e Netbeans 6 per avere un editor delle interfacce visuale (Matisse), quando Mac OS X, Windows e QT ne hanno avuto uno fin dal loro rilascio, non vi stupirete di sapere che Swing lo usano quattro gatti.
Alla Sun, evidentemente, avevano la passione per le interfacce testuali.

Facciamo un server
Se provate a scrivere un server multithread in Java avrete una gradita sorpresa: con meno di cento righe di codice sarà pronto un echo server funzionante che gestisce eccezioni e timeout. Impegnandovi potete fare un server IRC discreto in mezza giornata. Non dovrete preoccuparvi dei memory leak, sarà affidabile grazie al tanto bistrattato garbage collector (sapete che potete sceglierne sei a seconda delle esigenze?). Se poi il vostro hardware non regge e volete affiancarlo con un altro, non dovrete reimplementare niente: la JVM è scalabile, ossia sa bilanciare automaticamente il carico in maniera trasparente. Nel calcolo parallelo c'è il problema delle sezioni critiche; se in C o C++ bisogna ricorrere a semafori o mutex e fare un attentissimo debug (con più thread/processi è più difficile ricreare le condizioni di errore) in Java basta chiudere la sezione critica in una classe che abbia i metodi specificati con synchronized e il problema è risolto.

Il Domani dell'Isola di Java
Dal 1995 di strada ne è stata fatta e di cose ne sono cambiate: il grunge non va più e internet è in tutte le case. La rivoluzione client promessa da Java è stata fatta prima da Flash e poi da AJAX e Sun ha pagato le sue sviste venendo assorbita da Oracle.
La piattaforma Java è ancorata ai grandi server aziendali che devono macinare migliaia di richieste su più macchine, in maniera affidabile e scalabile. Il database NoSQL Cassandra ne è l'esempio perfetto. Ci sarà sicuramente qualcuno che continuerà a far programmi client in Java, ma piattaforme alternative più comode come Python e Ruby probabilmente gli saranno sempre più preferite. Android, che pure usa il linguaggio e il classpath, sicuramente non rifiuterà in un prossimo futuro interpreti python ottimizzati e, magari dotati di JIT.
Non sono in grado di fare previsioni: molti sistemi bancari usano Java come backend e difficilmente abbandoneranno anni di sviluppo e di test in favore di qualcos'altro (un fenomeno simile c'è in ambito scientifico con il Fortran). Tutto è nelle mani di Oracle e, in parte, della comunità Java: a loro il compito di rendere l'isola un centro frequentato, un parco naturale o una riserva.

Wednesday, 20 October 2010

La trappola del C++ (quarta parte)

Bjarne Stroustrup, l'autore del linguaggio C++
Nei precedenti post ho illustrato le difficoltà che possono emergere dall'uso del C++ e gli eventuali correttivi. Nell'ultimo post avevo accennato alla domanda «ma abbiamo ancora bisogno del C++?». Contrariamente alle previsioni, la mia risposta è «si, ne abbiamo ancora bisogno», ma con le dovute attenzioni.
Lo scopo dei miei post non è mai stato denigrare il linguaggio di Stroustroup, ma sottolineare come alcune posizioni di principio facciano più male che bene.
Pensate a un programma come Gwibber: è un programma di microblogging che aggiorna il vostro stato su Facebook e su Twitter (lo facesse anche su Google Buzz sarebbe perfetto); è veloce e pratico. In che linguaggio è stato scritto? In Python puro, con le interfacce grafiche fatte con le GTK+ per integrarlo nell'ambiente Gnome. Avrebbe avuto senso scriverlo in C++? Non penso. Non ne vedrei l'utilità. Il programma funziona e fa quello che deve fare senza rallentamenti né noie.Avremmo aumentato il numero di righe di codice (sicuramente di un buon 30%) per guadagnare qualche millisecondo che, per quello che deve fare Gwibber, sarebbe stato inutile.

Ma me serve il C++!
Analizziamo, invece, Vuze, noto client BitTorrent. Lo uso spesso, funziona ed è ricco di funzionalità. E' scritto in Java e su un sistema un po' datato non da un'esperienza utente particolarmente gradevole. Varrebbe la pena riscriverlo in C++? Non saprei, ma sulla pagina wikipedia dedicata ai client bittorrent ne trovo almeno tre (uTorrent, Opera e KTorrent); altri sono scritti in Python; uno solo in C#. Evidentemente Vuze non è particolarmente amato dall'utenza.

Mettiamo a confronto due programmi simili, ossia due motori 3D: il Source della Valve e l'Unreal Enginedella Epic Games. Non ci sono storie: entrambi DOVEVANO venir scritti in C++ (persino John Carmack, il programmatore eroico che ha scritto Quake 2 in puro C, per Quake 3 s'è votato al C++) perché un motore grafico 3D ha bisogno di
  1. Massima velocità di esecuzione, perché qualche millisecondo può far la differenza
  2. Alto livello di astrazione, visto l'alto numero di entità coinvolte
  3. Contatto il più vicino possibile con l'hardware della macchina
  4. Rispetto delle deadline nel contesto realtime
Python non è in grado di far questo e Java nemmeno. In questo contesto il C++ è davvero l'unica scelta praticabile. I programmatori dell'Unreal Engine, però, si son dimostrati più furbi di quelli di Valve. Unreal Tournament 2003 è stato fin da subito disponibile per Mac OS X e GNU/Linux, mentre Source no. Come mai? Alla pagina di wikipedia c'è la spiegazione, ma se siete stati attenti negli articoli precedenti avrete già indovinato. A un engine di base fatto in C++ facilmente portabile, i programmatori di Epic hanno agganciato un motore di scripting (UnrealScript) che gestisce tutta la logica di gioco. Per loro è "bastato" (le virgolette sono d'obbligo) riscrivere alcuni blocchi di basso livello (routine grafiche,audio) per trasferire un intero gioco su altre tre piattaforme. Source, invece, ha tutti i plugin scritti in C++ e compilati all'interno del motore. Fare una modifica su un programma del genere (in questo contesto ci aggiriamo facilmente sulle 20.000 e più righe di codice) non è assolutamente un lavoro da poco.

La Valutazione dei Requisiti
Sul famoso racconto «La notte che bruciammo Chrome», William Gibson racconta la storia del miglior colpo fatto da due hacker: questi due vivono in condizioni economiche pietose e vogliono fare "il colpaccio". La svolta avviene quando uno di loro scopre che un misterioso cubo comprato al mercato nero è un sistema di intrusione informatico pensato per i militari. Ma, anzichè esultare, il personaggio dice

«Mi sentivo come il ladruncolo che scende in strada per comprare un coltello e torna a casa con una bomba a neutroni. Tombola. Cosa te ne fai di una bomba a neutroni in una rissa di strada?»

Riuscite ad afferrare l'analogia? Il C++ è la bomba a neutroni. E' vero che col C++ si fa tutto, ma pochi ci mettono davvero la testa quando programmano in quel linguaggio. Provate a pensare ai programmatori C++ che conoscete e chiedetevi:
  • quanti hanno parlato di aver scritto una classe String più efficiente?
  • quanti hanno detto di aver pronta una personale libreria di template?
  • quanti hanno scritto delle classi per la gestione delle strutture dati comuni (vettori, liste)?
  • quanti hanno riempito di cout<< i loro programmi?
Ora, per contro, pensate a quanti
  • hanno scelto un motore di scripting interno?
  • hanno fatto una valutazione dei requisiti?
  • hanno calcolato le deadline del programma?
  • hanno utilizzato lo GNU debugger?
  • hanno utilizzato software come Valgrind?
  • hanno utilizzato le librerie QT?
Qui son stato volutamente provocatorio, ma il senso è chiaro. Molti decidono di programmare in C++ per partito preso, senza considerare se hanno davvero bisogno dell'astrazione, della velocità (e delle difficoltà) proprie di questo linguaggio. Lanciano allegramente g++ senza riflettere seriamente su debug, gestione della memoria, portabilità e su tutti i problemi di cui ho parlato. E' un po' come vedere il ladruncolo che armeggia con la bomba a neutroni dicendo «funziona meglio di un coltello, ne minacci di più e so perfettamente come funziona»

Pensare a un roguelike
Agband (immagine hostata da Wikipedia), uno dei roguelike più famosi
Faccio un altro esempio: provate a progettare (solo progettare) un gioco sullo stile di Angband. Questo tipo di giochi si chiama roguelike e sono degli RPG, generalmente basati sul regolamento di Dungeons and Dragons. L'interfaccia, come vedete, è scarna da far paura: è un'interfaccia a caratteri che usa i caratteri come tiles e come sprite.
I requisiti di questo nostro roguelike sono:
  • mappe caricate da file (non è molto "rogue", ma è per semplificarvi la vita)
  • movimento all'interno di mappe più grandi dello schermo
  • salvataggio e caricamento delle partite
  • gestione delle caratteristiche del personaggio
  • gestione degli oggetti di gioco (armi, cartelli, pozioni, ecc.)
  • Intelligenza artificiale dei mostri
 Provate a pensare a cosa significherebbe programmarlo in C++ su Ubuntu. Terminatolo, provate a pensare di farne la conversione in C++. Pensate a come evitare i memory leak e le ricerche fuori da un array. Pensate a riscriverlo in un altro linguaggio (Java, Python, Ruby... fate voi). Vi garantisco che le performance non se risentiranno, ma il tempo di sviluppo si (e anche tanto).

La Conclusione
Il C++ è nato con l'obiettivo di aggiungere le classi al linguaggio C mantenendo alta la velocità di esecuzione e la compatibilità con l'illustre predecessore. E' stato impiegato in quasi tutti i grandi progetti software dal 1995 in poi (Autocad, Quake 3, KDE...) e i suoi meriti sono indubbi.
Lo scopo di questa serie di articoli non è mai stato dire "il C++ fa schifo", ma invitare chi inizia a fare un progetto a chiedersi se valga davvero la pena affrontare anche tutte le problematiche che lo sviluppo di un programma C++ richieda.
Se poi i requisiti sono tali per cui  non si può davvero fare a meno del C++, è stata mia intenzione rivolgere l'attenzione del lettore al debugger, uno strumento utile che viene sottovalutato in diversi ambienti, ma che è un compagno inseparabile di chi lavora con i linguaggi compilati.
Del C++ non ci si sbarazzerà facilmente: la sua ubiquità, velocità di esecuzione e astrazione sono necessari in una miriade di contesti (videogames, sistemi realtime, controlli hardware, ecc.): ma la presenza di altre soluzioni software (Python, Ruby,Java) deve spingere lo sviluppatore a fare delle buone analisi e vedere cosa effettivamente vuole ottenere.
Analisi, pochi pregiudizi e attenzione.
E buona programmazione!

Un paio di link utili come spunto per ulteriori riflessioni
 All'anonimo autore del "provocatorio" commento (che ho apprezzato ;) ) dico che mi ha dato una bella idea per un prossimo post su Java.

Tuesday, 19 October 2010

La trappola del C++ (terza parte)

Nel procedente post ho mostrato come scrivere un programma in C++ che soddisfi il requisito della portabilità sia un compito più arduo di quanto si possa credere. Tuttavia molti programmi (come Blender 3D e Mozilla Firefox) sono stati portati con successo su diverse piattaforme.
Il segreto di questi programmi è relativamente semplice: i programmatori hanno costruito una solida e veloce base in C++ cui hanno agganciato l'interprete di un linguaggio di scripting (python nel caso di Blender 3D e XUL per tutti i prodotti di Mozilla). Una volta testato che la base C++ è robusta, tutto il resto è script. Se una funzione è troppo lenta la si riscrive in C++, ma tutto il resto rimane immutato e funzionerà su qualsiasi piattaforma. Se c'è un errore nella logica di programma probabilmente è all'interno di uno degli script: in questo caso è molto più comodo correggere uno script, piuttosto che ricompilare qualche mega di sorgente, non trovate? Lo stesso dicasi nel caso si voglia aggiungere una funzionalità: si scrive un file e lo si sposta nella cartella degli script.
Nel mondo dei videogame c'è un illustre esponente di questa tecnica: Quake 2, che John Carmack scrisse in puro C e che dotò di un motore di scripting scritto apposta per tutta la logica di gioco.
E nel free-software? Qualcuno conosce un altro programma che segua questa filosofia? Un applauso per chi ha detto EMACS.

fig 1
A questo punto dovrei parlare della gestione della memoria, croce e delizia del programmatore C.
Qua apro una parentesi di storia personale: spesso ho trovato persone che si son lanciate entusiaste nel famoso discorso "C++ è figo, Java è uno schifo". Di tutti questi, solo uno è riuscito a finire un progetto (circa 10.000 righe di codice) e ha passato le notti sul debugger per trovare le istruzioni delete che mandavano in crash il programma. Questo perché bisogna far ben attenzione a quando invocare una delete.
Prendete, ad esempio, il grafico riportato in Figura 1.
In questo quadro, la classe Camera ha richiesto a MediaCache un oggetto di tipo Image. Per comodità, di questo oggetto abbiamo passato il puntatore.
Immaginiamo, ora, che il programmatore diligente lanci una delete appena Camera ha terminato di usare l'oggetto ImageToDisplay. Il risultato è che anche l'elemento dell'array di MediaCache punterà a niente, con risultati disastrosi (Figura 2).

fig 2
Objective-C risolve il problema utilizzando oggetti che tengono il conto del numero referenze che puntano a essi utilizzando i metodi retain e release. E' molto bello come sistema, e vi consiglio di dare un'occhiata alla sezione sette del Cocoa Dev Central e alla Figura 3.

In Objective-C, si va a liberare lo spazio solo
quando il contatore delle referenze va a zero
Certo, il caso del motore grafico 2D è estremamente semplice e si può facilmente capire cos'è che va storto. Ma provate a fare il debug in un contesto di più seimila righe di codice e perderete sicuramente qualche oretta nel capire come mai il programma da segmentation fault.
Alcuni programmatori C++, sapendo che avrebbero potuto dimenticare qualche delete (in programmi lunghi milioni di righe di codice è una svista inevitabile), risolvevano il problema con un'area tampone d'emergenza, ossia:

  1. All'inizio del programma, come prima cosa, si alloca 1 Megabyte di RAM a vuoto (puntato da char* help_buffer;)
  2. Ad ogni new, si va a verificare che il risultato sia diverso da NULL. In caso contrario, c'è stato un errore di memoria: probabilmente i memory leak hanno saturato la memoria e rendono impossibile qualsiasi altra operazione.
  3. Si dealloca lo spazio puntato da help_buffer. Si libera così abbastanza memoria per resettare tutto il programma e, nel peggiore dei casi, a riavviarlo.
La soluzione è brutta, è poco elegante, ma in contesti critici (server, per esempio) garantisce che il programma continui a girare ininterrottamente. Immaginate un server web che va si pianta una volta al giorno:.i sistemisti non vi ringrazieranno per la straordinaria velocità e vi malediranno per la scarsa affidabilità. Il debug, le limature e la raffinazione del programma si farà poi, la priorità è che il programma funziona ed è affidabile.

Se programmate in C++ non sottovalutate MAI il debugger: è il vostro migliore strumento e più fido alleato. Evitate di ricorrere sempre ai cout<< di variabili. Sono utili per avere il log di sistema e per aiutare voi e gli utenti a fare un bug report. Ma un buon debugger vi servirà a capire precisamente cos'è andato storto: una delete azzardata, una new andata male o una ricerca all'interno di un array vuoto vengono facilmente individuate da un debugger.

Se state programmando in C++, senz'altro avrete bisogno di un debugger. Se state programmando in C++ fate molta attenzione alla gestione della memoria: individuare i memory leak e i crash dovuti a maldestre free è difficile. Se in fase di progetto vi accorgete che il programma inizia ad essere davvero complicato, valutate se è il caso di utilizzare un linguaggio di scripting al suo interno.
Nella prossima parte, concluderò questa serie di articoli rispondendo alla domanda «ma abbiamo ancora bisogno del C++?»
(continua nella domani nella quarta e ultima parte)

Monday, 18 October 2010

La trappola del C++ (seconda parte)

«Non è facile portare un satellite in orbita»
Lo Space Shuttle Atlanits (STS-27)
Immagine fornita da Wikimedia Commons

Sunday, 17 October 2010

E' morto Benoit Mandelbrot

Benoit Mandelbrot su Wikipedia

L'insieme di Mandelbrot su Wikipedia

Articolo su La Repubblica
Apprendo oggi che giovedì scorso s'è spento Benoit Mandelbrot, scopritore dell'insieme che porta il suo nome e pioniere della teoria dei frattali.
Non voglio aggiungere parole: penso che il miglior epitaffio sia esplorare i paesaggi matematici che scoprì per primo e sentire per questo un senso di meraviglia.

Saturday, 16 October 2010

La trappola del C++ (prima parte)

Il titolo è provocatorio, lo dico subito. Se pensate che qualsiasi programma è meglio scriverlo in C++ dimenticate l'esistenza di questo post, visto che vi farà solo venire acidità di stomaco.
Se, invece, siete disposti a in discuterne, mettetevi comodi: ci sarà da divertirsi.

Friday, 15 October 2010

Iniziare con la mia testa

Scrivo il primo post di "The J Head" dedicandomi all'argomento "informatica". Cosa c'è di così nuovo da segnalare da suscitare la nascita di un blog? C'è l'articolo pubblicato su in cui si segnala lo stato di avanzamento del progetto Haiku, un sistema operativo "Free Software" pensato per il desktop.
Haiku raccoglie la tradizione del vecchio BeOS ed è compatibile col parco software dell'illustre predecessore. Haiku non ha un kernel né Linux né tantomeno UNIX e questo rappresenta un'anomalia nel mondo dell'open-source.

In questo periodo, però, dove tutto il mondo corre dietro a Android, Ubuntu e Mac Os X, temo che il povero Haiku avrà vita dura. Dateci comunque un'occhio: potrebbe non dispiacervi.