Funzioni "First Class" e "Higher Order" nella Programmazione Funzionale

In un recente post ho parlato della Programmazione Funzionale (FP) come di un paradigma di programmazione per computer che è sostanzialmente esente da side-effect, cioè a dirla in modo un po' brutale: è esente da comportamenti anomali a run-time.

 

In pratica, un programma scritto in FP pura si comporta come un foglio Excel. Si è mai visto un foglio Excel avere comportamenti anomali? Ci sono dei valori in input, ci sono delle formule e tutto quello che si ottiene sono dei valori di output che derivano dall'applicazione di quelle formule.

In modo simile, un programma FP è una funzione che prende come input una funzione - quindi, si potrebbe dire: una formula - e dà in output un certo risultato. A complicare le cose, c'è il fatto che una funzione FP solitamente prende in input una funzione che a sua volta prende in input una funzione e così via, fin quando ce ne sia bisogno per realizzare lo scopo del programma.

Per indicare questo tipo di comporamento, si dice che un generico linguaggio FP supporta le First Class Functions.

Una funzione, per essere "First Class", deve avere questa caratteristica: può essere passata ad un'altra funzione come qualsiasi altro valore.

Facciamo un esempio. (L'esempio in basso è scritto in linguaggio Scala, che è un linguaggio di programmazione che supporta molto bene il paradigma funzionale).

val areaDelCerchio = (raggio: Double) => { 
    raggio*raggio*Math.PI 
}
    
def printResult(result: Any) {
    println("L'area del cerchio e' : " + result.toString)
}
    
printResult( areaDelCerchio(10.0) )

La formula dell'area del cerchio viene memorizzata come valore (val). Questo basta per far sì che Scala possa dirsi un linguaggio dove le funzioni sono First Class, cioè vengono trattate come valori di prima classe, come lo sono solitamente gli interi o le stringhe. Significa che qualunque funzione può prendere come parametro un valore di prima classe: quindi, tipi elementari, oggetti e funzioni.

La funzione printResult è una funzione che si dice di ordine superiore, Higher Order Function, perché può prendere come parametro un qualsiasi valore e - anche! - una funzione.

Da un punto di vista di controllo dei tipi, la funzione/valore areaDelCerchio prende come parametro un Double (raggio, un valore decimale a doppia precisione) e ritorna un Double.

Qualsiasi oggetto in Scala - e quindi un Double, o una First Class Function - può essere convertito in Stringa. Ed ecco che printResult prende come parametro Any, cioè qualsiasi tipo o funzione, che possa essere rappresentato come stringa - che possegga il metodo .toString.

Poichè la funzione areaDelCerchio non mantiene variabili di stato e non accetta input dall'esterno che potrebbero modificarla, il suo comportamento è predicibile a priori ed esente da side-effect.

Una funzione Higher Order che prende come input tipi semplici o funzioni o funzioni di funzioni, ha un comportamento sempre predicibile e, una volta compilata, sarà esente da bug a run-time. Detto in altri termini: se un programma funzionale puro si compila - quindi non dà errori a compile-time - sarà esente da bug.

La capacità di esprimere un programma per computer, anche complesso, in termini di Higher Order Functions è dunque una garanzia che lo stesso, se si compila, avrà un comportamento predicibile e senza malfunzionamenti.

Se si pensa alle ingenti risorse che vengono impiegate normalmente in informatica per il test e il controllo della qualità del software, le implicazioni economiche di un simile approccio alla programmazione sono del tutto evidenti.

First Class Functions in Scala

A volte è necessario passare come argomenti dei metodi o delle funzioni non un parametro normale come un intero o una stringa, ma un'altra funzione. Ad esempio vorremmo scrivere un metodo che applica una somma o una moltiplicazione di due numeri, e vogliamo passargli come argomento la funzione "somma" o la funzione "moltiplicazione".

Un esempio meno banale: vorremmo scrivere una funzione di sorting che prende in input la collezione di oggetti da ordinare e l'algoritmo di sort. Questa funzione avrebbe quindi due parametri: la collezione e una funzione con l'implementazione dello specifico algoritmo.

Dunque vorremmo costruire una procedura che esegue una determinata operazione sui suoi parametri, e vorremmo passare come parametro l'operazione stessa, in modo da rendere la procedura del tutto generica, e perciò anche riutilizzabile.

Normalmente, nella programmazione orientata agli oggetti, questo si ottiene con un pattern che si chiama "Functor". Il Functor è un'interfaccia che espone un metodo che includerà la nostra funzione. Sta poi alla particolare implementazione dell'interfaccia stabilire se quella funzione è, ad esempio, una moltiplicazione o una somma.

Posto che in Scala le interfacce non esistono, ma esistono i "trait", di cui ho parlato in un altro post, si potrebbe pensare di scrivere due classi, Somma e Moltiplicazione, così fatte:

trait Functor {
  def function(x: Int, y: Int) : Int
}

class Somma extends Functor {
  def function(x: Int, y: Int) : Int = (x+y)
}

class Moltiplicazione extends Functor {
  def function(x: Int, y: Int) : Int = (x*y)
}

Cosa sono le "first class functions"? Sono una particolarità del linguaggio che ci permette di passare, come argomento di una funzione o di un metodo di classe, una funzione; esattamente quello che otteniamo con il pattern "Functor".

In questo caso però, noi non passiamo un oggetto che ha come metodo una specifica funzione: noi passiamo direttamente la funzione!

Questa è la sintassi da usare:

object FirstClassFunctions {
  val somma = (x: Int, y: Int) => (x+y)
  val moltiplicazione = (x: Int, y: Int) => (x*y)
}

La variabile "somma" non è né un tipo primitivo (intero o stringa, ad esempio), nè un oggetto. E' una funzione. La prima parte dice quali sono i tipi che la funzione manipola, e la seconda parte è la funzione vera e propria. Somma è una funzione che somma il valore x al valore y. Similmente per moltiplicazione.

object Main {

  // Functor
  val functSomma : Functor = new Somma()
  val functMoltiplicazione : Functor = new Moltiplicazione()

  def testFunctor(f:Functor, x:Int, y:Int) {
    println("Il risultato e' = " + f.function(x,y))
  }

  // First Class
  def testFirstClass(f: (Int,Int) => Int, x:Int, y:Int)  {
    println("Il risultato e' = %d".format(f(x,y)))
  }


  // Main
  def main(args: Array[String]) {

    testFunctor(functSomma, 6, 5)
    testFunctor(functMoltiplicazione, 6, 5)

    testFirstClass(FirstClassFunctions.somma, 6, 5)
    testFirstClass(FirstClassFunctions.moltiplicazione, 6, 5)

  }

}

Il codice di sopra richiama le funzioni sia sotto forma di Functor, che sotto forma di First Class Functions.
Com'è ovvio, la possibilità di passare direttamente funzioni come parametri di metodi, piuttosto che inventare una tassonomia apposita di classi, riduce la complessità del codice, aumenta la leggibilità e quindi in definitiva migliora la qualità del codice sorgente.

Sviluppare codice migliore con la programmazione funzionale

Minimizzare gli impatti del cambiamento dovrebbe essere uno degli obiettivi prioritari nella produzione del software, soprattutto se in contesti di medio-alta complessità. Normalmente, infatti, si assiste al fenomeno dell'ingessatura del codice: nessuno si azzarda a introdurre cambiamenti migliorativi perché questo potrebbe portare a conseguenze inaspettate, potenzialmente drammatiche.

Per minimizzare gli impatti del cambiamento esistono strumenti e tecniche diverse: ad esempio il test driven development, oppure il defensive programming. Un altro metodo è quello di scrivere codice secondo il paradigma della programmazione funzionale (FP = Functional Programming).

Un programma scritto in un linguaggio FP puro è normalmente esente da "side-effect": cioè è un software che si comporta in un solo modo, predicibile, e che ha un comportamento identico una volta compilato. Questo perché si traduce sostanzialmente in una funzione che prende in input una qualunque serie di funzioni che agiscono su costanti. E' come un meccanismo di ruote e pulegge: una volta in movimento, si comporta sempre nello stesso identico modo.

Purtroppo solo una piccolissima parte di programmi può essere scritta in FP pura. Questo perché un programma per essere utile deve poter prevedere: 1) input dall'esterno e 2) mantenimento di uno stato. Queste però sono due cose che sono "inesprimibili" in FP puro.

Quello che possiamo fare è invece utilizzare un linguaggio ibrido, che permetta cioè sia la programmazione imperativa (magari ad oggetti) cui siamo abituati, sia la programmazione funzionale, cercando di minimizzare e confinare la parte imperativa in un punto noto - e ridotto - del codice sorgente. Eccellenti esempi di linguaggi ibridi sono oggi Scala e C#.

In Scala, le variabili vengono nominate in due modi diversi: var, la variabile "normale" cui siamo abituati, e val, una variabile che, una volta che abbia assegnato un valore, non lo modificherà mai per tutta la sua vita. (In C# le variabili val di Scala sono scritte come readonly) Un programma scritto in Scala che abbia molte var, è un programma che segue la logica imperativa, che crea oggetti che mantengono uno stato e che quindi è potenzialmente pieno di side-effects. Viceversa, un programma che abbia pochissime o nessuna var, e val al loro posto, è un programma scritto in logica funzionale, e che avrà pochi o nessun side-effect. Questo secondo tipo di programma è molto più facile da mantenere, dovrà essere testato di meno, e quindi avrà maggiore valore.

Come si possono scrivere normali costrutti in logica funzionale? E' difficile, perché il nostro cervello è abituato a pensare in termini di "oggetti" e di "stato", e molto poco in termini di "funzioni" e "funzioni di funzioni". Però con un po' di pratica l'obiettivo può essere centrato.

Vediamo un esempio. Supponiamo di voler scrivere una classe che prende in input una stringa e ne calcola il suo valore ASCII (il valore ASCII di una stringa è la somma dei suoi caratteri intesi secondo la codifica ASCII).

class TestClass(givenString: String) {

    require(givenString != null)

    private var gStr: String = givenString

    def getValue() = {

        this.compute()

    }

    private def compute(): Int = {

        var tempSum: Int = 0

        for (charV <- this.gStr.toCharArray()) {

            tempSum += charV.toInt

        }

        tempSum

    }

}

Questo programma in Scala contiene due var: una per mantenere lo "stato", che è la variabile che contiene la stringa da trasformare in numero, e una per mantenere il numero associato alla stringa mentre viene calcolato, all'interno di un ciclo for.

Come trasformare questa classe in logica funzionale?

Dobbiamo come prima cosa far sparire lo "stato" dalla classe. La nostra classe deve comportarsi come una "funzione" e quindi non deve mantenere in memoria parametri che possono cambiare valore nel tempo. Farlo è molto semplice: invece che memorizzare givenString come variabile (var) lo memorizzeremo come costante (val). Oppure, potremmo non memorizzarlo del tutto e passarlo così com'è al metodo di calcolo compute().

Più difficile è invece sostituire il costrutto for che calcola il valore. Qui useremo invece una formula classica della FP. Creeremo un metodo che ritorna una collezione, cioè un array dinamico, di valori ASCII, ognuno per ciascun carattere che forma la stringa. Poi su questa collezione applicheremo una funzione di trasformazione: nel nostro caso "sum". Ogni collezione fornisce metodi operatore sui valori che la compongono, e in più può accettarne di nuovi appositamente scritti.

Ecco il nostro codice trasformato in logica funzionale:

class ImmutableTestClass(givenString: String) {

    require(givenString != null)

    private val gStr: String = givenString

    def getValue() = {

        this.compute(this.gStr)

    }

    private def listOfValues(valStr: String) = {

        for (j <- 0 until valStr.length()) yield {

            valStr.charAt(j).toInt

        }

    }

    // 1. Convert the sequence to actual collection

    // 2. Add "mapping" to collection, example: .sum, .mkString

    private def compute(valStr: String): Int = {

        val listOfVals: List[Int] = this.listOfValues(valStr).toList

        listOfVals.sum

    }

}

Abbiamo buttato via le var e le abbiamo sostituite con val. Il codice è ora puramente funzionale. (E, tra parentesi, funzionerà molto meglio in contesti multi-threading).

Naturalmente lo stesso risultato si può ottenere con C#:

class Immutable

{

    private readonly String tString;

    public Immutable(String testString)

    {

        this.tString = testString;

    }

    public int GetSum()

    {

        return this.CharList().Sum();

    }

    private IEnumerable<int> CharList()

    {

        foreach (char ch in this.tString)

        {

            yield return (int)ch;

        }

    }

}

Convenzione invece che Configurazione

Una delle rivoluzioni silenziose più importanti degli ultimi anni in informatica è l'avvento di strumenti, linguaggi e sistemi che sposano il concetto di

Convention over Configuration (CoC)

ovvero, in italiano, potremmo dire: seguire una convenzione piuttosto che configurare.

I più eclatanti risultati di questa impostazione - ovviamente solo tra quelli che ho potuto provare - sono, ad esempio:

• Maven
  Un tool di management dei sorgenti, che effettua l'organizzazione e la compilazione del codice e della documentazione di un progetto software
• Ruby On Rails
  Un famoso framework per scrivere applicazioni Web data-intensive.
• SBT
  Un tool per la compilazione di codice sorgente in Scala (e non solo...)

Che cos'hanno di speciale questi oggetti software che implementano la CoC? Be' è presto detto: funzionano "da soli" come per magìa, senza bisogno di:

• parametri a linea di comando
• file di configurazione

Li scarichi, li lanci, e funzionano. Così, senza far niente, magicamente appunto! Chiaramente, dopo una prima fase in cui il tool si comporta in default, è sempre possibile arricchire e dettagliare in modo che esso faccia esattamente ciò di cui si ha bisogno.

Faccio un esempio. Comincio a scrivere il mio codice in Scala, un progettino, niente di che, ma comunque un bel po' di file sorgenti e documentazione. Ho bisogno di compilare, e scelgo un tool CoC come SBT. Lo scarico e lo lancio, così, nudo, senza alcun parametro!

> sbt

1. Come prima cosa, SBT si rende conto che gli mancano delle librerie per partire. Ok, le scarica tutte dalla rete e le installa.
2. Poi vede che non ho l'ultima versione di Scala: me la scarica e la mette "a fianco" alla versione che uso io.
3. Si accorge che l'ho lanciato in una directory che contiene codice Scala: fa il parsing dei sorgenti e individua il file che contiene il metodo principale (Main)
4. Compila tutti i miei file 
5. Trova le dipendenze (Scala e Java), le compila e le mette in una directory di libreria
6. Esegue il mio programma compilato!

Fantastico, no?

Cos'ho fatto io per permettere a SBT di funzionare così bene? Nient'altro che seguire delle "convenzioni": ad esempio, ovviamente, i miei file in Scala hanno estensione .scala, ma non molto più di questo.

Allo stesso modo, se scarico Ruby On Rails e ho il database Pippo, mi basta lanciare:

> rails pippo

perché "lui" mi sondi il database e mi costruisca un sito Web completo con tutte le funzioni di front-end per gestire il DB Pippo.

In maniera analoga, Maven, è in grado di scandagliare un progetto in Java, identificare le dipendenze, scaricarle da Internet, aggiornare il sistema e infine compilare e lanciare il progetto. Basta ovviamente che io segua delle "convenzioni" (ad esempio, le librerie sono in una directory /lib).

Questo è il futuro dei tool per lo sviluppo software, e sempre maggiormente la comunità di sviluppatori si aspetterà di avere a che fare con sistemi CoC che funzionano bene out-of-the-box, senza dover leggere quintali di documentazione o seguire passo passo noiosissimi esempi.

Interoperabilità tra Scala e Java

Scala è interoperabile con Java, poiché entrambi i linguaggi producono Java bytecode. Questo significa che tutte le seguenti frasi sono vere:

• Codice Scala può essere eseguito da una Java Virtual Machine
• Codice Java può essere "visto" da codice Scala
• Codice Scala può esserre "visto" da codice Java

Supponiamo di avere ad esempio la seguente classe di business in Scala, una generica struttura che rappresenta l'astrazione di un numero razionale. E' costruita passando numeratore e denominatore, ad esempio Rational(2,3) è due terzi (2/3).

 package net.alessiosaltarin.rationals  
   
 class Rational(n: Int, d: Int) {  
   require(d != 0)  
   
   private val g = this.gcd(n.abs, d.abs)  
   val numer: Int = (n / g)  
   val denom: Int = (d / g)  
   println("Created " + this.toString())  
   
   def this(n: Int) = this(n, 1)  
   
   override def toString = this.numer + "/" + this.denom  
   
   def +(that: Rational): Rational =  
     new Rational(  
       this.numer * that.denom + that.numer * this.denom,  
       this.denom * that.denom)  
   
   def *(that: Rational): Rational =  
     new Rational(this.numer * that.numer, this.denom * that.denom)  
   
   private def gcd(a: Int, b: Int): Int =  
     if (b == 0) a else gcd(b, a % b)  
 }  
   
 object RationalComputer {  
   
   def performSum(r1: Rational, r2: Rational): String =  
     (r1 + r2).toString()  
   
   def performMultiply(r1: Rational, r2: Rational): String =  
     (r1 * r2).toString()  
   
 }  
   
 object RationalFactory {  
   
   def create(rationalStr: String): Rational =  
     {  
       val indexOfSlash = rationalStr indexOf '/'  
       val n = nrParse(rationalStr.substring(0, indexOfSlash))  
       val d = nrParse(rationalStr.substring(indexOfSlash + 1))  
       new Rational(n, d)  
     }  
   
   private def nrParse(nstr: String): Integer = Integer.parseInt(nstr)  
 }  

Se vogliamo offrire a questo codice una user interface, che non sia Web, abbiamo ben poche possibilità, se vogliamo rimanere nell'ambito di Scala, e cioè quelle di usare il wrapping delle librerie Swing scritto in Scala, vale a dire: http://www.scala-lang.org/api/current/scala/swing/package.html Il problema di questo approccio è che alla data di questo post manca totalmente un editor visuale che generi in output un codice Scala. Quello che abbiamo, invece, sono degli editor visuali che generano codice Swing in Java, ad esempio:

• Netbeans Matisse
• Eclipse Visual Editor

La buona notizia è che, stanti le premesse di cui sopra, codice Scala può essere visto da Java come se fosse una "libreria" esterna (e viceversa, tra l'altro). Possiamo infatti pensare di realizzare un'interfaccia di questo tipo:

attraverso l'editor visuale che preferiamo, generare il codice Java equivalente, e poi eseguirlo. Per farlo possiamo seguire due approcci, entrambi validi: eseguire dalla macchina virtuale Scala il codice Scala e il codice Java interpretarlo come bytecode esterno, oppure eseguire da una qualsiasi macchina virtuale Java il codice dell'interfaccia grafica e da questo richiamare il bytecode compilato da Scala come una libreria esterna. Chiaramente, è il secondo approccio quello più interessante. Infatti nella pratica avremo a disposizione macchine virtuali Java, ottimizzate a seconda dell'uso. Perché questo approccio sia percorribile, occorre costruirsi un proxy Java in grado di richiamare il codice di business in Scala. Il proxy conterrà i metodi richiamati direttamente dall'interfaccia - nell'esempio, il pulsante di 'esegui operazione'. Ad esempio:

 package net.alessiosaltarin.javaproxy;  
   
 import net.alessiosaltarin.rationals.Rational;  
 import net.alessiosaltarin.rationals.RationalFactory;  
 import net.alessiosaltarin.rationals.RationalComputer;  
   
 public class ProxyLogic  
 {  
   public static String performOperation(Operation op,   
                           String rationalOne,   
                           String rationalTwo)  
   {  
     Rational r1 = RationalFactory.create(rationalOne);  
     Rational r2 = RationalFactory.create(rationalTwo);  
     String result;  
       
     switch (op)  
     {  
          case ADD:  
          default:  
               result = RationalComputer.performSum(r1, r2);  
               break;  
                 
          case SUBTRACT:  
               throw new UnsupportedOperationException();  
                 
          case MULTIPLY:  
               result = RationalComputer.performMultiply(r1, r2);  
               break;  
                 
          case DIVIDE:  
               throw new UnsupportedOperationException();  
     }  
       
     return result;  
   }    
 }  

Il codice sopra richiama il codice Scala - il namespace

net.alessiosaltarin.rationals.Rational

Come fa? Semplicemente lo trova nel percorso del codice compilato come Java bytecode, a patto di avere la libreria Scala

scala-library.jar

nel classpath corrente. Supponendo che la classe RationalGUI sia quella generata dal tool visuale, il codice eterogeneo Scala/Java verrà eseguito dalla JVM in questo modo:

java -cp scala-library.jar;[jre,...] net.alessiosaltarin.javaproxy.RationalGUI

Utilizzando ad esempio Eclipse, è possibile aprire due progetti, uno in Scala e uno in Java, e in quello Java che contiene il metodo main, referenziare come libreria esterna il codice Scala custom e la libreria scala-library.jar.

Differenza tra 'object' e 'class' in Scala

Una delle cose che trovo più intelligenti nel linguaggio Scala, è la netta distinzione tra Tipo Object e Tipo Class. Il primo è un tipo che può avere soltanto una istanza. Il secondo è un tipo che può avere molteplici istanze.

Il primo ha sintassi 'object', il secondo 'class'.

Chiaramente il primo, essendo sostanzialmente una classe "statica", non va istanziato, i suoi metodi possono essere chiamati direttamente. Il secondo va istanziato.

Ecco un esempio:

class Molteplice(nr : Int)
{
  def id = nr;
  
  def parla()
  {
    println("Buongiorno, sono il Molteplice nr = " + id);
  }
}

object Singleton 
{
  def parla() 
  {
    println("Buongiorno, sono un singleton.");
  }
}

object Main 
{
  def main(args : Array[String]) : Unit = 
  {
      Singleton.parla();
      val range = 0.until(10);

      for (i <- range)
      {
         val m = new Molteplice(i);
         m.parla();
      }
      
   } 
}

Questo ci permette di capire subito le intenzioni del programmatore, che deve creare classi solamente dove questo ha realmente senso.

Nella mia esperienza di programmatore OO (in Java, C++ e C#), direi che su 100 tipi in un programma normale, ad esempio di integrazione aziendale, 70 sono singleton (cioè in Scala 'object'), ovvero collezioni statiche di metodi e proprietà, e solo 30 classi vere e proprie (in Scala, 'class').

Ereditarietà multipla in Scala

Il problema dell'ereditarietà multipla nei linguaggi fortemente tipizzati (C++) è, molto banalmente, che se un oggetto eredita da due differenti classi che implementano lo stesso metodo, il compilatore non sa quale implementazione di quel metodo associargli (bind).

In Java e in C# perciò si è deciso di abolire l'ereditarietà multipla, e di inserire il concetto di interfaccia. Il problema delle interfacce, però, è che attraverso di loro viene descritto il comportamento di un oggetto (quali metodi sicuramente quel metodo avrà), ma non viene implementato, perché l'implementazione si demanda alla classe di quell'oggetto.

Questa soluzione non è ottimale, perché se nella mia tassonomia di classi ho delle forti "somiglianze" tra una classe e l'altra, la scrittura dell'implementazione dell'interfaccia comune rischia di doversi ripetere da una classe all'altra. Insomma, rischiamo ripetizioni e riscritture.

In Ruby esiste il concetto di mixin, per cui posso "prendere a prestito" del codice che esiste "altrove" e inserirlo nella mia classe, senza doverlo riscrivere. Il problema è che Ruby è un linguaggio di scripting, e non è tipizzato.

Scala è invece un linguaggio tipizzato che permette - in un certo senso! - l'ereditarietà multipla, e lo fa attraverso i "trait".

Ecco un esempio:

abstract class Animale
{
   def nome:String;
   def classe:String;
   def comeMiChiamo:String = ("Sono il " + this.nome + " e sono un " + this.classe);
}

trait Mammifero extends Animale
{
   override def classe:String = "Mammifero";
}

trait Rettile extends Animale
{
   override def classe:String = "Rettile";
}

class Delfino(aName: String) extends Animale with Mammifero
{
   def nome:String = "delfino "+ aName;
}

class Serpente(aName: String) extends Animale with Rettile
{
   def nome:String = "serpente "+aName;
}

object Main
{
    def main(args: Array[String])
    {  
      parla(new Delfino("Pippo"));
      parla(new Serpente("Pluto"));
    }
 
    def parla(animale: Animale)
    {
      println(animale.comeMiChiamo);
    }
}

In questo esempio, la classe Animale è una classe astratta, che definisce il metodo "comeMiChiamo" (ok, non mi veniva niente di meglio!). Questo metodo è polimorfico rispetto alla "specie" dell'animale. Definisco perciò due nuove classi, che incidentalmente sono anche "classi di animali": i rettili e i mammiferi.

L'output del programma in console è:

Sono il delfino Pippo e sono un Mammifero
Sono il serpente Pluto e sono un Rettile

Quello che voglio dimostrare, è che posso scrivere in Scala una classe che eredita sia da Animale (il metodo "come mi chiamo"), sia da Rettile oppure Mammifero. Per farlo, "Rettile" e "Mammifero" sono due trait, di fatto la trasposizione dei Mixin per Scala. Se vogliamo, sono delle interfacce, solo che, a differenza delle interfacce in Java, il metodo che espongono è anche già implementato - evitandoci riscritture e copia/incolla nel codice (che è sempre male).

PS: La questione della duplicazione dei metodi alla base del problema dell'ereditarietà multipla, non è risolta, in Scala, è solo "evitata", dal momento che il compilatore, quando si tratta di "trait", fa un bel copia e incolla e non si preoccupa di controllare la coerenza - provate infatti ad esempio a far ereditare a Delfino sia il trait Mammifero che il trait Rettile:

class Delfino(aName: String) extends Animale with Mammifero with Rettile

Scala e i suoi fratelli

Da qualche tempo guardo con interesse ai nuovi linguaggi che fanno la loro comparsa nel variegato orizzonte della programmazione dei computer. Tra gli altri, soprattutto Scala.

Giusto due note a proposito: che sono, lo sottolineo, del tutto soggettive.

La prima: il paradigma della programmazione funzionale non soppiantera' il paradigma a oggetti. Infatti il successo della programmazione a oggetti deriva dal fatto che l'essere umano,normalmente, pensa per oggetti e relazioni tra oggetti, e non per funzioni. Tranne casi particolari (il matematico, il fisico) l'uomo non pensa a un problema in termini funzionali (e men che meno di funzione di funzione, o di funzione di funzione di funzione...)

La seconda: dopo Java (e C#) il panorama dei linguaggi per computer e' abbastanza statico, e ho l'impressione che i nuovi venuti non portino significativo valore aggiunto. Ho l'impressione che oggi il focus si debba spostare dai linguaggi alle API. Il successo di Java, e poi del .NET Framework, si deve all'efficacia e all'ampiezza delle loro API piuttosto che delle specifiche tecniche del linguaggio. Francamente, al programmatore medio importa assai poco delle closures piuttosto che delle list comprehensions. Se invece riesce a creare un file e poi zipparlo in due linee di codice il discorso cambia...

Inoltre, il sempre maggior peso della UI (sia lato desktop che lato Web, il che ho l'impressione che prossimamente sara' la stessa cosa...) privilegia quei linguaggi e piattaforme che permettono di realizzare facilmente le interfacce grafiche e di integrarle con la business logic dell'applicazione.

In questo senso, il .NET Framework con il suo supporto a Silverlight attraverso XAML e il WPF, e dall'altra parte Adobe con AIR/Flex per Flash, siano i veri nuovi protagonisti della scena.

Espressività e sinteticità di un linguaggio

La recente discussione su Artima che riguarda l'espressività e la sinteticità di un linguaggio (http://www.artima.com/forums/flat.jsp?forum=276&thread=198171) mi spinge a fare qualche altra riflessione, visto che sull'argomento avevo già speso in passato qualche parola.
In questo forum si discute della sinteticità e dell'espressività di un linguaggio come sinonimi (e si sottolinea che non lo sono, o meglio, non è sempre detto che lo siano).
Un linguaggio per computer è conciso quando permette di fare "tanto" con "poche" righe di codice. Prendete ad esempio questa classica ricetta in Python:

thelist.sort()
item_insert_point = bisect.bisect(thelist, theitem)
is_present = thelist[item_insert_point-1 : item_insert_point] == [theitem]

Questo codice permette di cercare un item all'interno di una lista ordinata usando un algoritmo di ricerca binario. Sfido chiunque a fare la stessa cosa, per esempio, in Java, in 3 linee di codice. Dunque, Python è un linguaggio sintetico. (Il che significa spesso che ha delle API molto avanzate: in questo caso tutto il lavoro lo fa bisect).
Eppure, il codice sopra è poco espressivo. Ho detto che per espressività in genere si intende la capacità di un linguaggio di essere:

• leggibile (cioé facilmente comprensibile a chi abbia una ragionevole dimestichezza con i linguaggi per computer)
• potente (cioé possa esprimere un algoritmo in molti modi diversi)

Sicuramente è poco leggibile - tranne che dai fan di Python! Però capiamoci, non è vero che Python (ma potrei dire Ruby o Groovy o qualsiasi altro linguaggio della scorsa generazione, cioé prima di Scala, per intenderci) sia poco espressivo. Al contrario, viene sempre indicato come un linguaggio super-espressivo (e ciascun programmatore in Python vi dirà che è contento di Python proprio perché permette di fare "tutto" con pochissimo sforzo).

Allora qual è il nocciolo della questione? E' che spesso si confonde l'espressività di un linguaggio con la sua capacità di offrire "zucchero sintattico" per fare le cose normali, senza però aggiungere veramente qualcosa di nuovo. La sinteticità, in fondo, è sempre "zucchero sintattico", a volte è solo un virtuosismo inutile. Perciò, l'espressività di un linguaggio non la misurerei in varianti sintattiche per fare la stessa cosa (esempio, contare da 1 a 1000), ma nella sua capacità di fare cose che altri linguaggi non sono in grado di fare (esempio, le closure di cui parlavamo). Con nuova espressività, un linguaggio è in grado di annoverare tra le sue API, delle API che in altri linguaggi non sono nemmeno immaginabili.

Perché queste cose noiose sono così interessanti? Perché in realtà qui si gioca la nostra capacità di utilizzare i computer per fargli fare - senza perderci una vita - ciò che vogliamo: nuovi modi per lavorare, la possibilità di automatizzare alcuni compiti, o anche nuovi modi per divertirci, dalla comunicazione ai videogiochi. Linguaggi per computer più espressivi ci permetteranno di fare con loro - insieme all'evoluzione tecnologica dell'hardware - cose prima inimmaginabili.