Pare che questa sia stata una settimana intensa sul fronte dei linguaggi di programmazione, ed è una cosa buona.

In particolare è una cosa buona per me, visto che oggi ho tempo di scrivere questo post mentre domani me ne torno nella terra degli unni, il che significherà un probabile /away di un mese dal mondo tecnologico. Siccome voglio chiudere in bellezza vi lascio qualcosa di corposo da leggere.

Pugs & teoria dei numeri
Ma dicevo, settimana intensa sul fronte programmatorio. Anzitutto l’Autore è diventato committer di pugs, dimostrando che effettivamente il commit bit viene dato via con estrema facilità.
In particolare il suo ultimo contributo è stato il problema numero 32, implementare l’algoritmo di euclide per il minimo comune multiplo:

# Perl6 impone l'ottimizzazione delle tail call, per cui
# non abbiamo bisogno di scrivere la routine in forma iterativa.
# Ale' !
	
multi sub gcd(Int $a, Int $b){
    return $a if $b == 0;
    return gcd($b,$a % $b);
}
	
is gcd(36,63), 9, \"We should be able to find the gcd of 36 and 63\";
is gcd(63,36), 9, \".. and viceversa\";
is gcd(0,5)  , 5, '.. and that gcd(0,$x) is $x';
is gcd(0,0)  , 0, '.. even when $x is 0';


Notate la finezza per cui gcd è definito come un multimetodo, perché in teoria è possibile definire la funzione in qualsiasi anello commutativo, non solo per gli interi.

Ovviamente io so che esiste una cosa chiamata anello commutativo, ma non mi ricordo cosa sia veramente e questa nota è un semplice plagio da wikipedia.

Il che tra l’altro mi da l’occasione di far notare che la definizione di numero primo su en.wikipedia è sbagliata.
Uno (1) non è un numero primo, per definizione un numero primo è un numero positivo divisibile solo per se stesso e per 1 ma diverso da uno (o -1).
Questo perché, se usiamo questa definizione poi ci viene fuori il fantastico teorema fondamentale dell’aritmetica che è:

Ogni numero naturale diverso da 1 o è un numero primo o si può esprimere come prodotto di numeri primi. Tale rappresentazione è unica a meno dell’ordine in cui compaiono i fattori.

Il motivo di questo delirio era ovviamente la soluzione del problema 31.

Tornando a Perl6, forse l’Autore potrà raccontare ai suoi nipotini che se una subroutine dichiarata come Bool converte automaticamente un valore di ritorno undef in False è merito suo. Larry sembrava ponderoso sull’argomento, ma ci sono speranze.

Groovy 1.0
E a proposito di linguaggi con dichiarazioni di tipo opzionali, Groovy ha finalmente raggiunto la versione 1.0.
Per parte mia, ritengo che Groovy sia un linguaggino carino, mi piace un sacco che abbiano la variabile implicita “it” nei blocchi, ad esempio, che permette di scrivere

[1,2,3].each { print it}

Ma in fondo è solo un poco interessante dialetto di ruby per la JVM.
Il Lettore arguto potrebbe obiettare che ruby è solo un poco interessante dialetto del lisp o di smalltalk per unix, ma ho fiducia che i Lettori arguti non siano dei rompipalle.

D 1.0
Più interessante è invece il linguaggio D, che raggiunge la 1.0 , e mi han fatto notare che adesso c’è anche un pacchetto debian di gdc.

L’Autore invita a notare che gdc è un anagramma di gcd, e questo ovviamente non è un caso.

IMHO D è un’ottimo esempio di linguaggio di sistema moderno. Design By Contract, libreria ricca (regexp, socket, thread), strutture dati come array dinamici ed hash integrate, OOP fatta in modo sensato, supporto unicode etc..

Ma perché D prenda piede ha bisogno di un progettone open source che lo traini (server ftp/http/whatever, nuova implementazione di X11, linguaggio usato per nuke’em forever…) , e questo non verrà fuori a brevissimo tempo, temo.
Python e Ruby ci hanno messo una decina d’anni a sfondare.
E nel frattempo la concorrenza non se ne sta ferma, con il nuovo C++ in arrivo, il nuovo C# e i futuri Java, quindi imo il futuro di D non è particolarmente brillante.
Ma speriamo che mi sbagli.

Java 7
Guardiamoci in faccia, la comunità Java si è data una svegliata, hanno corretto, o provato a correggere, il linguaggio dove aveva delle falle troppo grosse (generic, autoboxing etc), hanno esteso la libreria dove ce n’era bisogno (java.util.concurrent etc), hanno cercato di abbracciare le richieste della comunità (JVM open source, invokedynamic).
E in java 7 ci saranno anche le closure, cosa che già sapeva , ma quello che non sapevo è il modo con cui esse si integreranno con le api precedenti.

In pratica, la closure viene utilizzata per costruire un’oggetto anonimo che viene poi infilato dentro l’interfaccia che già esisteva per i metodi. Ok, non si è capito, intendo dire che ad esempio una funzione startComputation(Runnable r) può essere richiamata con una closure come argomento, che verrà poi convertita automaticamente nel metodo run di un oggetto Runnable creato al volo.
Ovviamente, affinché il compilatore sia in grado di gestire correttamente la cosa è necessario che riesca a capire in che metodo mettere il blocco, quindi perché la cosa funzioni l’interfaccia deve fornire un solo metodo, come fa Runnable con run.

Per il resto è bello vedere come queste closure siano identiche ai blocchi in ruby, ad esempio non vengono segnalate nell’eccezioni come funzioni aggiuntive, il return da una closure esce dal blocco esterno ad essa invece che dalla closure, se si mettono come argomenti speciali si può usare una sintassi più carina etc..
Vabè, ma è inutile che ve ne parli io, andatevi a leggere l’intervista a neal gafter

Conclusione
Siamo al 4 gennaio, e già c’è un sacco di roba a cui pensare.
In più lawrence ha scelto erlang come LoTY, il che suggerisce che si potrebbe seguirlo.
E poi mi sono impegnato a rendermi utile con sette gruppi di persone differenti.
Ed avrei due o tre progettini da portare avanti.
E devo prendere una cavolo di laurea (”oh no, di nuovo!” [cit]) .

Ma se ne parla da febbraio, da febbraio.