Received: by 10.204.146.82 with SMTP id g18mr89068bkv.3.1349027826496; Sun, 30 Sep 2012 10:57:06 -0700 (PDT) X-BeenThere: sug-it@googlegroups.com Received: by 10.204.13.17 with SMTP id z17ls6118685bkz.5.gmail; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) Received: by 10.204.148.22 with SMTP id n22mr1089822bkv.0.1349027825812; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) Received: by 10.204.148.22 with SMTP id n22mr1089821bkv.0.1349027825792; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) Return-Path: Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by gmr-mx.google.com with ESMTPS id 27si1331744bks.3.2012.09.30.10.57.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 10:57:05 -0700 (PDT) Received-SPF: pass (google.com: domain of mario.fu...@gmail.com designates 209.85.217.182 as permitted sender) client-ip=209.85.217.182; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of mario.fu...@gmail.com designates 209.85.217.182 as permitted sender) smtp.mail=mario.fu...@gmail.com; dkim=pass header...@gmail.com Received: by mail-lb0-f182.google.com with SMTP id b5so5778014lbd.27 for ; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+wjS2YNwJZeLWaRfR2fZvsIKGyAKxFWnOUzvUm/FpiY=; b=Wr16fuyc2HoOsTke+IZVYiI8SzW+TvJdZ5cYwWYqsnvO5HPI8/modJKV8Q8xmua30Y qOGqMZgYAbueih9FpsHPeL1Wk9fN2z6vaKBR9Y8YrjtaRmrFB3PLcawDnNSy6n+pHuEa SjdQwBGGkZfe9liVCDswTm23eiE9Z4zUKLCmvq1QtUH+h49yjNaCF7cnnDLht7XhKlfU AMU5B/braD6rRuVryDfSeckRDaWsixRsdDvcDAhS7/mSNnI5QQW6fClINrHou3AOHBZs 2h2cbnsVNyGyNg+fp6mozMqcKj3PEtwoDZPCMFmz1H+M58qlIKP55w8dcYV4RdCCENA0 fa4w== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr9976917lab.21.1349027825541; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) Received: by 10.112.101.234 with HTTP; Sun, 30 Sep 2012 10:57:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Sep 2012 19:57:05 +0200 Message-ID: Subject: Re: [sug-it] Functional TDD: A Clash of Cultures From: Mario Fusco To: sug-it@googlegroups.com Content-Type: multipart/alternative; boundary=f46d042ef4475563dd04caef0417 --f46d042ef4475563dd04caef0417 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Ho letto e in buona parte condivido quello che scrive Beck. Quello che mi > ha stupito e' che la frase "Haskellians have assured me that type > checking is sufficient double checking" abbia dato origine a quasi tutti = i > commenti che seguono. > Anche io l'ho letto (grazie per il link) ed anche io lo condivido in buona parte, eccetto dove dice: "I love (am addicted to, really) the feeling of confidence that comes when a comprehensive suite of tests passes" ma questo credo si sia intuito dalle mie precedenti mail :) > Da programmatore " a oggetti" capisco come definire tipi specifici (Query > piuttosto che String) elimini tutta una serie di problemi, ma molti altri > rimangono (anche Java alla fine e' tipizzato staticamente in modo, credo, > paragonabile). > La potenza della tipizzazione di Java non =C3=A8 in alcun modo paragonabile= a quella di Scala o ancora meno di Haskell anche in considerazione del fatto che il sistema di tipi degli ultimi 2 =C3=A8 Turing completo. Invece, seguendo i commenti, pare che la questione dei tipi in Haskell sia > relamente la soluzione di (quasi) tutti i mali o anche solo una buona > alternativa agli unit test. > Provo a giustificare questa affermazione utilizzando un'esempio preso dal primo capitolo di "Scala in Depth". Implementiamo la semplice storia: "un gatto cattura un uccello e lo mangia" con 2 diversi paradigmi, ad oggetti class Bird class Cat { def catch(b: Bird): Unit =3D ... def eat(): Unit =3D ... } val cat =3D new Cat val bird =3D new Bird cat.catch(bird) cat.eat() e funzionale: trait Cat trait Bird trait Catch trait FullTummy def catch(hunter: Cat, prey: Bird): Cat with Catch def eat(consumer: Cat with Catch): Cat with FullTummy val story =3D (catch _) andThen (eat _) story(new Cat, new Bird) L'autore in realt=C3=A0 utilizza questo esempio ad uno scopo totalmente div= erso: sottolinare il dualismo OOP ed FP in Scala ed evidenziare come nel primo caso la storia si basa principalmente sui nomi (le classi Cat e Bird) mentre nel secondo si sviluppa attorno ai verbi (le funzioni catch e eat). Credo per=C3=B2 che il medesimo esempio possa essere usato anche per giustificare l'asserzione che un sistema di tipi potente come quelli di Haskell o Scala possa essere impiegato per rimpiazzare parte dei test. Come puoi notare lo stato del gatto (quello di avere una preda o quello di essere sazio) nella versione funzionale =C3=A8 implementato attraverso il sistema dei tipi con un mixin (cosa impossibile in Java). In altre parole non hai bisogno di testare che il gatto passato alla funzione eat abbia una preda e quello ritornato dalla funzione stessa sia sazio: ci=C3=B2 =C3=A8 g= arantito dal sistema di tipi e il codice nemmeno compilerebbe se non fosse cos=C3=AC= . Ovviamente ci=C3=B2 non =C3=A8 sufficiente (a mio parere) ad esimerti dall'= avere una suite di test quanto pi=C3=B9 possibile esaustiva, per=C3=B2 spero serva a giustificare che hai bisogno di avere meno test meno per raggiungere tale obiettivo. Mario --f46d042ef4475563dd04caef0417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ho letto e in buona parte condivido quello che scrive Beck. = Quello che mi ha stupito e' che la frase "Haskellians have a= ssured me that type checking is sufficient double checking" abbia dato= origine a quasi tutti i commenti che seguono.

Anche io l'ho letto (grazie per il li= nk) ed anche io lo condivido in buona parte, eccetto dove dice:

&quo= t;I love (am addicted to, really) the feeling of confidence that comes when= a comprehensive suite of tests passes"

ma questo credo si sia intuito dalle mie precedenti mail :)
=C2=A0
Da programmatore " a oggetti" capisco come definire tipi specific= i (Query piuttosto che String) elimini tutta una serie di problemi, ma molt= i altri rimangono (anche Java alla fine e' tipizzato staticamente in mo= do, credo, paragonabile).

La potenza della tipizzazione di Java non= =C3=A8 in alcun modo paragonabile a quella di Scala o ancora meno di Haske= ll anche in considerazione del fatto che il sistema di tipi degli ultimi 2 = =C3=A8 Turing completo.

Invece, seguendo i commenti, pare che la questione dei tipi in Haskell sia = relamente la soluzione di (quasi) tutti i mali o anche solo una buona alter= nativa agli unit test.

Provo a giustif= icare questa affermazione utilizzando un'esempio preso dal primo capito= lo di "Scala in Depth". Implementiamo la semplice storia: "u= n gatto cattura un uccello e lo mangia" con 2 diversi paradigmi, ad og= getti

class Bird
class Cat {
=C2=A0 def catch(b: Bird): Unit =3D ...=C2=A0 def eat(): Unit =3D ...
}
val cat =3D new Cat
val bird =3D= new Bird
cat.catch(bird)
cat.eat()

e funzionale:

trai= t Cat
trait Bird
trait Catch
trait FullTummy
def catch(hunter: Cat, prey: Bird): Cat w= ith Catch
def eat(consumer: Cat with Catch): Cat with FullTummy
val s= tory =3D (catch _) andThen (eat _)
story(new Cat, new Bird)

L'= ;autore in realt=C3=A0 utilizza questo esempio ad uno scopo totalmente dive= rso: sottolinare il dualismo OOP ed FP in Scala ed evidenziare come nel pri= mo caso la storia si basa principalmente sui nomi (le classi Cat e Bird) me= ntre nel secondo si sviluppa attorno ai verbi (le funzioni catch e eat).
Credo per=C3=B2 che il medesimo esempio possa essere usato anche per gi= ustificare l'asserzione che un sistema di tipi potente come quelli di H= askell o Scala possa essere impiegato per rimpiazzare parte dei test. Come = puoi notare lo stato del gatto (quello di avere una preda o quello di esser= e sazio) nella versione funzionale =C3=A8 implementato attraverso il sistem= a dei tipi con un mixin (cosa impossibile in Java). In altre parole non hai= bisogno di testare che il gatto passato alla funzione eat abbia una preda = e quello ritornato dalla funzione stessa sia sazio: ci=C3=B2 =C3=A8 garanti= to dal sistema di tipi e il codice nemmeno compilerebbe se non fosse cos=C3= =AC.

Ovviamente ci=C3=B2 non =C3=A8 sufficiente (a mio parere) ad esimerti d= all'avere una suite di test quanto pi=C3=B9 possibile esaustiva, per=C3= =B2 spero serva a giustificare che hai bisogno di avere meno test meno per = raggiungere tale obiettivo.

Mario
--f46d042ef4475563dd04caef0417--