Chi mi conosce sa bene il mio rapporto di amore-odio con Java. Amore perché Java è un linguaggio performante, di alto livello e soprattutto portabile. L’ho usato spesso, lo uso tutt’ora e ci ho fatto addirittura del game development. Odio perché, proprio perché ci ho combattuto tanto, ne conosco tutti i difetti, i limiti e le idiosincrasie. Java è sintatticamente prolisso e ha qualche problema di “vecchiaia” che andrebbe risolto (ed il confronto con C# è impietoso).

Giusto per fare un esempio in Java è abitudine leggere (o scrivere) codice raccapricciante quale

che in C# si risolve con un semplice

Qualcuno considererà questa caratteristica (tecnicamente si parla di Accessor e Mutators) un puro vezzo sintattico, ma quando si lavora con decine e decine di classi vi posso assicurare che questo facilita di un fattore dieci la produttività e la manutenibilità del codice. Problemi come questo ed altri più “concreti” sono ciò che mi hanno spinto a passare al lato oscuro della forza ogni qualvolta mi è possibile.

In attesa che Java venga riformato (sperando nella rivoluzionaria (?) versione 8 e 9 del linguaggio) la comunità si è messa in moto in modo autonomo. Uno dei progetti a mio avviso più interessanti è senza dubbio Ceylon, di Red-Hat.

Ceylon è un linguaggio JVM-based, ovvero che viene compilato generando byte-code compatibile con la Java Virtual Machine. Questo garantisce due vantaggi: il linguaggio sfrutta la portabilità e le ottime performance della JVM ed è potenzialmente compatibile con le librerie Java esistenti.

Ceylon è un linguaggio molto interessante perché non solo alleggerisce Java da tutti gli inutili orpelli sintattici di cui è infestato ma aggiunge anche una sorta di dinamismo opzionale nella gestione delle variabili (tramite il tipo jolly value). Ma facciamo qualche esempio.

Come non partire dal mitico “Hello, World!”? In realtà non è un “Hello, World!” semplice perché ci mostra due nuove caratteristiche del linguaggio. La prima è il modo con cui vengono documentati metodi e classi: niente commenti, ma una sintassi specifica che può essere letta dal generatore di documentazione integrato di Ceylon. La seconda è il tipo variabile value che può essere usato per simulare una certa dinamicità del linguaggio. Da notare però che nessuno ci obbliga ad usarlo: se siamo sicuri che la variabile message sia una stringa possiamo direttamente dichiararla come tale tramite String message.

Un’altra funzionalità molto utile è l’operatore di null check. Vediamolo in azione:

In questo esempio troviamo i due operatori in azione. Il primo è l’operatore “?”. Considerando il codice precedente, tale operatore restituisce name.uppercased se e solo se quest’ultimo è diverso da null, altrimenti restituisce il valore che lo segue (in questo caso la stringa “WORLD”). L’altro operatore nell’esempio è “?.”. Quest’ultimo fa in modo che si acceda alla funzione/attributo uppercased se e solo se name è diverso da null. Questi due operatori ci risparmiano quindi tutta una serie di noiosi “if” annidati!

Le caratteristiche di Ceylon sono numerosissime e per maggiori informazioni vi rimando alla loro pagina ufficiale. Ceylon è ancora in fase di sviluppo ma è già possibile scaricare delle versioni preliminari!

Come se non bastasse è in progetto lo sviluppo di un backend che compili Ceylon in JavaScript rendendone possibile l’uso anche per lo sviluppo di applicazioni web.

Insomma, Ceylon è un progetto che vi consiglio caldamente di tenere d’occhio!

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.

Salve a tutti e ben tornati dalle vacanze!Per riprendere un po’ il ritmo con il blog vi propongo dei mini-post che rispondono velocemente ai più comuni problemi di compilazione ed esecuzione di programmi.

Il primo problema che risolveremo è il seguente

A chi non è capitato almeno una volta nella vita?

PREMESSA:

Ogni applicazione sul vostro sistema usa delle librerie. Una libreria non è altro che un insieme di codice già pronto e compilato che esegue delle funzioni specifiche. Questo permette ad ogni sviluppatore di non reinventare la ruota ogni volta ma di utilizzare il codice già scritto da altri.

Una libreria può essere statica (.a) o dinamica (.so o .dll su Windows). Nel primo caso la libreria viene inglobata nell’eseguibile in fase di compilazione, nel secondo invece la libreria è un file separato che viene agganciato all’eseguibile durante il caricamento del programma da un componente del sistema operativo chiamato linker dinamico.

Ovviamente le librerie dinamiche ottimizzano meglio le risorse evitando che del codice uguale venga replicato inutilmente in ogni eseguibile.

CAUSA:

Il messaggio di errore non lascia alcun dubbio: la libreria dinamica non è presente nel sistema o il linker dinamico non riesce a trovarla.

SOLUZIONE:

Se la causa è semplice la soluzione è altrettanto semplice.

Per prima cosa accertiamoci che la libreria sia installata e presente nel nostro sistema. Possiamo verificarlo agilmente con

locate libXXX.so

Che restituirà il percorso della libreria.

Se la libreria è stata installata durante la sessione corrente allora dobbiamo forzare l’aggiornamento del database con

sudo updatedb

A questo punto probabilmente la libreria si troverà in un percorso non standard. Non ci resta che aggiungere questo percorso nella lista dei percorsi scandagliati dal linker.

Per fare questo apriamo il file /etc/ld.so.conf (o creiamo un file nella cartella /etc/ld.so.conf.d/) e inseriamoci dentro il percorso della libreria, ad esempio:

/usr/local/lib.

A questo punto chiamiamo

sudo ldconfig

per aggiornare la cache del linker.

E il gioco è fatto.

Durante lo sviluppo di Cobra Draugths ho avuto la necessità di trovare un profiler per Python che facesse al caso mio. Dato che non c’è un unico strumento adatto ho deciso di spiegare passo passo come ottenere dei dati di profiling veloci, puliti e graficamente guardabili.

È una guida espressa: niente discussioni, niente commenti, solo fatti e procedure.

1. cProfile

Primo passo. Installare i tool di profiling per python.

Supponiamo che il vostro programma/libreria abbia un file che invoca i metodi che volete profilare. Possiamo lanciare il comando

Questo avvierà il file test.py e, una volta terminato, creerà un file output.prof contenente tutte le informazioni di profiling.

2. Esplorare il file

Il modo più semplice per esplorare il file creato è usare il modulo pstats.

Ci troveremo davanti una shell. Primo comando da dare è

Che carica il file. Dopo di che possiamo ordinarlo per ordine di tempo (prima le funzioni più costose)

E poi leggere i primi 10 elementi

3. Grafo dei tempi

Il modo più elegante, chiaro e stiloso per ottenere un report leggibile è trasformare tutto in un bel grafo colorato. Per fare questo usiamo il tool Gprof2dot.

Scaricate lo script Python e installatelo con un

A questo punto createvi uno script bash con questo contenuto:

Chiamatelo, ad esempio, gprof2png. Installatelo alla stessa maniera.

A questo punto potete lanciarlo semplicemente con

Questo creerà una gradevole immagine png con tutti i dati di vostro interesse. Come esempio posto l’immagine generata per Cobra Draughts in una partita AI vs. AI.

Buon profiling.

Chi mi segue su Google+ o Twitter sa già tutta la storia. Per chi invece non lo fa eccola qui.

Un paio di settimane fa stavo pensando a quale progetto portare per l’esame di Machine Learning. Dopo aver scartato un po’ di idee perché troppo banali e altre perché troppo complesse mi si è accesa la lampadina. Ho pensato di progettare un intelligenza artificiale per il gioco della dama in grado di apprendere con l’esperienza.

Per l’apprendimento ho avuto subito le idee chiare: usare gli algoritmi genetici. Il fatto che la dama sia un gioco suggerisce subito un ambiente competitivo. Si fanno sfidare AI con parametri diversi fra loro e si selezionano i migliori, che si fanno riprodurre e di nuovo combattere fra loro. Dopo un certo numero di generazioni si ottiene un AI con i parametri migliori.

A questo punto mancava una grossa parte secondaria del progetto, un motore di gioco. Senza una AI che giochi a dama tutto il resto non è fattibile.

Dopo una ricerca infruttuosa di motori di dama adatti allo scopo ho deciso di farmelo da me. Il motore doveva avere le seguenti caratteristiche:

• Essere discretamente veloce.
• Essere di facile realizzazione per non diventare il collo di bottiglia nello sviluppo dell’intero progetto.
• Offrire la possibilità di variare i parametri di analisi della damiera.
• Offrire la possibilità di auto-sfidarsi con due coppie di parametri differenti.

Così, dopo qualche giorno di programmazione ho tirato fuori Cobra Draughts, un software damistico che soddisfa tutti i requisiti che ho elencato precedentemente. Certo, se l’avessi scritto in C (bene) sarebbe stato più veloce ma avrei aggiunto una marea di lavoro in più.

Il programma è discretamente performante, in un secondo riesce ad analizzare l’albero di ricerca fino al 6° livello, tuttavia credo che non lo spingerò oltre al 4° dato che una buona euristica (appresa automaticamente) può compensare i livelli mancanti (o almeno vorrei dimostrare questo).

Potete trovare maggiori informazioni sul progetto nell’apposita pagina google code dove presto metterò anche materiale più tecnico per chi vuole usare il programma a scopo didattico o semplicemente aiutarmi a migliorarlo.

L’ultima release di Eclipse (la Indigo) è favolosa. A prima vista non sembra molto diversa dalle precedenti ma la reattività e la stabilità è notevolmente aumentata. Funziona così bene che ho ricominciato ad usarla dimenticandomi dei problemi che mi aveva dato Helios.

La prima cosa che ho cercato era l’integrazione con Git (si, sono innamorato).

Bene, la ricerca è stata breve e il risultato è molto soddisfacente: EGit. L’ultima versione di Eclipse include questo plugin nella vasta gamma dei plugin scaricabili.

Quindi:

• Andate in Help -> Install New Software...
• Cercate egit e installatelo.
• Riavviate Eclipse
• A questo punto andate su un vostro progetto e cliccando con il destro andate su Team -> Share…
• Scegliete Git come sistema di CVS.
• Il programma vi chiederà dove creare il repository. Per non confondervi scegliete di creare il repository in una sub-directory del progetto (.git) selezionando la relativa spunta. Questo vi eviterà problemi nell’uso di tools esterni.

A questo punto tutto è pronto per il primo commit. Possiamo fare tutto da Eclipse.

• Andate in Team -> Commit… e selezionate tutti i file da aggiungere.
• Effettuate il commit.

Egit offre un ottima integrazione con Git con tanto di rappresentazione grafica della storia, dei rami, delle versioni e di tutte le altre funzioni di Git (compreso il rebase, il merge e il cherry-picking).

Insomma, se utilizzate Eclipse ve lo consiglio caldamente.

Con questo articolo tocchiamo il culmine di Lua. Scopriremo come implementare il paradigma ad oggetti in un linguaggio non Object Oriented come Lua. Scopriremo quindi come questo paradigma manuale lasci una personalizzazione enorme nel comportamento degli oggetti e nella definizione delle classi.

La prima cosa che ci viene in mente per simulare un oggetto è la seguente:

Questo modo è però sbagliato. Se ad esempio facciamo due oggetti

Le azioni e le modifiche su di un oggetto si ripercuotono anche su tutti gli altri! Questo viola il principio per cui oggetti diversi hanno storie differenti. Grosso difetto!

Tentiamo di rimediare scegliendo un approccio più complesso.

Abbiamo aggiunto il parametro self. Questo ci permette di applicare l’effetto di un azione direttamente all’istanza sul quale è invocato. Possiamo inoltre rimuovere la necessità di specificare ogni volta il self usando l’operatore : (due-punti) sia nella definizione di un metodo che nella sua invocazione.

Il nostro oggetto non è ancora completo. Vogliamo introdurre il concetto di “classe”, ovvero di un template grazie al quale creare oggetti con caratteristiche e comportamenti simili.

Possiamo simulare questo meccanismo introducendo un metodo costruttore.

Come potete vedere sfruttiamo il meccanismo delle meta-tabelle per generalizzare l’oggetto. Impostando a self il valore della metatabella di o (il nuovo oggetto) non facciamo altro che dire che: se il metodo (o la variabile) invocata su o non esiste in o allora cercala in self. Ora possiamo quindi evitare di ridefinire un metodo per ogni oggetto: ci penserà Lua ad andare a ripescare nella classe l’implementazione giusta.

Questa procedura permette di ottenere l’ereditarietà delle classi in modo terribilmente semplice.

Anzi, permette perfino di poter ridefinire metodi della singola istanza!

Il codice precedente mostra come è possibile ridefinire il metodo incrementa per la sola istanza c! Questa cosa è difficile da trovare persino per i linguaggi massivamente Object Oriented!

Insomma, con una manciata di righe di codice possiamo creare il nostro personale paradigma ad oggetti in Lua. Ci manca da vedere come poter creare metodi o variabili private. Ma questa è un altra storia.

La notizie e le informazioni in internet vanno sempre verificate. Molte cose infatti si tramandano di bocca in bocca (o di tastiera in tastiera) fino a confondersi. Le senti ripetere talmente tante volte che alla fine te ne convinci e le accetti acriticamente.

Arriva poi il giorno che ti informi e scopri che le cose non sono proprio così o che, in fondo, sono molto più complesse. Fra questo ricade anche l’asserzione Android è scritto in Java.

Android non è scritto in Java?

Si e no. Intendiamoci, il titolo dell’articolo è volutamente provocatorio e non dobbiamo pensare che Java non c’entri nulla con Android, piuttosto dobbiamo capire dove si ferma Java e dove comincia il resto.

Per prima cosa Android è scritto in C. Il kernel è Linux e tutti i ricami sovrastanti sono scritti ovviamente in C. Sembra banale ma ho sentito dire che il kernel di Android è scritto in Java… quindi meglio essere puntuali.

Seconda cosa. La gran parte dello strato applicativo poggia su Dalvik.

Ovvero la nota Java Virtual Machine. Giusto?

Si e no. Anche qui dobbiamo essere precisi. Quando uno dice “le applicazioni di Android sono in Java” apre un mondo di se e di ma.

Quando pensiamo a un applicazione in Java pensiamo alle applicazioni Java che girano sul mattone delle Java VM standard. Quando facciamo questa affermazione diamo l’idea che anche le applicazioni di Android siano dello stesso tipo e girino su una VM equivalente. Ma questo è completamente falso!

Dalvik non esegue codice Java?

NO! Questo ci tengo a specificarlo perché è la chiave di tutto il discorso. Dalvik non esegue e compila il codice Java! Dalvik compila il Java bytecode ed esegue il Dalvik Bytecode! La differenza è abissale, enorme, è come la differenza fra il codice Morse e il Dolce Stil Novo. Basti pensare che il Java Bytecode (quello dei file .class) esegue istruzioni codificate in 8-bit invece dei 16-bit delle istruzioni di Dalvik (nei file eseguibili .dex).

In ogni caso se Dalvik compila il Java ByteCode non è la stessa cosa?

Assolutamente No. Sarebbe come dire che io so il giapponese perché so tradurre in italiano le scritte giapponesi che qualcuno mi traduce in inglese.

Inoltre questa caratteristica permette (in teoria) di utilizzare linguaggi alternativi a Java in modo piuttosto semplice. Ad esempio possiamo scrivere applicazioni per Dalvik anche in Python a patto di compilare il codice Python in Java ByteCode (ad esempio usando Jython ). Il codice compilato in questo modo può quindi passare per Dalvik che lo convertirà in file .dex.

Usare Python (o altri linguaggi) per programmare in Android è tuttavia attualmente impossibile. Tutte le librerie di sistema Android (le API che scarichiamo quando configuriamo l’ambiente) sono scritte in Java, tuttavia se qualcuno avesse pazienza e voglia di convertire tali librerie in Python (compatibile con Jython) si potrebbe usare questo linguaggio in modo quasi trasparente.

Quindi Dalvik non è una Java VM?

Dalvik è una VM che interpreta il Java ByteCode. La differenza è molto sottile concettualmente ma importante per non fare confusione.

Inoltre ci sono numerosissime altre differenze con la Java VM di cui molte incentrate all’ottimizzazione del sistema su dispositivi mobili e con risorse limitate che potete scoprire cercando Dalvik su uno qualsiasi dei motori di ricerca.

A me, sviluppatore, cosa cambia?

Nulla. Tu sviluppatore scriverai applicazioni per Android in Java. Di chi compila ed esegue il tuo codice non ti interessa. Quindi per te le applicazioni Android sono in Java.

Ora però sai che la situazione è più complessa di così e la consapevolezza di come funzionano le cose in realtà le cose è l’arma più potente di ogni sviluppatore.

Lo sviluppo di Lua procede lento ma costante. Ieri è stata infatti rilasciata la Beta di Lua 5.2. La nuova versione del linguaggio introduce, come è solito, grandi cambiamenti e una manciata di incompatibilità con le precedenti versioni. Vediamone alcune (la lista completa la trovate qui)

No more fenv for threads or functions

In Lua5.1 e nelle versioni precedenti ogni funzione ha una tabella ambiente. Tale tabella immagazzina alcune informazioni sulla funzione e in particolare risolve le variabili globali contenute in essa (potete modificare tale tabella con i comandi getfenv/setfenv).

In L5.2 invece questa tabella non esiste più. Tutto il sistema di gestione delle variabili globali è stato spostato in un oggetto _ENV. Tale oggetto è condiviso da tutto il codice (a meno che non viene esplicitamente ridefinito come local da qualche parte.

In pratica immaginate che ogni funzione “base” sia in realtà un metodo di _ENV e che quindi venga invocato come _ENV.mia_funzione(). È un po’ grezza come spiegazione ma credo renda l’idea.

tables honor the __len metamethod

Una meta-tabella è una tabella che contiene informazioni sulla tabella stessa e può essere collegata ad una tabella con il comando setmetatable. Fra le informazioni presenti in questa tabella c’è ad esempio il meta-metodo __len che fornisce informazioni sulla dimensione della tabella. Tuttavia in L5.1 tale metodo soffriva di alcuni problemi logici (specialmente se veniva ridefinito). Facciamo un esempio:

Creiamo una tabella vuota e ridefiniamo __len in modo tale che restituisca sempre 3. L’operatore #t restituirà quindi il valore restituito dal meta-metodo anche se in realtà t ha 5 elementi. Corretto: la ridefinizione di un meta-metodo ha priorità anche sulla realtà stessa. Tuttavia in L5.1 le tabelle non rispettano tale meta-metodo per operazioni come la concatenazione e l’ordinamento dei valori. Il L5.2 questo comportamento è stato risolto (non ho conferme dirette, se potete confermatemelo).

hex and \* escapes in strings

Aggiunti alcuni codici di escape nelle stringhe. Il primo (\x) permette di inserire direttamente il codice esadecimale del carattere che segue. Il secondo (\x) è utile solo per questioni di leggibilità del codice.

Questo codice infatti ignora tutti gli spazi successivi. Nell’esempio precedente quindi la scritta stampata sarà corretta. Se provate a togliere il carattere vedrete che “World” sarà molto lontano da “Hello”.

new library for bitwise operations

Nuova libreria per le operazioni binarie. La libreria è denominata bit e contiene bit.band, bit.bnot, bit.bor, bit.rol, bit.ror, bit.lshift, bit.rshift, bit.btest, and bit.bxor.

goto statement

Abominio. In L5.2 è stato introdotto il comando goto, croce e delizia di molti programmatori hardcore. Ripeto, come mio solito, che non esiste NULLA che possa essere fatto con goto che non possa essere fatto con if, while e break. Tuttavia, se usato raramente e saggiamente, il goto può semplificare il codice a scapito della chiarezza. Ogni volta che usate un goto un gatto muore. Pensateci bene.

emergency (and generational) garbage collector

Ci sono due grossi cambiamenti nel garbage collector. Il primo riguarda il garbage collector di emergenza: in pratica questo comportamento lancia il garbage collector massivamente non appena un allocazione fallisce (nella speranza di liberare spazio), dopo di che l’allocazione viene rilanciata e, se fallisce nuovamente, viene dato definitivamente errore.
Il secondo comportamento (garbage collector generazionale) è invece ancora marcato come sperimentale ma è decisamente interessante: questa modalità sfrutta il principio per cui è più probabile che abbia bisogno di essere deallocato un oggetto creato di recente rispetto ad un oggetto che è presente in memoria da tempo. Questo si traduce in un ottimizzazione del processo di garbaging. Questi due cambiamenti sono decisamente importanti dal punto di vista prestazionale.

Altri cambiamenti

C’è un altro listone di cambiamenti che non ho tempo di analizzare nel dettaglio. Molte modifiche alle librerie standard e ben 11 aggiunte alle API C (che dovrò studiarmi prima o poi per migliorare e adattare LuaGrip). Tutte le novità sembrano essere interessanti sia per gli hardcore lua developer sia per gli utenti finali. Non ci resta che aspettare con trepidazione la versione finale di questa nuova generazione del linguaggio.

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.