Syvo3

Ho pensato per un po’ se far uscire questo post anche su PlanetKDE, però poi ho optato per l’italiano e per la stretta cerchia di lettori “nostrani”, ed è perciò a questo pubblico che rivolgo i miei 2 cents sul dibattito Mono.

Premessa doverosa: non intendo soffermarmi sulla questione etica, che è stata sicuramente mitigata dagli ultimi accordi di licenza by Microsoft, e che comunque non mi trova del tutto d’accordo con RMS (che, ripeto, per me continua ad essere troppo estremista, il mondo non è bianco o nero).

Da un punto di vista di sviluppatore, mi infilo alla grande nel dibattito Banshee vs. Rhythmbox, ripreso anche su Pollycoke, forse uno degli eventi maggiormente scatenanti le polemiche: in pratica, Canonical vuole sostituire al secondo il primo nella prossima edizione di Ubuntu, sostanzialmente droppando lo storico riproduttore di Gnome ed aumentando perciò la propria dipendenza da Mono, questo quando altre distribuzioni invece cercano di liberarsene.

Ora, io non sono mai stato un utilizzatore di nessuno dei due, dato che mi piace Amarok e lo uso a prescindere dal Desktop Environment che ho attivo in quel momento; sottolineo che entrambi i programmi hanno due interfacce estremamente simili, quindi un utente dell’uno non credo possa essere completamente spaesato nell’altro, e sono comunque convinto che chi utilizza Rhythmbox continuerà ad usarlo a prescindere da che programma sarà di default, anche perchè si potrà installare quest’ultimo giusto con i soliti due click. Mi è anche difficile sparare su Mono, dato che uso ormai da 3 anni Tomboy, e non lo cambio neppure ora che sono fisso su KDE, più che altro perchè ho ormai più di 300 note, e voglia zero di dover creare uno script apposito che mi trasferisca tutta la history in un altro framework analogo.

Da un punto di vista di sviluppatore, bè non posso che approvare la scelta: sono ormai un paio di mesi che sviluppo in C++ per il GSoC, ed intendiamoci, questa non è certo una critica (o uno sputare nel piatto dove sto mangiando quest’estate), ma rimango comunque alquanto interdetto dal fatto che siamo costretti ancora ad usare C/C++ per produrre non dico programmi dalla grafica 3D spinta, o dalla gestione di dati sconfinati, ma per produrre un’interfaccia grafica standard e funzionalità direi “normali”.

Per un programma di riproduzione multimediale, obiettivamente, uno sviluppatore non può dover trattare ancora con la gestione della memoria, non nel 2009, per il semplice motivo che è assurdo dover stare attenti a dove eseguire i delete o le free per evitare dangling pointers, o utilizzare compilatori sostanzialmente lenti (Banshee lato C# si compila in 2 minuti, serve quasi quasi di più per i wrapper in C verso le librerie multimediali) e che producono errori non certo sempre comprensibili.

Ammetto, ad esempio, che la mia esperienza con C++ non è così vasta, e che giorno dopo giorno imparo dai miei errori ed evito di combinare guai con le mie librerie, certo è che ho perso tre ore per un’istruzione non funzionante in una classe (quando in un’altra classe sostanzialmente identica non dava problemi), per poi scoprire che mancava un’include, e naturalmente l’errore non faceva certo percepire che il problema potesse vagamente essere questo; oppure la possibilità di passare i parametri per riferimento in due modi diversi, che naturalmente devono essere gestiti in modo diverso, o la quantità di combinazioni della parola chiave “const” che si possono utilizzare…

Quando il mio progettino sarà finito, inoltre, dovrò dare un giro di Valgrind, per verificare di non lasciare memoria occupata per niente, quando in linguaggi come Python, Java, C# questa è una cosa assolutamente inutile, dato che non dipende più da me.

Insomma: i framework Qt e GTK sicuramente aiutano e tolgono parte del peso dalle spalle dei programmatori, ma secondo me dovrebbe esserci sempre più la nascita e lo spostamento di sforzo di sviluppo dai linguaggi usati oggi a quelli che potremmo considerare sostanzialmente moderni, dato che il livello di prestazioni è sostanzialmente identico e la manutezione e lo sviluppo discretamente semplificati.

Read Full Post »