Ogni tanto mi capita di trovarmi immischiato nella discussione che da anni tormenta programmatori e informatici di ogni nazione ed etnia: meglio usare un linguaggio tipizzato dinamicamente o staticamente?

Senza pretese di scientificità o di dogma o di starvi a rivelare chissà quale verità arcana nascosta, vi dirò la mia sull’argomento. Innanzitutto sappiate che sulla faida statico/dinamico ci sono tonnellate di discussioni filosofiche, euristiche, epistemologiche e tecniche capaci di far impallidire chiunque provi ad avvicinarsi alla questione.

Celeberrimo è il duck test di Whitcomb Riley: “Quando io vedo un uccello che cammina come un’anatra, nuota come un’anatra e starnazza come un’anatra, io chiamo quell’uccello “anatra”". Concetto che i sostenitori della tipizzazione dinamica sintetizzano in: guardate la vignetta precedente, se la scritta vi è stata di aiuto allora la tipizzazione statica fa per voi.

In pratica la questione è prettamente filosofica: l’identità di un oggetto-barra-valore deve derivare dalle sue caratteristiche o da una specifica esterna? Ovvero: un’anatra è un anatra perché vola, nuota, ha le piume, etc… oppure è un anatra perché dico che è un anatra?

Dal punto di vista della rappresentazione della conoscenza possiamo essere d’accordo che un oggetto sia identificato dalle sue proprietà, dal punto di vista informatico invece la questione è più spinosa. In informatica tutto è un numero e i numeri non hanno proprietà per natura bensì caratteristiche che nascono dall’interpretazione che io ne do (tramite l’assegnazione di un tipo).

Ma chiudendo la parentesi filosofica torniamo all’atto pratico: perché dovrei scegliere un linguaggio statico rispetto ad un linguaggio dinamico? Non c’è risposta, serve solo l’esperienza e il gusto personale. Tuttavia negli ultimi dieci anni ci hanno distrutto l’anima raccontandoci che i linguaggi statici (C, Java e compari) erano obsoleti e che il futuro era dinamico. Il risultato di questa campagna è che attualmente abbiamo decine di linguaggi dinamici liberi e di ottimo livello (Python, Ruby, PHP e molti altri) e solo un paio di linguaggi statici decenti. Io, da estimatore dei linguaggi statici, vengo qui per raccontarvi le mie personali considerazioni sull’argomento.

1. Ordine nel caos

Quando mi sono messo ad usare il Python per progetti di media complessità (vedi CobraDraughts) ho sempre avuto l’impressione che tutto era avvolto dal disordine. Il fatto che non bisognava dichiarare da nessuna parte gli attributi di una classe mi inquietava.

Oltre ai miei problemi psicologici però c’era un comportamento oggettivamente fastidioso: presa la classe A non c’era verso dalla classe B di sapere durante la digitazione del codice quali attributi avesse e, soprattutto, di che tipo fossero. Questo perché non esiste nessun tipo associato alle variabili di un linguaggio dinamico!

Questo comporta due grossi problemi:

• Il compilatore è quasi inutile come strumento di correzione degli errori. Se passo una stringa ad una variabile che nell’intero arco della sua vita deve contenere solamente interi non lo vengo a scoprire fino a quando non eseguo quella porzione di codice e il programma muore. Insomma, l’analisi statica del codice è praticamente nulla. Bisogna armarsi di pazienza e code-coverage ed eseguire il codice.
• L’overloading di funzioni con lo stesso numero di parametri è un parto greco. Probabilmente non si usano ma il mio cuore ne ha sofferto.

A me personalmente tutta questa cosa fa sembrare che il programma si regga su un sottobosco di magia che non apprezzo. Inoltre la stretta maglia dei tipi mi costringe anche a strutturare meglio il codice e ad essere più rigoroso nello sviluppo.

2. Prestazioni

Qui c’è poco da fare. I linguaggi statici stracciano spesso e volentieri un linguaggio dinamico sul campo prestazionale, sia per il tempo che per la memoria. Ciò è causato semplicemente da tutto l’overhead necessario a gestire la “naturalissima” dinamicità delle variabili. Per alcune applicazioni ciò non è un problema (anche grazie all’uso di librerie che wrappano codice C) ma per molte altre invece si!

Molti dicono che questo non è un gran problema perché abbiamo macchine sempre più efficienti. Io credo che questo sia come dire che posso ingrassare venti chili perché tanto ho i pantaloni con l’elastico.

3. Didattica

Un aspetto da non trascurare. Quando mi trovo davanti la solita domanda su quale linguaggio sia meglio per cominciare a programmare, sento che molti consigliano linguaggi come il Python perché sono più semplici. Questo è sicuramente vero, la tipizzazione dinamica permette di trascurare una gran parte di aspetti della programmazione, ma mentre ciò può essere buono per chi già programma, a mio avviso, è un problema per chi comincia. Sarebbe come se un maestro di scacchi mi insegnasse a giocare senza cavalli, alfieri e 4 pedoni perché così è “più facile”.

Il risultato di certe politiche è l’inondazione di brutto codice e la prolificazione di programmi orrendamente progettati. Senza contare i bimbominkia del development che vanno in giro a raccontare che “il C è inutilmente complesso e fa schifo” mentre “il PHP ruleggia”.

È quindi importante per chi tiene corsi o si vuole avvicinare alla programmazione senza tutta la vicinanza alla macchina del C, di mantenersi almeno all’inizio sui linguaggi statici (come il Java o il C#) che aiutano a creare quella forma mentis necessaria anche per i linguaggi dinamici.

Inoltre, se ciò non bastasse, è più facile passare dallo statico al dinamico che viceversa. Quindi sul lungo periodo si risparmia anche fatica.

In conclusione: questi sono i motivi per cui trovo molto molto più divertente lavorare con linguaggi staticamente tipizzati rispetto ai linguaggi dinamicamente tipizzati. Non sono leggi assolute e potete benissimo rispondermi che “io col Python ho programmato un AI senziente ed è stato facilissimo”. Ci credo, anche io uso il Python spesso.

Chiudo con una speranza. La speranza che i linguaggi statici vengano riscoperti e portati avanti in modo da avere la stessa scelta che abbiamo oggi con quelli dinamici. Lasciare questo mondo solo al C/C++, allo sgangherato Java e al controverso C# secondo me è una grandissima occasione sprecata.

Fra le parole più abusate su internet un posto d’onore va a programmatore (o developer e varianti). Forse secondo solo a “H4ck3r”. In ogni caso, programmatore fa fico, creare programmi e dire alla gente “questo l’ho fatto io” non ha prezzo.

Ma la realtà è ben diversa. Spesso molti di questi individui sono programmAttori e nulla più. Molti conoscono la programmazione sciamanica, l’arte di scrivere mantra tantrici su dei file .c o .py e passarli ad un compilatore per ottenere qualcosa in cambio. Questa non è programmazione, almeno non al suo livello più nobile. Il web è pieno di questi arroganti developer. Vediamo come disinnescarli.

1 – Programmare non significa assemblare

Se trovate persone che vi propinano programmi scritti da loro il primo modo per verificare la potenza della loro capacità. Verificate il numero di librerie e cosa fanno. Molto spesso troverete programmi assemblati. I programmi assemblati sono i software semplici costruiti a partire da un numero enorme di librerie (che fanno tutto il lavoro sporco) che vengono assemblate dal programmatore. Un esempio di questi programmi sono player musicali o programmi di pulizia del sistema. In realtà tali programmi usano librerie grafiche, librerie audio e collegano il tutto in modo piuttosto lineare.

Questo è essere programmatori allo stesso modo di come cucinare un piatto leggendo una ricetta da un libro di cucina usando prodotti surgelati fa di noi degli Chef.

È una programmazione hobbistica, che ha il suo rispetto, la sua dignità e spesso sforna programmi utilissimi. Ma i programmAttori te lo spacceranno come una meraviglia dell’informatica e pretenderanno, alla luce di ciò, di parlare alla pari con un developer del kernel.

2 – Programmare non significa sapere un linguaggio

Un programmatore non conosce il C, non conosce il Java, non conosce il Python: li conosce tutti. Un programmatore esperto non ha paura di imparare un linguaggio nuovo perché con venti minuti di letta al manuale del linguaggio entra già nel meccanismo. Questo perché sa che cos’è la programmazione al di là del singolo linguaggio, ha appreso i concetti informatici che stanno dietro ai linguaggi di programmazione e sa riconoscerli in tutti i linguaggi del mondo.

Ovviamente sto esagerando, ma un programmatore esperto può semplicemente imparare un linguaggio nuovo in due ore (se rientra nei paradigmi che conosce, altrimenti un paio di giorni).

Il programmatore farlocco invece no. Se gli dici “facciamo un progetto XYZ” non ti dirà di farlo nel linguaggio più adatto allo scopo bensì nel linguaggio che conosce.

Si può essere più programmatori scrivendo in pseudocodice su carta che scrivendo uno script di pulizia in bash.

3 – Programmare non significa fare finestre

Altro comportamento classico del programmatore wannabe è il classificare come più dignitose le applicazioni grafiche rispetto alle applicazioni a riga di comando. Se sentite frasi del tipo “io faccio programmi con le finestre, mica quelle schifezze a riga di comando” accendete l’allarme: è molto probabile che vi troviate di fronte ad un programmAttore montato dei più classici.

Le finestre sono un aspetto (minimale) dell’intera programmazione. Nonostante nell’uso desktop utilizziamo quasi tutte applicazioni a finestra queste rappresentano solo una minima parte del lavoro che milioni di programmatori fanno ogni giorno (ad esempio scrivendo librerie come quelle che loro usano per fare le amate finestre). Quindi scusate se mi innervosisco ma uno che si vanta di fare programmi a finestra invece di altro non solo non è programmatore: è un mentecatto.

Un programma come Gazebo, tanto per dirne uno che sto usando ora, è un programma estremamente sofisticato e complesso dato che serve a simulare insiemi di Robot in ambienti 3d. Eppure è un programma a riga di comando. Il tanto amato dpkg di Debian è a riga di comando eppure svolge tutto il lavoro pesante dell’installazione dei pacchetti.

Inoltre, se vogliamo dirla tutta, la programmazione una finestra grafica non è complessa (in generale), si va dalla quasi banalità del Visual Basic e del Gambas alla media complessità di Gtk e Qt. Saper fare finestre grafiche significa studiare e conoscere bene una libreria fra le infinite disponibili, non conoscere la programmazione nel suo complesso.

4 – Programmare non significa conoscere HTML e CSS

Fra i programmAttori web spesso giara questa balla. Io conosco HTML e CSS quindi sono un programmatore. Sbagliato. Al massimo sei un Web Designer ma non un programmatore.

La ragione è semplice: HTML e CSS non sono linguaggi di programmazione e, se non il presunto developer non sa questo allora è garantito che non è un developer. Essere esperti di HTML equivale ad essere esperti di CSV, LaTex e altre metodologie di formattazione dei dati. Potete fare un ciclo in HTML? No. E quindi non è chiaramente un linguaggio di programmazione.

5 – Programmare non significa scrivere codice

O almeno non significa solo quello. La programmazione è una cosa più vasta di cui lo scrivere codice è probabilmente la cosa più noiosa. L’atto di sviluppare un’applicazione parte da prima, da quando si analizzano gli aspetti di ciò che si vuole fare e si progetta l’applicazione, e arriva fino alla fase di test. È la progettazione soprattutto, la sensazione di analizzare un problema, smontarlo e risolverlo che fa di noi un programmatore. Non ha ancora scritto una riga di codice ma nella sua mente il programma è già scritto e questo, vi assicuro, da una bellissima sensazione.

Il programmAttore invece scrive codice su codice spesso in mega malloppi di file per nulla modulari e invece di lamentarsi di come sta gestendo il suo progetto probabilmente si lamenterà del linguaggio (che secondo lui non permette di fare la cosa X o la cosa Y).

6 – Programmare significa progettare strutture dati

Probabilmente, se non vi siete mai trovati a progettare una struttura dati o almeno a pensare a quale struttura dati sia migliore per la vostra applicazione, non siete veri programmatori. L’unica cosa che fanno i programmi è manipolare l’informazione e l’informazione è manipolata e memorizzata nelle strutture dati. Quindi programmare È fare strutture dati.

Molti linguaggi coprono molte funzioni base. In Python per fare una lista dinamica non ci vuole certo un tecnico esperto, ma per programmi complessi anche il Python necessita di un po’ di progettazione nelle strutture dati (anche solamente organizzare gli oggetti che popoleranno la nostra applicazione).

Tutti i programmatori che conosco e che stimo almeno una volta hanno avuto la necessità di scrivere manualmente una lista, un array, un heap e così via. Anche io ne ho avuto bisogno. Credo che tutti ne abbiano bisogno prima o poi.

Se il vostro interlocutore tentenna sulla struttura firstchild-nextsibling di un albero probabilmente siete davanti ad un programmAttore.

Per concludere. Forse ci sarebbe molto altro da dire e molte altre cose che al momento mi sfuggono ma il punto credo sia chiaro: per chi, come me, ama questa disciplina è fastidioso veder impazzare per il web tanti tromboni che vantano una conoscenza di programmazione accademica e danno la colpa dei loro fallimenti sempre a qualcos’altro. È irritante sentire cose stupide come quelle al punto 3.

C’è chi studia anni, legge libri su libri per apprendere una tecnica, che scrive tonnellate di righe di codice praticamente inutile solo per implementare e mettere a punto una particolare struttura dati o un particolare algoritmo che ha studiato. Poi arriva il ragazzino di turno che ti sbatte in faccia l’ennesimo programma con GUI per pulire il tuo sistema e pretende di parlarti alla pari.

Vorrei che tutti questi individui imparassero l’umiltà e capissero, come me, che abbiamo ancora molto da imparare. Molto.

Nulla è più importante di quello che è racchiuso nelle parentesi graffe. Se dovessi scegliere una frase per descrivere Lua sceglierei proprio questa. Volevo parlarvi di come utilizzare il paradigma a oggetti con Lua ma, rileggendo vari appunti, mi sono accorto che non posso assolutamente tralasciare una parte vitale del linguaggio: le tabelle.

Se in Lisp il tipo di dato base del linguaggio è la lista, se in Python è l’oggetto in Lua è la tabella. Non esiste nessun’altra struttura dati in Lua all’infuori della tabella: niente array, niente vettori, niente liste, solo ed esclusivamente tabelle.

Una tabella vuota si crea in un modo semplice:

Una nota tecnica. Le tabelle in Lua sono anonime ovvero tab non contiene la tabella ma un riferimento ad essa. Infatti se faccio:

Otterrete come risultato 2. Le due variabili infatti si riferiscono alla stessa tabella!

Il modo più semplice per usare una tabella Lua è di usarla come un classico array.

Nulla di difficile. Dovete fare occhio a due cose:

• Il primo elemento di una tabella ha indice 1 (invece di 0 come nel 99% dei linguaggi di programmazione. Non esiste quindi nessun tab[0]
• Non esistono limiti quindi se chiamate tab[-3] o tab[3090] non otterrete nessunissimo errore. Semplicemente queste locazioni contengono il valore vuoto di Lua: nil

Non avete idea di quanti problemi possa causare la numerazione che parte da uno.

Per scorrere tutti i valori di un array definito in questo modo possiamo usare

Il comando ipairs restituisce indice e valore di ogni elemento di una tabella fino al primo “nil”.

Le tabelle Lua però, come potete immaginare, vanno ben oltre il semplice uso come array. Prendiamo questo codice d’esempio:

Prima cosa, le tabelle possono essere indicizzate da qualunque tipo di dato e, in particolare, da stringhe. Questo permette una grande versatilità alle tabelle Lua che diventano, a tutti gli effetti, un dizionario. È possibile cioè usare chiavi generiche per memorizzare gli elementi in una tabella.

Secondo, provate a indovinare l’output dei quattro print.

• Il primo print restituisce "index is 9". Abbiamo scelto di prendere il valore nella posizione indicata dalla variabile x che è uguale a 9.
• Il secondo print restituisce "index is x". Abbiamo scelto infatti di prendere il valore indicizzato dalla stringa “x” (e non dalla variabile x).
• Il terzo print restituisce lo stesso valore del secondo. Questa è infatti una notazione alternativa che permette di richiamare i valori nella tabella indicizzati da stringhe. Potete, ad esempio, chiamare anche tab.slashcode
• Il quarto print restituisce nil. Stiamo cercando di accedere alla locazione della tabella indicizzata dalla stringa “9″ ma non abbiamo inizializzato nessuna locazione con quell’indice!

Come potete vedere le tabelle in Lua sono una struttura dati estremamente efficiente e versatile ma bisogna fare attenzione a non confondersi con gli indici (specie a non confondere indicizzazioni tramite stringhe o tramite variabili).

Le tabelle sono, inoltre, lo strumento principale per implementare il nostro meccanismo ObjectOriented in Lua. Ma questo lo vedremo la prossima volta.

PS: Nulla è più importante di quello che è racchiuso nelle parentesi graffe. In questo caso, nella foto, c’è la mia ragazza ed è veramente la cosa più importante.

C’è un principio molto noto dell’informatica che spesso viene dimenticato dagli sviluppatori tutti. Tale principio recita più o meno così: se una cosa è a 3 schermate di distanza allora non esiste. È un principio basilare nell’usabilità del computer per l’utente medio: se una cosa necessita di più di 3-4 click e si trova oltre i 3 passaggi allora, indipendentemente da quanto sia importante, per l’utente finale, non esiste.

Al riguardo ci sono un po’ di considerazioni da fare.

Perché viene dimenticata?

Il motivo è semplice: i programmi vengono scritti dai programmatori. Non è un gioco di parole, è la verità. Ai programmatori piace la soluzione arguta, l’opzione contorta, l’arzighigolo programmativo. Non possono farci nulla, è più forte di loro. Non di rado quando parli dell’usabilità d’uso di un programma con un programmatore ricevi come risposta cose tipo “vabbè è semplice. Basta che aggiungi /percorso/assurdo nella variabile ENV e avvii il programma con nomeprogramma -opzione1 -opzione2 -opzionen=boh e ottieni quello che vuoi!”. E tutto ciò è normale: se non gli piacessero le cose complicate non sarebbero programmatori.

Tutti se le dimenticano?

No. Ovviamente in molti programmi ci sono persone incaricate appositamente di frenare l’indole complicatrice degli sviluppatori. Ma allora perché troviamo ancora questi grossolani errori? Alcune volte per disattenzione e altrettante per malafede. Un esempio? Le impostazioni della privacy di Facebook. Quanti click servono per arrivarci? Sono tre per visualizzarle e 4 + n per modificarle a piacimento, tutto questo attraversando 2 schermate e un menù piuttosto dimenticato.

Solo malafede?

No. A volte nascondere una possibilità oltre la soglia dei 3-4 passaggi è una “features” che permette allo sviluppatore di evitare la scrittura di complicati meccanismi di blocco, criptaggio, ecc, contando sui grandi numeri.

Un esempio è dato da un applicazione Android per impostare lo sfondo del terminale. L’applicazione da accesso a una sterminata galleria di sfondi ma, ovviamente, non da la possibilità diretta di scaricare tali sfondi. Il motivo è che, giustamente, lo sviluppatore vuole che tu apra il programma ogni volta che vuoi cambiare sfondo: se te li facesse scaricare facilmente l’utente se ne scaricherebbe 30 nel giro di due minuti e poi si dimenticherebbe dell’applicazione!

Tuttavia per impostare uno sfondo è necessario scaricare l’immagine. Come fa il programma? La scarica e la imposta. Quando cambiate sfondo, cancella la precedente e la sostituisce con la nuova.

Ora capirete che è ancora teoricamente possibile scaricarsi 30 sfondi e buttare l’applicazione, basta copiarsi in una cartella l’immagine scaricata ogni volta che il programma la scarica. Ma quanti passaggi necessita? Troppi. Non tanti, ma troppi, più di 3-4. E così statisticamente il 99% delle persone utilizzerà il programma nel modo voluto dallo sviluppatore nonostante sia teoricamente fare diversamente.

Altri esempi?

Google. Fate una ricerca su Google e notate a che pagina desistete dalla ricerca. Sono quasi sicuro che smettete di cercare entro la 3° 4° pagina, se arrivate a 6 siete parecchio insistenti, a 10 significa che siete disperati (come io quando cerco tutorial su roba strana).

Se il vostro blog cade oltre la 4° pagina non esistete. È come se fosse alla pagina 100 mila.

Quindi?

Quindi pensateci. Tutto qui. Se programmate qualsiasi cosa che non sia destinata ad altri programmatori, fate caso a non collocare nulla oltre la soglia dei 4 click/schermate. I vostri utenti ne gioveranno e voi pure.

Se avete visto l’ultimo articolo sui venti linguaggi di tendenza forse avete notato una triste assenza. Nella top-50 infatti manca completamente l’accoppiata Vala/Genie. Se non l’avete notata allora è il momento che vi presenti questi due giovani virgulti.

Chi o cosa sono Vala e Genie?

Vale e Genie sono due linguaggi di programmazione OpenSource ad alto livello ed orientati agli oggetti portati avanti dalla fondazione di GNOME. La raison d’etre di questi due linguaggi, la loro missione, consiste nel limitare la diffusioni di linguaggi controversi come C# e le librerie Mono nel mondo Linux. Non credo serva ripetere quali sono i problemi di Mono in un ambiente open con Linux.

Oh no! L’ennesimo linguaggio fotocopia!

In realtà Vala e Genie sono qualcosa di più che una copia di C#. Ma partiamo dall’inizio.

La sintassi di Vala è presa quasi interamente da C# ma adattata alla struttura degli oggetti GObject (strutture dati ancestrali della programmazione Gnome). La sintassi di Genie invece ricopia la sintassi del Python.

Quali sono i vantaggi rispetto a usare C# o python?

Potrei elencare una lista di piccoli vantaggi. Tuttavia preferisco dirvene uno enorme: Vala e Genie sono compilati in C. Nessuna macchina virtuale, nessuna interpretazione del linguaggio, bensì tutta la potenza binaria del C. Volendo Vala e Genie vi forniscono anche il file .c e l’header .h in modo tale da poter integrare librerie in Vala all’interno di progetti in C.

Ovviamente il codice è meno prestante di un codice scritto in C nativamente (e scritto per bene) ma è comunque più veloce di una versione interpretata da una macchina virtuale.

Bellissimo! Un esempio?

Vala nasce dal progetto GNOME ed è quindi naturale che integri un supporto praticamente nativo con le librerie Gtk. Le Qt purtroppo non sono ancora supportate. Come esempio creiamo quindi una bella finestra in Gtk (l’esempio è preso da Wikipedia).

Il programma può essere compilato con:

Il risultato sarà un file binario perfettamente funzionante.

Mi piace! Ma funziona solo su Linux?

Vala e Genie sono nati per Linux. Esiste tuttavia un porting sperimentale per Windows.

E come mai questi due linguaggi tanto promettenti non sono nella top 50?

La risposta è una: gioventù. Il fatto che sia un linguaggio nato per linux da poco più che un anno sicuramente non aiuta. Tuttavia le premesse sono ottime.

Sono interessato. Da dove comincio per programmare in Vala?

Il vala non è molto diffuso e informazioni specifiche scarseggiano. Potete innanzitutto cominciare dal sito ufficiale.

Io, personalmente, non ho in programma di scrivere nulla su Vala e Genie. Per SlashCode nel prossimo periodo ho intenzione ancora di trattare Lua, l’AI e alcune cose di simulazione fisica. Comunque, se mi capiterà di trovare libri, siti e guide interessanti non mancherò di linkarle.

Buon Vala a tutti.

Intanto che rifinisco l’ltimo articolo di Lua o mi viene in mente qualcosa di intelligente da dire, vi presento i venti linguaggi più quotati nel mese di giugno 2011 così come rilevati da TIOBE.

1 – Java

Conoscete già tutti Java, uno dei linguaggi più fastidiosi della storia (almeno secondo i miei canoni xD) che però detiene la prima posizione per due motivi: l’uso aziendale intensivo e il fatto di essere il linguaggio di programmazione nativo per Android.

2/3 – C/C++

Aggrego queste due posizioni in una a causa della strettissima correlazione fra i due linguaggi. Il fatto che siano nelle parti alte della classifica non sorprende.

4 – C#

Il clone (migliorato) di Java targato Microsoft è competitivo. Non avevo dubbi, molte aziende utilizzano il framework .net per le loro applicazioni.

5 – PHP

PHP è il linguaggio di scripting più usato del Web. Dopo anni ancora nessun linguaggio riesce a competere in modo significativo con questo mostro sacro dei linguaggi (anche se, la sintassi del PHP sembra fatta apposta per rendere il codice illeggibile).

6 – (Visual) Basic

Qui c’è la prima sorpresa. Il Visual Basic, per chi bazzica la rete, è praticamente un linguaggio morto e solo un pazzo consiglierebbe a qualcuno di mettersi a studiare il Basic. Tuttavia è bene ricordare che VB era usato massicciamente per uso aziendale circa dieci anni fa e che il mondo aziendale è dannatamente lento. Ed è anche comprensibile: quale azienda spenderebbe tempo e denaro per riconvertire migliaia di linee di codice che in VB funzionano perfettamente ai loro scopi?

7 – Objective-C

Questo stupendo spin-off del C/C++ è il linguaggio di programmazione usato per iPhone e iPad, motivo per cui mi verrebbe la voglia di comprarmi un suddetto dispositivo e programmarci su. L’Objective-C è un estensione ad oggetti del C, come il C++, ma da un punto di vista sintattico rispetto a quest’ultimo sembra più organico e versatile. L’uso nei dispositivi di casa Apple è sicuramente la causa principale del suo successo.

8 – Python

Onestamente il Python me lo immaginavo più alto. Il linguaggio di scripting più famoso e chiacchierato del decennio si ferma a 8 perdendo una posizione rispetto ad un anno fa.

9 – Perl

Perl è un linguaggio che ha perso un po’ di fama e notorietà negli ultimi anni spodestato da linguaggi più complessi e completi come Python. Tuttavia, a livello di script di sistema, ci sono ancora tonnellate di script che utilizzano Perl. Dopotutto la sua integrazione nativa con le espressioni regolari lo rendono adattissimo allo scopo.

10 – Lua

Scalando ben 10 posizioni in un anno Lua arriva dalla ventesima alla decima posizione! Se non conoscete l’esistenza di Lua dopo gli articoli che ho fatto vi picchio! Questa è la novità più rilevante del rapporto tant’è che TIOBE gli dedica un approfondimento. Il motivo? Semplice, un anno fa Apple ha deciso di permettere l’esecuzione di Lua su iOS.

11 – JavaScript

Incremento per JavaScript. Il motivo a mio parere può essere solo uno: HTML5. Con i nuovi browser e le meraviglie che si possono fare con HTML5 e JavaScript quest’ultimo ha beneficiato di un notevole interesse da parte della comunità. Ricordo ancora quando il JavaScript veniva dato per morto a causa di Flash e altre tecnologie emergenti ora superate.

12 – Ruby

Ruby è un linguaggio di scripting strano: o lo si ama, o lo si ignora. Questo perché non offre molto più di un Python qualunque ma allo stesso tempo ha una sintassi molto piacevole. Un motivo per cui si mantiene attorno alla dodicesima posizione è la presenza del framework web RubyOnRails.

13 – Delphi/OjectPascal

Lo usavo a undici anni. Poi, ovviamente, è quasi scomparso dalla programmazione mainstream. Comunque, nonostante abbia perso ben 4 posizioni ancora rimane nella top 20. Il motivo per la sua permanenza è comunque storico e legato all’uso aziendale.

14 – Lisp

Questo meraviglioso linguaggio funzionale di “nicchia” è in posizione 14. Ho fatto qualche guida al suo dialetto Scheme che potete trovare nell’archivio di Slashcode.

15 – Pascal

È stupendo notare che un dinosauro dell’informatica come il Pascal sia ancora nella top 20. Il Pascal ha smesso di essere usato come linguaggio didattico già da anni eppure, a quanto pare, l’impatto che ha avuto negli anni 90 è stato talmente elevato che può vivere ancora di rendita.

16 – Assembly

Con Assembly TIOBE aggrega tutti i vari linguaggi macchina. L’uso di tali linguaggi è fondamentale per la programmazione di OS, Driver e altri moduli di bassissimo livello.

17 – Transact-SQL

Transact balza di 4 posizioni ed entra nella top-20. Questo linguaggio è un estensione proprietaria targata Microsoft del classico linguaggio SQL. Tuttavia, a differenza di SQL è Turing completo e quindi può essere considerato linguaggio di programmazione.

18 – RPG (OS/400)

Sale di ben 7 posizioni RPG. RPG è un linguaggio ad alto livello della IBM dalla sintassi scoppiacervello (tenete conto che è un evoluzione di un linguaggio pensato per schede perforate). Onestamente potete ignorarlo e vivrete comunque felici.

19 – Ada

Noto con piacere che un linguaggio dal nome così evocativo sia tornato nella top-20. Ada infatti prende il nome da Ada Lovelace la prima programmatrice del genere umano (ebbene si, era una donna). Ada si ispira molto alla sintassi del Pascal.

20 – Scheme

Dialetto del Lisp. Per cui valgono le stesse considerazioni del suo papà.

Ultimamente, lo ammetto, sto scrivendo parecchio meno del solito. Sono oscillazioni naturali, non si possono avere sempre cose intelligenti da dire e in questo caso è meglio tacere piuttosto che scrivere diecimila post uguali sull’ultima emissione gassosa di Google o di chissà quale altro software. Ho passato le ultime settimane per lo più a studiare (anche se non al ritmo che mi aspettavo causa mancanza di fonti e concentrazione) e ad approfondire alcuni miei interessi. Siatene giulivi poiché dispenserò a breve tale conoscenza a fiotti sulle vostre menti assetate.

Ma torniamo a noi. Nell’ultima settimana mi sono trovato a mettere le mani sul sorgente di KPackageKit. Questo sorgente è un vero lavoro machiavellico di ingarbugliamento di idee, completamente privo di documentazione e saltuariamente infarcito di commenti di poco aiuto come granella di nocciola sul gelato. Allorché, in preda al deliro causato dall’essermi letto migliaia di righe di codice senza averci capito quasi nulla, se non a grandi righe, mi è venuta l’idea di buttare due righe su come NON si programma.

Ci sono infatti una manciata di cose che un programmatore non deve mai fare. Una lista di COSE DA NON FARE che troppo spesso vengono fatte al grido di “tanto funziona” e “tanto si capisce”. Risulta quindi più facile spiegarvi cosa non fare piuttosto che insegnarvi il contrario.

1) NON DOCUMENTARE IL CODICE

La risposta del tizio di KPK alla richiesta di documentazione è stata:

I don’t create documentation for KPackageKit because I think libs needs to be docummented, and if you read the lib’s docs you will understand KPackageKit

Permettetemi di dissentire. E’ normale che un programmatore debba conoscere la documentazione delle librerie Y alla base di un progetto X, ma ciò non toglie che anche il progetto X debba essere documentato! La documentazione di X infatti serve, come minimo, a spiegare come viene utilizzata la libreria Y all’interno di X. La documentazione serve per aiutare chi mette le mani sul codice per la prima volta, fornisce un filo rosso da seguire per muovere i primi passi all’interno del codice senza perdersi e in modo efficiente, spiega quali sono i moduli, il loro funzionamento e come sono relazionati fra di loro. Tutte cose che si possono apprendere dal codice ma che necessita di un enormità di tempo.

Questo fa quindi perdere tempo al novello programmatore e spesso perdere tempo significa far perdere la voglia.

2) DESCRIVERE IL CODICE

Altro errore frequente è quello di descrivere il codice nei commenti. I commenti devono descrivere le intenzioni di un passaggio non tutti i dettagli. Dovete infatti assumere che chi legge il codice conosca il linguaggio e gran parte delle librerie sottostanti.

/* COMMENTO ERRATO:

 * Se a è maggiore di b restituisce a, altrimenti b.

 */



/* COMMENTO GIUSTO:

 * Restituisce il più grande fra a e b.

 */

if (a > b)

    return a

else

    return b

Ora, quello sopra era un esempio piuttosto idiota ma spero sia chiaro il concetto. In sintesi i commenti dovrebbero descrivere tutto ciò che non è chiaramente intuibile leggendo il codice nei dintorni.

3) USARE CONVENZIONI AD-PERSONAM

Questo si traduce in un semplice usate le convenzioni del linguaggio. Questo va fatto sempre. Anche se una cosa è sintatticamente corretta non vuol dire che lo sia. Se nel linguaggio le classi cominciano per maiuscola NON fate classi che non cominciano per maiuscola. Questo serve a far subito capire ad altri programmatori il significato di una parola all’interno del codice. Se io leggo in un codice C++ la parola supereroe io penso che sia una variabile e non una classe. Se invece scrivete SuperEroe allora è chiaro che tale parola si riferisce ad una classe. Semplificando di molto il mio lavoro.

Oltre a questo le convenzioni di un linguaggio indicano la via corretta per molti altri aspetti. Se avete intenzione di infrangere delle convenzioni documentatelo. Come, ad esempio, fa Google con le linee guida per python.

4) NON MANTENERE UNA COERENZA INTERNA

Cosa più semplice a farsi che a dirsi ma che spesso viene del tutto ignorata. Un esempio di coerenza interna è la posizione dei parametri di un metodo o di una funzione oppure il nome delle funzioni. Se decidiamo che tutte le funzioni che accettano in ingresso un vettore finiscano con la lettera v allora dobbiamo accertarci di seguire questa regola per tutto il progetto. Se decidiamo che il primo parametro delle funzioni che si riferiscono ad una Persona sia il nome allora dobbiamo accertarci che sia sempre così.

5) LASCIARE BOLLE DI CODICE SOTTO COMMENTO

Può capitare che, nel corso della scrittura di un programma si commentino grandi parti di una funzione o interi metodi. Questo può servire ad isolare del codice buggato o a nascondere funzionalità incomplete. Tuttavia, sebbene questo vada bene in rami locali personali non dovrebbe mai essere lasciato in rami pubblici. Se una funzione funziona bene, altrimenti la togliamo. Queste bolle di codice creano gran confusione  e soprattutto un programmatore intento a modificare il codice se le ritrova in mezzo alle scatole senza sapere se le può togliere oppure no.

6) CHIAMARE LE VARIABILI CON UNA LETTERA O CON NOMI A CASO

I nomi delle variabili dovrebbero essere piuttosto esplicativi. Ad esclusione di contatori ed iteratori, una variabile non dovrebbe mai avere un nome di una sola lettere. A meno che l’oggetto a cui si riferisce non sia proprio un qualcosa identificabile da una lettera (ad esempio le coordinate x e y di un punto). Non vedo dove sia il problema a scrivere variabili di una decina di caratteri considerando che tutti gli editor hanno l’auto-completamento.

7) ORGANIZZARE IL CODICE SENZA CRITERIO

Il codice va diviso e organizzato in macro-moduli (o package, come si chiamano in molti linguaggi) che siano coerenti fra loro. Questo per consentire un rapido accesso all’insieme dei moduli che gestiscono una data funzionalità. Questi macro-moduli vanno assolutamente documentati.

8 ) SCRIVERE CODICE SENZA PROGETTO

Questo è il punto fondamentale. I programmi vanno prima scritti a computer spento. Non fatevi prendere dalla fretta di scrivere e compilare perché al 90% esce un casino. Questo può andare bene per piccoli progetti e roba semplice ma per qualunque cosa di complesso è un suicidio. Programmate tutto su carta. Scrivete le classi di cui avete bisogno, le relazioni fra le stesse, le operazioni salienti, i moduli da fare e i package in cui suddividerli. Dopo un paio di giorni di analisi a computer spento vedrete che con mezza giornata scriverete migliaia di righe di codice come se fossero sonetti in rima baciata.

Ovviamente mentre scriverete e proverete il codice sul serio salteranno parecchie cose di cui non avevate tenuto conto o errori di progetto. Ma non fa nulla. Questa è la prassi, è il modo in cui vanno fatte le cose.

CONCLUSIONE

Ora spero che appenderete questi 8 punti sulla vostra parete perché io non ho più voglia di impiccarmi mentre leggo del codice scritto e documentato da un macaco. Se seguite i miei consigli e non fate questi 8 punti (in realtà potrebbero essere di più ma oggi sono buono) vedrete che sarà tutto più facile per voi, sia per chi ha intenzione di aiutarvi.

Buona giornata.

A parte il titolo stupido di questa “rubrica” volevo pubblicare la risposta ad una domanda che mi è arrivata da Facebook. La domanda è la tradizionale “Come faccio a programmare come un Dio?”. Domanda la cui risposta basterebbe da sola a riempire corsi e tonnellate di guide. Tuttavia ho scritto un mezzo poema e, unito al fatto che la risposta può servire anche ad altri, mi sembra sprecato lasciarla nella mia casella di posta in uscita.

La domanda era la seguente:

io avrei bisogno di un consiglio se possibile: vorrei sapere come sei arrivato e dove hai imparato a fare queste cose cosi complesse?io provo provo e provo ma fallisco miserabilmente.

Ed ecco la risposta.

Mi fanno in molti questa domanda e difficilmente riesco a dare risposte soddisfacenti.

Per primo credo che sia necessario apprendere una forma mentis che va al di là del linguaggio usato per programmare. Questo permette di passare facilmente da un linguaggio ad un altro e di “progettare” un applicazione ancor prima di scrivere una sola riga di codice.

Tale impostazione è la cosa a mio avviso più importante. Bisogna imparare a trattare le cose che vogliamo fare come entità matematiche perché , fondamentalmente, i computer sanno fare solo calcoli matematici.

Il problema è, come sempre, trovare il modo per entrare in quest’ottica. Il primo modo è avere una preparazione matematica basilare: la matematica è di per se un “linguaggio” e conoscerlo aiuta molto. Secondo c’è il lato puramente informatico. Riguardo a questo ci sono un paio di consigli che con l’esperienza mi sento di dare:

1) Scegliersi un linguaggio e concentrarsi su quello. Non cambiare quindi linguaggio nella speranza che vada meglio: le basi concettuali sono sempre le stesse.

2) La scelta del linguaggio è molto importante: linguaggi troppo “severi” rischiano di farti concentrare troppo sul lato “macchina” del linguaggio, linguaggi troppo “di bocca buona”, al contrario, astraggono talmente tanto la programmazione che difficilmente si imparano i suoi aspetti fondamentali. Io quindi solitamente consiglio delle buone vie di mezzo come C# o Java (tanto per usare i più famosi). Python è molto facile ma lo trovo “poco istruttivo”: è molto più facile passare da C# o Java ad un altro linguaggio piuttosto che passarci da Python.

3) Perseverare. Una volta appresa la sintassi di un linguaggio non si sa programmare. A programmare si impara programmando: piazzarsi un obbiettivo non troppo elevato e iniziare a portarlo avanti. Anche abbandonarlo se si rivela troppo alto ma l’importante è provarci. Il 90% delle cose che ho imparato le ho imparate sbattendoci la testa, cercando soluzioni su Google, chiedendo a gente più esperta. Quindi ti consiglio caldamente di imparare la sintassi di un linguaggio e di usare quello per realizzare piccoli progetti personali. Roba anche inutile ma utile per imparare. Ad esempio scoprirai che è molto istruttivo cercare di implementare una specie di rubrica da terminale.

4) Ultimo consiglio: le librerie. Quando si padroneggia un linguaggio è giunge il momento di imparare qualche libreria: interfacce grafiche (Gtk o QT ad esempio), sistemi audio (gstreamer o Xine), per l’interazione col web, e così via… Questa è l’unica parte veramente difficile E a questo punto non puoi far a meno di chiedere e domandare in giro e dovrai pensarci solo a tempo debito.

Mi sono dilungato anche troppo. Ti ringrazio per la domanda che mi ha spinto a una piccola riflessione e spero che tu possa continuare a provarci. Per ogni domanda che ti verrà in mente durante il tuo percorso puoi sempre trovarmi su Slashcode o chiedere sul forum di LinuxQualityHelp.

Stavo attrezzando un piccolo progettino scemo sulle OpenGL (più didattico che altro) e così ho pensato di condividere quelle regole non scritte che servono ad organizzare e gestire un progetto software. Sono piccole “tips”, struttura delle cartelle e file che non devono mai mancare. Presenterò anche altri strumenti, come ho fatto per Python, ma questa volta saranno strumenti “generici”, ovvero utilizzabili con qualunque linguaggio.

Questo perché tenere in piedi un progetto male organizzato è come costruire un castello di carta. Ci vuole una base forte per rendere il più accogliente possibile il progetto per le persone interessate a collaborare, sia per i membri del vostro team (se ne avete uno).

STRUTTURA CARTELLE

Le cartelle vanno organizzate in modo piuttosto coerente. È importante non mischiare tutto in poche cartelle confuse specialmente per progetti destinati a crescere rapidamente. Una struttura minimale è la seguente:

• src – La cartella src contiene il codice sorgente. Il codice al suo interno può essere organizzato come si desidera in accordo con le convenzioni del linguaggio. L’importante è che contenga solamente il codice del programma/libreria.
• test – La cartella test contiene il codice sorgente dedicato ai test. Il codice di test serve a provare il corretto funzionamento delle classi sviluppate o di alcuni moduli software oppure possono essere semplicemente test prestazionali.
• build – La cartella build contiene tutti i file ottenuti come residuo di una compilazione. Possono essere moduli parziali C/C++ (.o), classi Java (.class), file python compilati (.pyc) e così via. La cartella va a sua volta divisa nelle varie configurazioni di compilazione (ad esempio ci potrebbe essere una configurazione Debug con compilati ottimizzati per il debug e una configurazione Release con compilati ottimizzati per le prestazioni).
• dist – La cartella dist contiene il prodotto finito. Può essere il programma eseguibile, un file .jar, una libreria .so e così via. Tutto quello che sta in dist deve essere pronto per essere eseguito e distribuito.
• doc – La cartella doc contiene la documentazione dettagliata. Tale documentazione è per lo più la specifica dettagliata delle API la quale è solitamente auto-generata.

FILE MUST

Nella cartella radice sono necessari alcuni file. Necessari è una parola grossa in quanto solitamente il programma funziona benissimo anche senza, ma sono un tocco di classe e di umanità verso chi vuole accedere ai sorgenti della vostra applicazione.

• Tool di compilazione - Sia Makefile, o Cmake o qualunque altro tool utilizzate… DEVE esserci uno strumento per la configurazione e la compilazione. Molti IDE possono anche auto-generare roba simile.
• README – Il readme deve dire vita morte e miracoli sull’applicazione. Deve spiegare come può essere compilata  l’applicazione, quali sono le dipendenze, i bug noti, etc..
• README.src – Per applicazioni il cui README è eccessivamente complesso è bene separare le informazioni per sviluppatori in un file a parte. Il file README.src deve spiegare come è organizzato il codice, quale IDE si è usato (se si è usato), quale librerie di sviluppo servono, quale strumenti si sono usati per generare la documentazione, per i test e per altro. Insomma… tutto ciò che può essere utile per chi è interessato alla modifica del codice.
• COPYRIGTH - Il file che contiene le informazioni sulla licenza del progetto.
• CHANGELOG – Il file che contiene la lista dei cambiamenti apportati al programma nel corso della sua storia. Questo file può essere auto-generato da alcuni sistemi di CVS.

DOCUMENTAZIONE

Scrivere a mano la documentazione è sempre l’ultimo dei problemi. Nonostante ci siano molte cose che debbano necessariamente essere scritte a mano, per le API è possibile usare dei tools automatici. Abbiamo visto Epydoc per python. Bene, per tutto il resto c’è Doxygen. Doxygen è un programma di auto-generazione della documentazione utilizzabile per una miriade di linguaggi.

CVS

Il programma per CVS è essenziale se programmate in gruppo ma è molto utile anche se programmate da soli. Vi permette di manipolare il codice con molta disinvoltura navigando fra branch diversi in modo del tutto trasparente.

Potete usare quello che vi pare come CVS anche se io consiglio sempre GIT. Lo trovo molto più veloce ed elastico dei concorrenti. Se volete convincervi potete sempre andare su http://it.whygitisbetterthanx.com/

MESSAGGISTICA

Ebbene si. Se avete un gruppo di persone con cui lavorate insieme non potete prescindere da un sistema rapido e veloce per lo scambio di informazioni, siano esse “OMG! Non funziona una cippa!” o messaggi più tecnici.

A questo punto avete le basi. Non vi resta che seguire questi consigli e lanciarvi nel tempestoso mondo del software libero sperando che il vostro progetto non sia un castello di carte spazzato via dal vento.

Avevo promesso aggiornamenti settimanali ed eccomi qui. Il capitolo sulla logica booleana è grossomodo terminato. Mancano degli esercizi che inizierò a mettere presto. Inoltre c’è anche la prima parte del capitolo sugli algoritmi.

Come al solito sono gradite segnalazioni di errori, commenti e richieste di maggiori chiarimenti su parti della guida che ho involontariamente lasciato troppo fumose.

Trovate tutto al solito link: DIGITAL MIND

Ciao