micheledellatorre.net

Come ho scritto qualche tempo fa, ho iniziato a giocare un po’ con Ruby, cercando di realizzare un piccolo gioco.
Il primo approccio non è stato dei più felici.

Ruby è un linguaggio dinamico che sfrutta la tipizzazione dinamica, quindi può essere modificato a runtime il comportamento di una classe e non vi sono controlli sul tipo a compile-time.
Queste due caratteristiche danno una flessibilità incredibile al linguaggio, ad esempio pensate di avere a che fare con un’applicazione in cui i numeri devono essere trasmessi sulla rete con una codifica particolare a 16 bit; con un linguaggio come Java svilupperemo un metodo con la seguente signature

public static byte[] encodeFloat(float f)

ma non è molto “object oriented” come soluzione, in Ruby è possibile aggiungere il metodo encode direttamente alla classe numerica, arrivando poi a scrivere codice del tipo

socket.sendData( 10.encode )

che è sicuramente più pulito.

Tutta questa flessibilità però ha un prezzo molto salato,infatto il compilatore non è più un nostro alleato e si finisce col perdere tantissimo tempo alla ricerca di un errore comune come la scrittura errata del nome di una variabile o di un suo metodo. Il fatto più irritante è che questo problema può essere evidenziato solo dopo molto tempo. Prendiamo il seguente esempio in pseudocodice:

numero = random(10000)
if (numero > 0) 
    risultato = log(numero).toString()
else
    risultato = numro.toString()

in un linguaggio come Java o C# si viene segnalato subito che nell’ultima riga abbiamo sbagliato a scrivere il nome della variabile, mentre in Ruby ce ne accorgiamo solo quando viene eseguito quel ramo di codice, ma è evidente che la probabilità è molto bassa.

Il test diviene quindi fondamentale visto che deve prendersi carico anche dei compiti che normalmente vengono eseguiti dal compilatore, quindi una metodologia test first è praticamente obbligatoria (tant’è che Ruby ha integrato un framework di test simile a JUnit).

Preso singolarmente questa mancanza non sembrerebbe quindi così grave: chi, come me, scrive sempre i test prima del codice non ha particolari problemi. Peccato che non sia vero.
Tanto per cominciare il compilatore è davvero comodo, cioè ci fa risparmiare tempo, per alcuni tipi di modifiche: ad esempio supponiamo di esserci resi conto che una certa classe è inutile e perchè può essere sostituita con una classe fornita da una libreria. La cosa più rapida è cancellare la vecchia classe, guardare quali sono i file che non compilano più e modificarli: con un IDE come Eclipse l’operazione è davvero molto veloce, visto che con un semplice doppio click sull’errore si viene rimandati dalla riga corrispondente.
In Ruby invece bisogna continuare a lanciare i test finchè la barra non è verde… insomma, è un lavoro decisamente più lungo, specialmente se i test non riescono a darci un’idea precisa di dove sia l’errore.

Il secondo limite, ben più grave, è in sede di refactoring, specialmente per quelli molto comuni come la rinominazione di un metodo o una variabile visto che la mancanza di tipizzazione statica non fornisce alcun indizio al motore di refactoring stesso (tant’è che Netbeans ci obbliga a vedere la preview e accettarla).

Dalla mia breve esperienza, posso dire che Ruby è ottimo quando si devono scrivere programmi relativamente piccoli in tempi rapidi, mentre mi affiderei ad un linguaggio con un numero maggiori di controlli a compile time, come Java o C#, per programmi più vasti o critici.