Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-13 17:49 GMT+02:00 enrico franchi enrico.fran...@gmail.com: Io credo che quello che puoi facilmente fare e' invece separare a livello di architettura invece che a livello di codice. E.g., hai un set di API rest servite da Go e un layer sottile in Python che chiama le API. Poi, detto fra noi... sta roba viene fatta meglio ammazzando suddetto layer e facendo tutto con opportuno javascript. Infatti none ra quello il motivo del wrapping. Per il progetto attuale le cose pesanti sul piano concorrenzialita' ma piccole sul piano di cosa fanno (esempio registrare che l'utente con il mac address si e' collegato sul router con uuid sul db PG dove ho una tabella a 4 (oltre id) campi di cui uno e' automatico (timestamp registrazione record aka inizioo connessione) e un'altro lo devo updatare (da altra chiamata) quando la connessione termina) le valutavo in Go, mentre per cose piu' impegnative sul fronte di carico ma complesse come elaborazioni, Python. Il wrap era riferito a casi come quelli in cui si wrappa tipo wxwidgets Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-12 18:42 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: Chiamare Go da Python. Cosi' le parti critiche potrebbero essere gestite da Go e le cose che faccio meglio in Python le faccio in Python appunto. Mah, dipende cosa vuoi fare, davvero. Allora... in Go 1.5 sara' piuttosto facile chiamare Go da C (e non solo C da Go), il che fa pensare che chiamarlo da Python non sara' un gran sbattimento. La questione e' l'opportunita': non ho ancora guardato la draft dell'1.5 in questo dettaglio... ma in generale Go e' concepito come linguaggio per sviluppare sistemi piuttosto che come linguaggio per implementare librerie per altri sistemi. Molti dei punti di forza di Go non hanno facili map 1:1 in altri linguaggi e di conseguenza non mi e' chiaro quale sia il punto di fare esattamente quello. Io credo che quello che puoi facilmente fare e' invece separare a livello di architettura invece che a livello di codice. E.g., hai un set di API rest servite da Go e un layer sottile in Python che chiama le API. Poi, detto fra noi... sta roba viene fatta meglio ammazzando suddetto layer e facendo tutto con opportuno javascript. Diciamo che il problema e' che non ho identificato molti problemi che Python risolve meglio di Go, con alcune eccezioni, e se guardi la lista delle eccezioni non e' che si presti molto a fare quello che vuoi fare: * calcolo scientifico (a la notebook + pandas + roba sottostante): diciamo prototipi di da data scientist * gui apps Il resto per me lo fa oggettivamente meglio Go. Hai un hit relativamente piccolo in termini di produttivita' sul codice, piu' che compensato da tutto quello che riguarda le operations (dal deploy in su). Per il resto... -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
On Jul 12, 2015 6:58 PM, enrico franchi enrico.fran...@gmail.com wrote: Io posso dire che Python sufficientemente vecchio era molto leggibile. Leggibile perche' aveva meno features e soprattutto meno features complesse. Piano piano le hanno aggiunte, e' tutta roba molto potente e interessante, ma alla fine dei conti e' anche tutta roba che rende il codice relativamente troppo complicato da capire per essere considerato leggibile. Intervengo per un piccolo commento: credo di aver capito cosa intendi, ma secondo me la complessità e la leggibilità di un linguaggio non sono legate in quel senso. Un linguaggio leggibile è leggibile sempre, anche se trovare bachi alle 3 di notte può essere complesso. La leggibilità penso che sia legata anche alla capacità del linguaggio di presentarsi in modo familiare e intuitivo, anche attraverso della complessità che nasconde dettagli non rilevanti alla comprensione generale. Faccio un esempio scemo: il costrutto with è molto utile e potente. Ciò che ci sta dietro è relativamente complesso (NB è un esempio scemo!) e di fatto la complessità viene mascherata dal costrutto e dalle magie che ci son dietro. Ora, se uno nasconde una cosa molto complessa dietro with, magari debuggers alle 3 di notte è una menata perché tu *sai* che c'è dietro della complessità e che magari il baco sta lì. Però guardare il codice è capire che with ti crea un contesto che viene aperto e chiuso è un concetto piuttosto immediato, quindi quando leggi il codice capisci in fretta cosa si cerca di fare. Forse tu parli di leggibile ma vuoi dire palese o esplicito mentre io dico veloce farsi un'idea. Però questo non vuol dire che non ci possa essere dietro della complessità che viene nascosta per rendere, appunto, tutti leggibile. Se ho fatto typos è perché son dal cellulare, abbiate pazienza :p ~Ale ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Un interessante quesito che e' alla fine e' venuto fuori dalla lista CPYG-BO Che voi sappiate qualcuno sta usando Go per scrivere software di sistema famosi (o noti, con buone prospettive) ? Qualcuno ha risposte? La domanda scaturisce dal discorso C vs Go, con il primo usatissimo ancora per scrivere OS o sistemi embedded. Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 12/07/2015 19:26, enrico franchi ha scritto: Tipo... 90.000 connessioni aperte simultaneamente? Ma dai, diciamo proprio di no. Non e' che non *puoi* farlo. E' che e' proprio una cattiva idea farlo *a meno che non devi proprio farlo*. Tipicamente tutte le volte che assumi che qualcosa sia gratuito e illimitato, prima o poi qualcuno ti fara' scoprire che non e' cosi' (corollario: di solito questa cosa accade in un'altra time-zone, quando uno avrebbe preferito dormire invece di scoprire nuove cose). Non c'è alcuna spiegazione su come deve funzionare il sistema di Carlos per cui sono stato molto generico. Ho giusto scritto cosa Go può raggiungere senza troppo sbattimento, chiaramente a scopo di paragone con Python. Dipende da quale è il suo bisogno, ha parlato di alcune decine di migliaia di router da gestire. Se è un progetto serio avrà un budget e l'aiuto di colleghi, eventualmente un sistemista. Ovvio che si può fare distribuendo il carico su più server, che è probabilmente la soluzione migliore sotto diversi punti di vista, non c'è bisogno di correre di notte. Questo tizio ha raggiunto 600.000 connessioni per processo con 16GB di RAM e il vecchio Go 1.0.3, che è molto più di 90.000 connessioni. Il GC da allora è migliorato sensibilmente: https://groups.google.com/forum/#!searchin/golang-nuts/Garbage$20collecting/golang-nuts/S9goEGuoMRM/FZyd2M6uiVMJ In generale e' davvero molto piu' semplice usare logiche di pool rispetto che fare 90.000 goroutine. Sono d'accordo. A Qihoo 360 hanno comunque raggiunto 1 milione di connessioni/server prima di passare ai pool, sempre con Go 1.0.3. Dubito che Carlos debba creare un sistemone del genere, probabilmente gli basta molto ma molto meno. Tipicamente se uno fa ste cose a cuor leggero la prima cosa che scopre e' che ha un problema con il garbage collector, per dire. Basta fare una spike solution per vedere quali numeri ottiene. Python mi pare meno adatto per queste cose, se lo deve fare con quello probabilmente si trova con limiti ancora maggiori. Puoi usare tutte le CPU a disposizione fin da subito senza scrivere codice aggiuntivo. Ora... il codice aggiuntivo e' piccolo, ma di per se Go 1.4 se non gli dici altrimenti usa *una* CPU. Hai ragione, è una riga di codice all'inizio del programma per dire quante CPU usare. Quello che intendo è che non deve modificare come funziona il proprio codice, tipo per usare il multiprocessing in Python. Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 12/07/2015 19:42, Carlos Catucci ha scritto: Chiamare Go da Python. Cosi' le parti critiche potrebbero essere gestite da Go e le cose che faccio meglio in Python le faccio in Python appunto. Si perderebbero molte performance convertendo i dati da un ambiente all'altro. Dubito che convenga farlo. Puoi comunque mettere in piedi una queue con RabbitMQ, oppure in maniera più leggera con Redis, e creare dei worker in Go. Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-13 1:35 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net: Si perderebbero molte performance convertendo i dati da un ambiente all'altro. Dubito che convenga farlo. Allora perhe' sio wrappano programmi C/C++? Puoi comunque mettere in piedi una queue con RabbitMQ, oppure in maniera più leggera con Redis, e creare dei worker in Go. Interesante ma sono tecnologie di cui per ora non so nulla. Appena avro' tempo (mai se non cambia qualcosa) ci guardo Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 20:16 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: 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. Una persona normale, intendo dire un vdeveloper, fa fatica anche a capire la meta' delle cose che dice il Franchi, ovvio che se si mette a programmare ad alto livello, seguendo fili logici che un comune mortale (o una comune mortadella come me) neppure riesce a immaginare nei suoi viaggi dopo avere tagliato una punta di acido, non capisca una cippa del codice. Pero' codice del Franchi a parte io sono sempre riuscito a leggere e capire piu' o meno al volo codice Python scritto da altri. Non conosco Go (ma voglio studiarlo se solo ho un poco di respiro) per cui non posso dire se sarei capace di leggerlo altrettanto semplicemente. Con Python, nella stessa situazione pero', non ho avuto problemi a leggere il rpimo listato (e non era un fibonacci o simili ma una applicazione complessa). Si, in realta' buona parte del mio codice *non* usa (o fa un uso molto limitato) di suddette features, e non faccio passare codice che ne abusa. Il discorso non e' quanto avanzato e' il mio python rispetto a quello del programmatore medio. Il problema e' che Python e' leggibile se e solo se non si usano (o abusano) determinate features. Altrimenti e' leggibile per un sottoinsieme ristretto di persone e *soprattutto* non e' il codice che vuoi guardare alle 3 di mattina quando sei stato svegliato perche' l'applicazione e' rotta. Non vuoi farlo se il codice e' tuo, non vuoi farlo se il codice e' di qualcun altro. Ma se cominci a dire che il linguaggio e' leggibile se non usi feature x e y comincia ad indebolirsi molto il fatto che il linguaggio sia leggibile. Perche' restringendo arbitrariamente il sottoinsieme di linguaggio leggibile, tutto sommato parecchi linguaggi non patologicamente illeggibili diventano leggibili. E anche alcuni linguaggi patologici. Io posso dire che Python sufficientemente vecchio era molto leggibile. Leggibile perche' aveva meno features e soprattutto meno features complesse. Piano piano le hanno aggiunte, e' tutta roba molto potente e interessante, ma alla fine dei conti e' anche tutta roba che rende il codice relativamente troppo complicato da capire per essere considerato leggibile. Il motivo per cui tutto sommato la maggior parte del codice Python la fuori e' sempre considerato leggibile e' che la maggior parte dei programmatori non abusano troppo di queste features (per scelta o per ignoranza). Ma di per se, il problema e' presente. Poi abbi pazienza, lui e' un prof delle superiori, ha come target ragazzi di 14/18 anni che si avvicinano alla programmazione, non un tale che lavora per una non meglio specificata $bigcompany. Si, ma niente da dire su di *lui*. Quello che io sto dicendo e' che *a mio avviso* Go e' piu' leggibile di Python. Almeno per ora. Poi certo, se e quando cominceranno a farcirlo di features fichissime (ma complicate) anche lui sara' molto meno leggibile. Insomma, per fare un altro paragone... Haskell e' un linguaggio *estremamente* leggibile. Ha regole piuttosto rigorose sulla formattazione, etc etc etc. Pero'... diciamo che se uno non mastica alcuni concetti relativamente poco intuitivi non si va troppo lontano. Non ho vergogna ad ammettere che spesso e volentieri quando leggo codice scritto da gente che fa Haskell duro non capisco davvero un accidente, ma e' un modo diverso di non capire che cavolo fa rispetto a quando mi danno il classico blobbone da 2000 righe di Perl da riscrivere in qualcos'altro. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-11 11:40 GMT+01:00 Davide Muzzarelli d.muzzare...@dav-muz.net: Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire circa 90.000 connessioni aperte simultaneamente. Come dire... occhio pero'. Tutte le volte nella storia dell'informatica che qualcuno ha convinto qualcun altro che qualcosa fosse essenzialmente gratuito, ci sono stati tanti ingegneri a correrre la notte e tanti sistemi riscritti. Tipo... 90.000 connessioni aperte simultaneamente? Ma dai, diciamo proprio di no. Non e' che non *puoi* farlo. E' che e' proprio una cattiva idea farlo *a meno che non devi proprio farlo*. Tipicamente tutte le volte che assumi che qualcosa sia gratuito e illimitato, prima o poi qualcuno ti fara' scoprire che non e' cosi' (corollario: di solito questa cosa accade in un'altra time-zone, quando uno avrebbe preferito dormire invece di scoprire nuove cose). Vuoi tenere 90K connessioni aperte? Metti conto che: TCP ha bisogno di bookeeping nel kernel. 90K descrittori sono proprio tanti. A questo punto devi tenere traccia di quali connessioni sono buone e quali non sono buone (cosa non banale... TCP Keepalive offre qualcosa di diverso e farlo a mano e' noioso... HTTP keepalive e' una cosa diversa ancora, ma e' piuttosto delicata e spesso si spacca... in pratica non e' un caso come funzionano i vari pool di connessioni http -- che per dire, Go stesso offre senza dirlo in modo troppo esplicito). In generale e' davvero molto piu' semplice usare logiche di pool rispetto che fare 90.000 goroutine. Tipicamente se uno fa ste cose a cuor leggero la prima cosa che scopre e' che ha un problema con il garbage collector, per dire. Puoi usare tutte le CPU a disposizione fin da subito senza scrivere codice aggiuntivo. Ora... il codice aggiuntivo e' piccolo, ma di per se Go 1.4 se non gli dici altrimenti usa *una* CPU. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 12/lug/2015 14:30, Davide Muzzarelli d.muzzare...@dav-muz.net ha scritto: Ecco qui di seguito una lista non ordinata. Mi permetto di aggiungere uno dei progetti con la codebase Go più estesa in circolazione: https://github.com/golang/go Ciao M. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-11 12:18 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: Verdad, la gestione e' semplficata, ma la leggibilita' lo diventa solo quando hai capito come funzionano. Il Try Except Finally Else di Python e' immediato. Tranen forse Else ecco. Che comunque trovo comodissimo da avere. Dici? Non so... statisticamente parecchia gente ci mette un bel po' di tempo prima a capire cosa siano le eccezioni e ancora di piu' per usarle come si deve. Poi certo, se hai capito le eccezioni in Python probabilmente ti adatti facilmente alle eccezioni in Java o C++ (e viceversa), ma non e' che sia un concetto naturalmente semplice. E' solo un concetto che spesso si ha gia'. Per inciso, pensa a tutto il tempo che i niubbi spendono scrivendo *male* il codice che usa le eccezioni (variando da: ricondurle appena possibile a gestione con valori di ritorno -- oppure la variante: cercare di evitarle facendo [male] LBYL; grosso modo ignorarle quando non dovrebbero; catturare troppa roba e mascherare bachi logici con gestione dell'errore troppo generica). Generalmente io trovo che capire il punto nel call stack in cui e' ottimale gestire un'eccezione non e' affatto banale. Anche perche' ci sono due aspetti distinti che sono riuniti nella variante castrata di eccezioni che ha Python, che sono appunto gestire l'errore essenzialmente lato utente e pulire lo stato dell'applicazione. E queste due cose sono legate in modo indissolubile e spesso bisogna o usare contorsioni logiche oppure accettare codice inutilmente inefficiente. Ma un wrapper per codice Go da Python non lo hanno mai pensato? Io non so se sariei capace di scriverlo, ma lo troverei utile. Cosa intendi? Vuoi chiamare Go da Python o Python da Go? O cosa altro avevi in mente? -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-11 12:40 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net: E' come in finally, con la differenza che puoi metterli nel punto dove preferisci e non devi creare dei livelli d'identazione quando ne devi creare più di uno. In sostanza sono più comodi e semplici da utilizzare rispetto ai finally. Verdad, la gestione e' semplficata, ma la leggibilita' lo diventa solo quando hai capito come funzionano. Il Try Except Finally Else di Python e' immediato. Tranen forse Else ecco. Che comunque trovo comodissimo da avere. Go sarebbe adatto per quel progetto. Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire circa 90.000 connessioni aperte simultaneamente. Puoi usare tutte le CPU a disposizione fin da subito senza scrivere codice aggiuntivo. Sicuramente farai prima a scriverlo in Python che in Go, anche perché dovresti imparare ad usarlo. Valuta tu se hai bisogno di quelle performance. Forse non ne avro' bisogno, ma e' una ottima occasione per poterlo studiare e usare su un progetto reale. In fondo essendo una serie di Web Services che in comune hanno solamente la base dati, posso benissimo lasciare in Python (sempre riscrivendo per Flask) le parti piu' incasinate come logiche ma che hanno meno richieste di performance (esempio la registrazione dell'utente che si ha solo la prima volta che installa la app) e scrivere in Go quelle dove invece performance etc. sono vitali. Ma un wrapper per codice Go da Python non lo hanno mai pensato? Io non so se sariei capace di scriverlo, ma lo troverei utile. Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 10/07/2015 21:27, Carlos Catucci ha scritto: Scusa solo per capire, dov'e' la differenza con try except? E comunque tu indich defer (non lo conosco bene) subito dopo avere aperto. Implica che verra' eseguito COMUNQUE (tipo finally per capirci) alla fine della funzione? Se si e' davvero una cosa buona. E' come in finally, con la differenza che puoi metterli nel punto dove preferisci e non devi creare dei livelli d'identazione quando ne devi creare più di uno. In sostanza sono più comodi e semplici da utilizzare rispetto ai finally. Go è un linguaggio che ha i suoi difetti ma sono veramente pochi, anche Python e C hanno i loro difetti eh. Beh nessuno e' perfetto (tranne Andy ;P). :) Comunque si penso che per certe cose sia interessante. Gia' intendevo riscrivere con Flask i web services del progetto. Se i boss non mi farranno girare le palle al punto da essere sfanculati, potrei pensare di ricriverene una buona parte in Go. In particolair quelli che gestiranno le connessioni/disconnessioni degli utenti sui router. (*) * Trattasi di rete wifi free dove chi entra si connette come se fosse la rete di casa. Questo comporta che io debba far registrare dati provenienti dai vari router (si conta a progetto avviato di averne qualche decina di milgiaia) tutti i casi di connessione/disconnessione che potrebbe essere un problema non da poco con Python (ce la fara' a reggere? Potrebbero arrivare in pochi secondi un numero elevatissimo di segnalazioni). Go sarebbe adatto per quel progetto. Ogni gorutine (simile ai thread) occupa 4kb. In 350MB di RAM puoi gestire circa 90.000 connessioni aperte simultaneamente. Puoi usare tutte le CPU a disposizione fin da subito senza scrivere codice aggiuntivo. Sicuramente farai prima a scriverlo in Python che in Go, anche perché dovresti imparare ad usarlo. Valuta tu se hai bisogno di quelle performance. Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 21:27 GMT+02:00 Carlos Catucci carlos.catu...@gmail.com:
2015-07-10 20:21 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
In questo esempio, il file verrebbe chiuso correttamente anche nel caso
in cui f.Write() restituisse un errore:
f, _ := os.Open(nome del file)
defer f.Close()
n, err := f.Write(foobar)
if err != nil {
return Errore, spazio su disco esaurito
}
Scusa solo per capire, dov'e' la differenza con try except?
Che try/except aggiungono un ulteriore livello di nidificazione che rende
la lettura del codice meno lineare.
Ad esempio:
try:
makedirs(path)
except OSError, err
if err.errno == errno.EEXISTS:
return
raise
Il maggiore problema con le eccezione è semplicemente che tu *non puoi
sapere* se e quale eccezione può lanciare una funzione.
In C++ e Java ci hanno provato [1], ma non funziona.
In Go lo sai semplicemente vedendo cosa restituisce la funzione.
[...]
[1] https://en.wikipedia.org/wiki/Exception_handling#Checked_exceptions
Ciao Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
On 07/10/2015 08:21 PM, Davide Muzzarelli wrote: - Piatto è meglio che annidato - Sparso è meglio che denso Per capire, cosa intendi? Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 11/07/2015 19:09, Simone Federici ha scritto: per te, che lo scrivi ma il codice è letto in media 50 volte in piú a quanto viene scritto. Il fatto è che scrivendo metti il defer nel posto migliore a livello logico proprio dove te lo aspetteresti. Le funzioni in Go tendono ad essere piuttosto corte e bisogna tenere conto anche di questo. e avere un try finally che puoi mettere a caso nel codice non mi sembra una buona pratica La maniera più naturale è mettere il defer nel posto giusto, per scriverlo in un posto a caso bisogna proprio farlo apposta. ps: io sono più x i context manager che supportano un unico punto di indentazione anche usati multipli Concordo che context manager sono una gran cosa! :) Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Davide Muzzarelli: E' come in finally, con la differenza che puoi metterli nel punto dove preferisci e non devi creare dei livelli d'identazione quando ne devi creare più di uno. ok capito In sostanza sono più comodi e semplici da utilizzare rispetto ai finally. per te, che lo scrivi ma il codice è letto in media 50 volte in piú a quanto viene scritto. e avere un try finally che puoi mettere a caso nel codice non mi sembra una buona pratica ps: io sono più x i context manager che supportano un unico punto di indentazione anche usati multipli -- Simone Federici Software Craftsman XP, Agile, Scrum, Kanban Quality, performance security Explicit is better than implicit. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 11/07/2015 19:02, Simone Federici ha scritto: molto molto fico, lo compro :-) LOL :D Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 11/07/2015 15:50, Enrico Bianchi ha scritto: Per capire, cosa intendi? Una traduzione sommaria e imprecisa dello zen di Python, che avrei potuto fare meglio :p I metodi in Go sono alla stessa indentazione delle classi, in effetti si tratta di funzioni collegate a strutture. Lo stile idiomatico di Go incoraggia l'uso di funzioni piccole, moduli altrettanto piccoli molto specializzati e aggregazione. Le interfacce, come sono pensate in Go, aiutano molto il riuso di codice in grandi progetti. Alla fine ci si ritrova in maniera naturale ad avere pochi livelli d'indentazione, funzioni con pochi argomenti e moduli con poche strutture. Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Carlos Catucci wrote: Attendo risposte (che con il vostro permesso riportero' all'esimio prof, nonche' amico di vecchia data) Quanto avrei da dire è piuttosto negativo, sia sulla valutazione che sul metodo usato per arrivarci, quindi non dirò nulla per non offendere l'esimio prof nonché amico di vecchia data. :-P -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 10/07/2015 16:19, Carlos Catucci ha scritto:
Attendo risposte (che con il vostro permesso riportero' all'esimio prof,
nonche' amico di vecchia data)
Uso Go in produzione da un anno e mezzo circa, in poco tempo ho
sviluppato un software per gestire i prodotti di un eCommerce più
qualche altro tool per me (server SMPP, websocket e altre cose più piccole).
Il programma ha diverse funzioni sia come server web che da linea di
comando, lavora su 3 database diversi contemporaneamente (Postgresql,
MSSQL e MySQL) per gestire dati tra Microsoft Navision, Magento e dati
aggiuntivi suoi. Ha interfacce web e CLI, non ho dovuto usare alcun
framework, è estremamente veloce rispetto a Python, consuma un decimo
della memoria che consuma Python e non ha i problemi di GIL.
* 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.
La sintassi è presa a piene mani dal C. L'obiettivo era permettere ai
neo-laureati, che solitamente hanno studiato C a scuola, di essere
subito produttivi in pochi giorni.
In pratica è come un C fatto per chi viene da linguaggi di scripting.
* 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à. Carini anche se non
immediati i vari range, map, un po' presi da python e ruby.
then non esiste in Go.
if è identico agli altri linguaggi tranne la possibilità opzionale di
creare un'assegnazione con scopo privato, e mi pare molto chiara come
espressione dato che la logica sarebbe prima di creare una variabile e
poi di usarla:
if err := eseguiQualcosa(); err != nil {
...
}
switch/case è simile ad altri linguaggi, molto facile da leggere:
switch valore {
case vero:
return true
case falso:
return false
default:
return nil
}
map è un semplice hash:
numeri := map[string]int{
uno: 1,
due: 2,
tre: 3,
}
print(numeri[uno])
range è completamente diverso da Python.
Python: for x in tupla
Go: for k, v := range tupla
* La gestione degli array multidimensionali fa rabbrividire, a momenti
è meglio quella di Javascript che pure è atroce. :-)
In Go puoi solo avere array di array.
* Interessante la gestione dei canali per lo scambio dei dati tra thread
E' un pattern e lo hanno implementato in maniera molto comoda da usare e
prevenendo i soliti errori comuni, in effetti ha semplificato
notevolmente l'uso di parallelismo e concorrenza.
* defer è un'innovazione, ma che serve in soldoni?
defer è estremamente utile per scrivere software stabile, serve quando
vuoi essere sicuro che venga eseguita una funzione anche in caso di errore.
Un esempio banale è quando vuoi essere sicuro che venga chiuso un
descrittore di un file o una connessione dopo averlo aperta.
In questo esempio, il file verrebbe chiuso correttamente anche nel caso
in cui f.Write() restituisse un errore:
f, _ := os.Open(nome del file)
defer f.Close()
n, err := f.Write(foobar)
if err != nil {
return Errore, spazio su disco esaurito
}
Inoltre aiuta nella lettura del programma perché in questo modo le
operazioni di apertura sono vicine alle funzioni di pulizia e chiusura.
Se le funzioni fossero lontane, tipo le prime all'inizio della funzione
e le altre alla fine, diventerebbe più facile commettere errori o
dimenticarsi qualcosa inoltre si dovrebbe scrivere il codice per pulire
e chiudere anche in caso di errore.
* NOn abbiamo approfondito la questione degli oggetti, ma sempra
un'aggiunta alla fine, più object-based che object-oriented.
Go è decisamente object-oriented e non object-based e lo è usando il
pattern dell'aggregazione al posto di quello dell'editarietà.
Go ha array, scalari ecc. che non sono per niente oggetti.
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. Qual è quindi la mission del
linguaggio? Forse è quella della massima portabilità e velocità di
esecuzione, ma questo non abbiamo potuto provarlo - forse in futuro?
Go prende direttamente dal C, ben poco da altri linguaggi.
Ancora non è pronto per applicazioni GUI per scarsità di librerie oppure
per applicazioni web nella maniera classica perché la tipizzazione
statica diventa scomoda da usare rispetto a Python/Ruby.
Go è una via di mezzo tra il C e il Python, attrae molti più
programmatori da Python che da C/C++.
La sintassi è semplice con pochi costrutti, molto chiara, il codice
viene pulito e identato direttamente
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 15:19 GMT+01:00 Carlos Catucci carlos.catu...@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
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 20:21 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
In questo esempio, il file verrebbe chiuso correttamente anche nel caso in
cui f.Write() restituisse un errore:
f, _ := os.Open(nome del file)
defer f.Close()
n, err := f.Write(foobar)
if err != nil {
return Errore, spazio su disco esaurito
}
Scusa solo per capire, dov'e' la differenza con try except? E comunque tu
indich defer (non lo conosco bene) subito dopo avere aperto. Implica che
verra' eseguito COMUNQUE (tipo finally per capirci) alla fine della
funzione? Se si e' davvero una cosa buona.
Go è un linguaggio che ha i suoi difetti ma sono veramente pochi, anche
Python e C hanno i loro difetti eh.
Beh nessuno e' perfetto (tranne Andy ;P). Comunque si penso che per certe
cose sia interessante. Gia' intendevo riscrivere con Flask i web services
del progetto. Se i boss non mi farranno girare le palle al punto da essere
sfanculati, potrei pensare di ricriverene una buona parte in Go. In
particolair quelli che gestiranno le connessioni/disconnessioni degli
utenti sui router. (*)
* Trattasi di rete wifi free dove chi entra si connette come se fosse la
rete di casa. Questo comporta che io debba far registrare dati provenienti
dai vari router (si conta a progetto avviato di averne qualche decina di
milgiaia) tutti i casi di connessione/disconnessione che potrebbe essere un
problema non da poco con Python (ce la fara' a reggere? Potrebbero arrivare
in pochi secondi un numero elevatissimo di segnalazioni).
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 18:49 GMT+02:00 enrico franchi enrico.fran...@gmail.com: 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. Una persona normale, intendo dire un vdeveloper, fa fatica anche a capire la meta' delle cose che dice il Franchi, ovvio che se si mette a programmare ad alto livello, seguendo fili logici che un comune mortale (o una comune mortadella come me) neppure riesce a immaginare nei suoi viaggi dopo avere tagliato una punta di acido, non capisca una cippa del codice. Pero' codice del Franchi a parte io sono sempre riuscito a leggere e capire piu' o meno al volo codice Python scritto da altri. Non conosco Go (ma voglio studiarlo se solo ho un poco di respiro) per cui non posso dire se sarei capace di leggerlo altrettanto semplicemente. Con Python, nella stessa situazione pero', non ho avuto problemi a leggere il rpimo listato (e non era un fibonacci o simili ma una applicazione complessa). Poi abbi pazienza, lui e' un prof delle superiori, ha come target ragazzi di 14/18 anni che si avvicinano alla programmazione, non un tale che lavora per una non meglio specificata $bigcompany. Pero' come sempre leggere le tue considerazioni aiuta a aprirsi la mente. Aggiungo che ci contavo un poco di leggere cose rispondevi, una benevola provocazione da parte mia girare qui quella mail. Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
Il 10/07/2015 16:47, Nicola Larosa ha scritto: Carlos Catucci wrote: Attendo risposte (che con il vostro permesso riportero' all'esimio prof, nonche' amico di vecchia data) Quanto avrei da dire è piuttosto negativo, sia sulla valutazione che sul metodo usato per arrivarci, quindi non dirò nulla per non offendere l'esimio prof nonché amico di vecchia data. :-P Già. Il fatto che abbiano messo nei parametri delle funzioni i tipi dopo ai nomi delle variabili ha spiazzato anche me. Con gli occhi del pythonista probabilmente go non sembra granchè (forse fa anche un pò male agli occhi) ma con gli occhi da sviluppatore C dici: ah le slice mica male, e il defer mi aiuta a non dover usare goto e label per gestione errori, etc... -- Riccardo Magliocchetti @rmistaken http://menodizero.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG
2015-07-10 16:47 GMT+02:00 Nicola Larosa n...@teknico.net: Quanto avrei da dire è piuttosto negativo, sia sulla valutazione che sul metodo usato per arrivarci, quindi non dirò nulla per non offendere l'esimio prof nonché amico di vecchia data. :-P dai dai.. illuminaci :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
