<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-10 15:19 GMT+01:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Riporto quanto espresso sulla lista XPUG-BO dal prof. Marcello "Piffy" Missiroli. <br><br><div>"Un mio commento a freddo sulla serata (che è stata molto carina, anche nel post-evento)</div><div><br></div><div>Dato
 che ignoro il ramo applicativo di Go e di quali e quante libreria siano
 disponibili, mi limiterò a valutare il linguaggio in sè e le sue 
caratteristiche. </div></div></div></blockquote><div><br></div><div>Mi sembra che la premessa chiarifichi tutto: ovvero, non ci ho scritto 3 righe di fila. E da molti dei commenti che fa sotto, e' parecchio chiaro.</div><div>In particolare parecchie delle questioni che segnala sono cose che si chiariscono affrontando un progettino giocattolo. Sono li e hanno senso.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>In sintesi, non è che mi abbia molto convinto. </div><div><br></div><ul><li>La
 sintassi è presa "parzialmente" dal C, ma con strane modifiche che lo 
rendono soggetto a errori inconsci. Per esempio la scelta di avere il 
tipo di dato DOPO la variabile. Il che crea costrutti particolamente 
poco chiari come x := float32(y)  che non è solo un'assegnazione. </li></ul></div></div></blockquote><div>E qui, per dire, fa come esempio una questione relata al tipo, ma che *non* e' un problema di dichiarazione. Ovvero, in Go *tutte* le dichiarazioni hanno il tipo in coda (o non hanno tipo esplicito in quanto inferito dal compilatore). Che e' strano se vieni da C, certo. Che e' anche uno dei motivi per cui si evitano molte ambiguita' nel parsing che hanno C e C++. Nota a margine: le ambiguita' non sono solo per il compilatore, ma per chi legge.</div><div><br></div><div>a * b in C puo' essere, per dire, una dichiarazione di una variabile puntatore ad a oppure una moltiplicazione. In go e' solo una moltiplicazione.</div><div>Ci sono un po' di spiegazioni di queste problematiche sulle faq.</div><div><br></div><div>Ora, queste cose ad occhio non e' che mi aspetti che le veda. </div><div><br></div><div>E quella li *non* e' una dichiarazione. Cioe', si, formalmente e' una dichiarazione. Ma la parte di dichiarazione e' semplicemente</div><div><br></div><div>x := <expr></div><div><br></div><div>il fatto che expr sia un type cast... beh, vabbe'. ma non e' particolarmente diverso da fare x = int(y) in Python.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>I
 controlli (if, then, else, switch) sono abbastanza carini, ma anche qui
 l'idea di poter preporre un'assegnazione prima del controllo ne fa 
perdere un po la leggibilità.</li></ul></div></div></blockquote><div>E come dire... l'assegnamento li serve per idiomi estremamente comuni:</div><div><br></div><div>if a, err := build_a(...); err != null {</div><div>   defer clean_a(a)</div><div>}</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>Carini anche se non immediati i vari 
range, map, un po' presi da python e ruby.</li></ul></div></div></blockquote><div>Anche qui... cosa non abbia di immediato range non lo so. Ricordiamoci che esplicito e' bello. Vogliamo iterare su un array?</div><div><br></div><div>for el := arr {</div><div><br></div><div>}</div><div><br></div><div>ecco... questo dovrebbe volere dire cosa? che voglio iterare su un array? Pero' attenzione... quell el := arr all'inizio sembra molto un assegnamento "semplice" (per inciso, il codice non compila, ma solo per intenderci. </div><div><br></div><div>Questo invece compila:</div><div><div>     for el := a;; {</div><div><br></div><div>   <span class="" style="white-space:pre"> </span>fmt.Println(el)</div><div>      }</div></div><div><br></div><div>e ovviamente e' un loop infinito. etc etc etc. io trovo che usare range sia piuttosto carino sia come sintassi che come semantica. Non a caso Python usa una keyword apposta per indicare che un "assegnamento" prende valori da un iterabile (for el in a). In Go hanno scelto una cosa diversa... a me piace. anche perche' non "rompe" la sintasi. Nota che range funziona con tutto quello che go considera in qualche modo "iterabile".</div><div><br></div><div>map... map non capisco cosa ci sia da non capire.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>La gestione degli array multidimensionali fa rabbrividire, a momenti è meglio quella di Javascript che pure è atroce. :-)</li></ul></div></div></blockquote><div>?</div><div>Go (come C e parecchi linguaggi la fuori) *non* ha array multidimensionali. Non ce li ha e basta. </div><div>Quello che Go (come C e parecchi linguaggi la fuori) ha, sono *array di array*. </div><div>E' un problema? In generale si. Per dire che vuole fare hpc lo e' in modo indubbio. Verrebbe anche da dire che le ovvie estensioni probabilmente non funzionerebbero troppo bene se si vuole mantenere l'attuale semantica di Go. Pero' la differenza built-in fra array e slice potrebbe proprio essere chiave per farci cose interessanti. Non so... ci devo pensare.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>Interessante la gestione dei canali per lo scambio dei dati tra thread</li></ul></div></div></blockquote><div>E io scommetto che, come a tutti quanti finche' non ci sbattono il muso, non gli sono *davvero* chiari. E non gli e' davvero chiaro perche' e' facile usarli. La differnza fra uno con buffer e uno senza buffer, per dire... etc etc etc.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>defer è un'innovazione, ma che serve in soldoni?</li></ul></div></div></blockquote><div>Esticazzi pero'... come a che serve? Dico ma sono l'unico che ha l'abitudine di pulire le cose che alloca? Lo facevo in C, lo facevo in C++, lo faccio in Python e in Java... big surprise: voglio farlo anche in Go. Visto che RAII e' out of the picture... posso usare goto, certo. Ma veramente... defer e' chiaramente una soluzione superiore.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><li>NOn abbiamo approfondito la questione degli oggetti, ma sempra un'aggiunta alla fine, più object-based che object-oriented. </li></ul></div></div></blockquote><div>O dannazione ancora? Quanto male hanno fatto alle comunita' la propaganda spietata di chi voleva vendere gli oggetti a partire dagli anni 80 e' smodato.</div><div>Tanto per dire... tutt'ora la maggior parte degli sviluppatori in linguaggi ad oggetti non hanno capito la programmazione ad oggetti (che e' un problema). Che e' un formalismo matematicamente mal definito *e* piuttosto complicato da capire. Almeno le typeclasses alla haskell sono si complicate da capire ma sono molto facili da usare. Poi su tutto... chiedi a 10 persone "competenti" e hai 10 definizioni di OOP tutte leggermente diverse. </div><div><br></div><div>E no.. non sono d'accordo che il sistema di tipi di Go sia "un'aggiunta alla fine". Mi sembra anzi qualcosa di molto organico che ha interazioni eccellenti con le altre feature del linguaggio e che e' completamente chiave nel progetto complessivo. Tra l'altro quello che mi piace e' che e' *semplicissimo* da capire tutto quanto. E' proprio facile. Ed e' relativamente difficile da cannare. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Nella
 mia prospettiva da docente e/o curioso, non vedo un grande appeal su 
questo linguaggio che prende un po' dal C classico, python, ruby, java, 
C# e node/javascript ma non ottiene nè codice di facile lettura 
(tutt'altro) nè codice più stringato.</div></div></div></blockquote><div><br></div><div>Boh? "Stringato" non mi sembra un vantaggio... e si, Go non ha come obiettivo battere Perl sui golf. Facile lettura? Non ho *mai* e dico *mai* incontrato un linguaggio piu' facile di Go da leggere. No, nemmeno Python. Cioe', Python 2.2 in un certo punto era altrettanto facile da leggere. Dopo di che e' stato un continuo feature creep che rendono Python tutt'altro che facile da leggere. </div><div><br></div><div>Tutti quelli che considerano Python facile da leggere non devono solo considerare il problema "riesco a rileggere il codice che ho scritto" (problema non banale, certi linguaggi falliscono malamente anche questo). Ma devono considerare anche il problema: riesco a leggere facilmente il codice che un altra persona (che potrebbe essere il Franchi in vena di metaprogramming) scrive? La mia esperienza e' *no*. Tanto e' vero che, per dire, sul lavoro mi contengo. </div><div><br></div><div>Per esempio chi ha *assolutamente* chiaro come funzionano e come interagiscono fra di loro:</div><div><br></div><div>* decoratori (specialmente carina l'interazione con l'ereditarieta' -- consiglio spassionato: se usate dei decoratori, assicuratevi di non avere mai overriding)</div><div>* generatori (e specialmente farci .send -- il tutto anche in presenza di eccezioni)</div><div>* __new__ (e specialmente come si va avanti quando si sottoclassa)</div><div>* metaclassi (differenze e similitudini con __new__... e cosa succede quando si definisce __new__ su qualcosa che ha una metaclasse)</div><div>* __new__ definito *sulla* metaclasse</div><div>* similitudini e differenze fra un classmethod di una classe con una metaclasse e un metodo normale della metaclasse</div><div>* descrittori (e specialmente come interagiscono fra oggetti classe e classi)</div><div>* buffer protocol</div><div>* funzionamento reale delle abc.</div><div><br></div><div>Ora a me la maggior parte della roba la sopra e' "abbastanza" chiara. Ma davvero, ci sono una serie di interazioni sorprendenti tutt'ora. Se sentite di dare il suggerimento: si ma non usare feature x, forse dovrebbe essere chiaro che Python non e' cosi' leggibile come sembra. Poi certo, se avessi fatto una lista per altri linguaggi sarebbe stata molto piu' lunga.</div><div><br></div><div>D'altra parte Go non ha (al momento) *nessuna* feature complicata. Non ce l'ha. Quando il codice Go e' complicato, e' perche' il problema che si sta risolvendo e' complicato.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div> Qual è quindi la "mission" del 
linguaggio? Forse è quella della massima portabilità e velocità di 
esecuzione, ma questo non abbiamo potuto provarlo - forse in futuro?"</div></div></div></blockquote><div><br></div><div>Davvero? Cioe' quale e' la mission?</div><div><br>"""</div><div><span style="font-family:Helvetica,Arial,sans-serif;font-size:20px">Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.</span><br></div><div>"""</div><div><br></div><div>Ma diciamo che e' uno slogan e uno non ha aperto la homepage del sito. Diciamo anche che effettivamente non vuole dire una fava: concordo. Visto che nessuno direbbe che ha fatto un linguaggio che dichiara avere scritto per creare "overly complicated, unreliable and inefficient software". Sebbene, per intenderci, PHP matcha abbastanza la definizione. </div><div><br></div><div>Ecco... diciamo che e' complicato non accorgersi che Go nasce con l'idea di rendere umano risolvere problemi di concorrenza. Ora, siccome *tutto* il software a venire dovra' risolvere problemi di concorrenza... fate voi.</div><div><br></div><div><br></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>