[Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG

[enrico franchi]

2015-07-10 15:19 GMT+01:00 Carlos Catucci <carlos.catucci a gmail.com>:

Riporto quanto espresso sulla lista XPUG-BO dal prof. Marcello "Piffy"
> Missiroli.
>
> "Un mio commento a freddo sulla serata (che è stata molto carina, anche
> nel post-evento)
>
> 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.
>

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.
In particolare parecchie delle questioni che segnala sono cose che si
chiariscono affrontando un progettino giocattolo. Sono li e hanno senso.



> In sintesi, non è che mi abbia molto convinto.
>
>
>    - 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.
>
> 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.

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.
Ci sono un po' di spiegazioni di queste problematiche sulle faq.

Ora, queste cose ad occhio non e' che mi aspetti che le veda.

E quella li *non* e' una dichiarazione. Cioe', si, formalmente e' una
dichiarazione. Ma la parte di dichiarazione e' semplicemente

x := <expr>

il fatto che expr sia un type cast... beh, vabbe'. ma non e'
particolarmente diverso da fare x = int(y) in Python.


>
>    - 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à.
>
> E come dire... l'assegnamento li serve per idiomi estremamente comuni:

if a, err := build_a(...); err != null {
   defer clean_a(a)
}


>
>    - Carini anche se non immediati i vari range, map, un po' presi da
>    python e ruby.
>
> Anche qui... cosa non abbia di immediato range non lo so. Ricordiamoci che
esplicito e' bello. Vogliamo iterare su un array?

for el := arr {

}

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.

Questo invece compila:
     for el := a;; {

    fmt.Println(el)
      }

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".

map... map non capisco cosa ci sia da non capire.



>
>    - La gestione degli array multidimensionali fa rabbrividire, a momenti
>    è meglio quella di Javascript che pure è atroce. :-)
>
> ?
Go (come C e parecchi linguaggi la fuori) *non* ha array multidimensionali.
Non ce li ha e basta.
Quello che Go (come C e parecchi linguaggi la fuori) ha, sono *array di
array*.
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.

>
>    - Interessante la gestione dei canali per lo scambio dei dati tra
>    thread
>
> 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.

>
>    - defer è un'innovazione, ma che serve in soldoni?
>
> 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.

>
>    - NOn abbiamo approfondito la questione degli oggetti, ma sempra
>    un'aggiunta alla fine, più object-based che object-oriented.
>
> 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.
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.

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.



> 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.
>

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.

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.

Per esempio chi ha *assolutamente* chiaro come funzionano e come
interagiscono fra di loro:

* decoratori (specialmente carina l'interazione con l'ereditarieta' --
consiglio spassionato: se usate dei decoratori, assicuratevi di non avere
mai overriding)
* generatori (e specialmente farci .send -- il tutto anche in presenza di
eccezioni)
* __new__ (e specialmente come si va avanti quando si sottoclassa)
* metaclassi (differenze e similitudini con __new__... e cosa succede
quando si definisce __new__ su qualcosa che ha una metaclasse)
* __new__ definito *sulla* metaclasse
* similitudini e differenze fra un classmethod di una classe con una
metaclasse e un metodo normale della metaclasse
* descrittori (e specialmente come interagiscono fra oggetti classe e
classi)
* buffer protocol
* funzionamento reale delle abc.

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.

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.



> Qual è quindi la "mission" del linguaggio? Forse è quella della massima
> portabilità e velocità di esecuzione, ma questo non abbiamo potuto provarlo
> - forse in futuro?"
>

Davvero? Cioe' quale e' la mission?

"""
Go is an open source programming language that makes it easy to build
simple, reliable, and efficient software.
"""

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.

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.




-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150710/2574f0d3/attachment-0001.html>