[Python] Python innovation -- no longer OT --[Re: OT ma interssante]
2015-07-17 14:53 GMT+01:00 enrico franchi enrico.fran...@gmail.com: Per il resto, davvero, non vedo come possiamo continuare la discussione con un minimo di interesse Ora... facciamo un po' di esercizio. Per esempio cerchiamo di applicare il concetto di innovazione a qualcosa che tutti conosciamo. Python. La domanda e' Python e' innovativo? Non daro' una risposta, ma un po' di spunti. Breve contesto... Python e' un linguaggio vecchio, da un certo punto di vista. Ma non e' cosi' vecchio da potere essere annoverato fra i pionieri. Per dire... la parte ad oggetti di Python non e' particolarmente innovativa. Le versioni vecchie (2.2) non avevano le new style classes. Tutta questa parte non e' particolarmente innovativa: Smalltalk faceva probabilmente altrettanto se non di piu' 20 anni prima. Lisp come sopra. Lisp aveva pure il concetto di MOP, che in Python fino a 1.5 era implementabile con molta fatica (e uscendo da Python) e fino all'introduzione delle metalcassi e' stato disponibile con fatica. Anche qui, la versione del MOP di Python non e' piu' elegante o piu' potente di quella di Lisp. Il fatto che funzioni siano valori non e' particolarmente innovativa. Lisp aveva questa cosa da 40 anni o giu' di li. map/filter e compagnia? Ancora Lisp. List comprehensions? Haskell e probabilmente altri. Generatori base? Anche li c'e' parecchia prior art (se guardi la PEP ti dicono anche esattamente cosa). Ad essere onesto, e' prior art meno celebre di Haskell o Lisp, ma ancora una volta... I generatori completi che abbiamo ora? Un po' piu' innovativi... ma non sono altro che una versione castratissima delle continuation di Scheme (e di altri linguaggi che le hanno) e in generale non sono nulla di nuovo. Altri hanno avuto cose simili tutte insieme. Il descriptor protocol? Quello mi sembra piuttosto nuovo. Ma, dal mio punto di vista, e' una cosa relativamente implementativa. Ti consente di scrivere codice piu' coinciso in determinate circostanze, ma di per se non rende il linguaggio piu' potente. Ti consente di fare certe cose (che si fanno di rado) in modo un po' piu' semplice. Decoratori? Davvero... qui c'e' parecchia prior art. Troppa per entrarci. Ottima implementazione (peccato che Python sia anche un linguaggio con ereditarieta' e che le due cose facciano a cazzotti in modo spettacolare: se non ve ne siete accorti, meditate). Ma innovativo? Il fatto che il programmatore Java non li avesse non li rende certo innovativi... oh, ma dannazione... i Javisti avevano le annotazioni, con una sintassi molto simile, relativamente piu' raffinati, ma molto piu' complicati da usare per determinate cose che invece in Python sono molto semplici. Innovativi? Boh... effettivamente e' qualcosa che anche i laymen hanno preso su da subito. Fra tutte le features elencate sono probabilmente la piu' banale, la meno interessante, la meno innovativa... eppure hanno avuto un impatto colossale sulla comunita'. Tanto per dire. Per il resto... cpython e' implementato con una macchina a stack. Piuttosto banale, per inciso. Non e' funzionalmente troppo diversa dalle implementazioni giocattolo che si scrivono in un paio di pomeriggi. Il compilatore non fa ottimizzazione nemmeno a parlarne (e' tipo anni indietro rispetto quello che fanno oggi le macchine virtuali dei linguaggi dinamici e paragonarla alla tecnologia che c'e' nella JVM e' davvero offensivo). Niente di innovativo li. Oh... ma anche cose come un garbage collector che fa un po' tristezza ma non e' completamente uno scherzo sono arrivati quasi 10 anni dopo l'implementazione iniziale. Per dire... Ora praticamente la cosa piu' innovativa che Python ha avuto e' stata l'intuizione sulla leggibilita'. Ora il concetto (letterario) di leggibilita' e' qualcosa di cui si stava parlando gia' nell' '800 (so much for innovation). Nell'ambito dei linguaggi di programmazione il concetto di readability e' stato studiato piuttosto presto (ci sono risultati interessanti dei primi anni 80, sostanzialmente quando si parlava anche di literate programming). Da un certo punto di vista... niente di interessante. Eppure il concetto di literate programming ha sostanzialmente fallito... io personalmente ricordo qualche vecchia versione di Haskell che andava in questa direzione e mi dava davvero dolore indicibile. Se vuoi l'approccio di Python e' opposto: rendiamo il codice leggibile, non farciamolo di spiegazioni testuali per renderlo leggibile. Ma anche li... se ne parlava da tempo. Innovativo o no? Il fatto e' che Python e' tutto sommato uno dei linguaggi piu' usati al mondo (si, essere nei primi 10 vuole dire essere molto usato) ed e' quello che ha portato il concetto di readability a molti sviluppatori. E incidentalmente li ha anche esposti ad una serie di tecniche (quelle la sopra) che i laymen programmer non conoscevano (e che, per inciso, tuttora non padroneggiano... pero' almeno si possono usare). Ora, se consideriamo esclusivamente i meriti tecnici/tecnologici Python non e' per nulla
Re: [Python] Why Go is not good
2015-07-17 14:33 GMT+01:00 Davide Muzzarelli d.muzzare...@dav-muz.net: Yes: if greeting: No:if greeting == True: Nel suggerimento la differenza tra Yes e No è solo sintassi. No. E' semantica. Nel primo caso stai di fatto andando a chiamare greeting.__nonzero__ se presente, se no greeting.__len__ e altrimenti e' semplicemente vero. Nel secondo invece stai andando a chiamare greeting.__eq__ (oppure greeting.__neq__ oppure greeting.__cmp__) oppure stai andando a confrontare gli id degli oggetti. Tipicamente quei due frammenti non sono sintatticamente diversi: sono filosoficamente diversi. Sono pure ortogonali. Il caso in cui collassano e' essenzialmente se greeting e' un booleano o un'intero (o qualcosa che si comporta come tale). Il terzo caso invece non è affatto sintassi e lo usi quando vuoi essere sicuro anche del tipo. Il terzo, come i primi due, non e' solo sintassi e *non* lo usi. E se lo usi mettici dei bei commenti a spiegare perche' lo usi. Siccome nel 99.9% dei casi e' un bug, e' molto facile che il primo che ripassa sul codice te lo sega via. Per cui se c'era un buon motivo, e' bene specificarlo. Tra l'altro in Python quando cominci a fare check espliciti sui tipi il codice puzzicchia. Ci sono motivi per farlo e niente da dire... ma sono *moolto* rari. Diventa worse se usi l'is quando non serve, ovvero nella maggioranza dei casi. Praticamente nella totalita'. Comunque sia == che is in quel caso sono moolto sospetti. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
Il 17/07/2015 14:38, Carlos Catucci ha scritto:
Adesso mi spieghi questa, a me povero 'gnurant. Come puoi avere un if
senza espressioni booleane? Al massimo sono piu' espressioni combinate
tra loro con operatori logici ma sempre booelane sono.
Intende che puoi fare:
a := true // Variabile booleana
if a {
...
}
e che invece non puoi fare:
b := nil // Sarebbe un None in Python
if b { // Errore!
...
}
e nemmeno:
c := 1
if c { // Errore!
...
}
Byez,
Davide Muzzarelli
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-17 14:46 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
b := nil // Sarebbe un None in Python
if b { // Errore!
...
}
e nemmeno:
c := 1
if c { // Errore!
...
}
Ah ecco, sara' che io certe brutte abitudini non le ho mai avute. Per me
True e False sono True e False, se ho
a = 1
non farei mai
if a:
pass
non avrebbe senso. Potrei farlo solo se avessi un
a = True o a = False
Sara' che preferisco avere codice leggibile e tranquillo.
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
Il giorno 17/lug/2015, alle ore 12:43, Marco Beri marcob...@gmail.com ha scritto: On Jul 17, 2015 12:26 PM, Enrico Bianchi enrico.bian...@ymail.com wrote: On 07/17/2015 11:45 AM, Carlos Catucci wrote: Sperem. Sopratutto i frameworks dovrebbero fare tutti il grande passo Ma a parte Twisted, cos'e` rimasto da portare? Tutte le mie applicazioni per esempio… IL punto è che la fatica è molta, il rischio è molto e la ricompensa è incerta. Per Marco, fervente cattolico (!), voglio dire che python 3 mi pare come il Paradiso che puoi conquistare a prezzo di sacrifici e che ti promette una miglior vita dopo la tua morte. Ammazzarmi di lavoro su questa base, in questo momento è al 48 posto nelle mia scala delle urgenze, appena dopo la traversata della Manica in pedalò… G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-17 0:53 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com: On 07/13/2015 11:55 AM, enrico franchi wrote: [...] a = may_return_null(...) if a is not None: f(a, ...) Bruttino, non tanto perche` non mi piace, ma per com'e` scritto :) La sintassi if a: f(a,...) E` molto piu` elegante (si, e` una pulce che non serve a molto) :) Io ti consiglio di lasciare `a is not None`. `if a` può significare troppe cose, specialmente in Python, e rischi di ritrovarti con un comportamento inaspettato. In Go per evitare problemi del genere hanno deciso che l'istruzione `if` accetta solo espressioni booleane. Fanno sempre e solo stack unwind, non danno controllo al programmatore. Mmm... continuo a non capire... Un esempio (o della documentazione)? Come dicevo... quello non e' Go idiomatico a mio avviso. Anche qua, mi sembra che tu abbia dato piu` peso al codice che ho usato come esempio piuttosto che al concetto che volevo esprimere. Personalmente ritengo che un try/except sia piu` elegante rispetto al dover fare il check per ogni error che ti viene restituito. http://blog.golang.org/errors-are-values Quello che intendo e` che, ad esempio, le operazioni di apertura, scrittura e chiusura di un file in Go devono essere gestite una per una, mentre in Python le posso gestire tutte nello stesso try/except che, personalmente, ritengo piu` sensato Fino a quando non devi gestire l'errore. A molti le eccezioni piacciono perchè ti fanno dimenticare che c'è stato un errore. Il codice è bello, ma quando devi gestire gli errori poi le cose iniziano ad andare in modo diverso. E la gente inizia a fare: except Exception: # print traceback se non di peggio. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] No al naturismo (era: Re: Why Go is not good)
Manlio Perillo wrote: E la gente inizia a fare: except Exception: # print traceback se non di peggio. Cosa potrebbe esserci di peggio di... OH! OH NO! Non starai mica pensando al... al... NAKED EXCEPT! Maledetto Manlio che susciti pensieri impuri in noi, facili prede delle tentazioni! -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
2015-07-17 14:07 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: Ammazzarmi di lavoro su questa base, in questo momento è al 48 posto nelle mia scala delle urgenze, appena dopo la traversata della Manica in pedalò… ROFLASTC! Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] OT ma interssante
2015-07-14 20:20 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: Prima risposta, senno' ci perdiamo. Darwin viene dal substrato Unix. Il concetto come dici tu di innovazione e' semrpe relativo. Pero' trovo innovativo un Linux (che comuqnue si e' evoluto nel tempo) e non certo un MacOsX che ha solo una interfaccia tutta cosette carine che si muovono da sole (ma anche quelle che stanno nel cartone del latte che ho nel frigo da sei mesi lo fanno) ma in concreto non rendono la fruizione dei contenuti di certo piu' facile. Nelle prossime cerco di rispondere agli altri punti. 1. il problema originario non e' se uno specifico componente di OS X sia innovativo o meno; il problema e' la tua tesi, secondo la quale Jobs (o Apple o entrambi) abbiano innovato. Anche se dimostri che Darwin non e' un sistema innovativo, non hai dimostrato che Jobs (o Apple) non siano stati innovativi (https://yourlogicalfallacyis.com/composition-division). Viceversa, per assurdo, se dimostrassimo che Darwin e' un sistema altamente innovativo, sarebbe molto difficile sostenere la tesi secondo la quale Jobs non ha innovato. 2. specificamente, per potere dimostrare che Darwin non e' innovativo, dovresti conoscere per bene Darwin. Senza offesa, non credo che questo sia il caso. Da quello che hai scritto mi sembra che tutto sommato tu non sia eccessivamente familiare con Darwin; il che non e' un problema, a meno che appunto tu non voglia parlare nello specifico di Darwin, nel qual caso un certo livello di familiarita' con l'argomento sarebbe utile per potere condurre la discussione sul punto specifico. Ovviamente, sostituisci Darwin con quello che ti pare. Che so... io ho una conoscenza relativamente sommaria (o anche nulla) di tante cose, ma tendo a non assumere posizioni forti sull'argomento perche', appunto, non posso motivarle. 3. il problema chiave e' che non abbiamo dato una chiara definizione di innovativo. senza quella definizione di innovativo e' complicato dire se qualcosa (o qualcuno) sia stato innovativo. perche' e' sufficiente negare caso per caso che un dato aspetto sia innovativo. Questo era il senso della mia provocazione niente e' innovativo. Se mettiamo una barra arbitrariamente alta su cosa sia innovazione, possiamo escludere arbitrariamente qualunque cosa dal novero delle cose innovative. Io metto la barra infinita e concludo che nulla e' innovativo: potremmo concludere che sono un coglione, ma non che ho torto (la mia posizione e' interamente coerente e logica internamente). Quando invece cominciamo a dire e invece questo e' innovativo si apre il problema: senza avere una definizione condivisa di innovativo non andiamo da nessuna parte. Incidentalmente, se guardi un po' di evoluzione, si vede spesso un pattern che le cose innovative sono in effetti estremamente conservative sulla maggior parte dei punti (magari anche tutti quanti i punti tecnologici). C'e' perfino il concetto di disruptive innovation, che tipicamente si applica a soluzioni che, fra le varia cose sono spesso assolutamente *non* innovative in senso tecnico, ma la cui innovazione e' la penetrazione di mercato oppure il semplice fatto che abilitano fasce di persone ad una tecnologia dalla quale erano completamente escluse (sebbene ne stiano usando una variante di serie B). E incidentalmente questo e' un concetto di... Marketing. Gia'. Ora non vorrei troppo parlare di disruptive innovation (che e' solo un tipo di innovazione... e molti sistemi apparentemente in competizione *sono* disruptive innovation: DOS, Windows, ed esattamente per gli stessi motivi... Linux; ma in un certo senso anche il vecchio MacOS e piu' recentemente MacOSX... e Amiga e il PC... tutti competitori, tutti con comunita' che si guardano in cagnesco, eppure tutti sistemi in cui una delle piu' grosse innovazioni e' stata quella di avere avuto tratti di disruptive innovation; il che non nega che su certi specifici aspetti ci sia stata innovazione tradizionale, tecnologica o sociale). Alla fine, senza avere una buona definizione di innovazione, checche' tu ne dica, siamo nel mondo della simpatia: qualcosa mi e' simpatico e quindi ne sopra-stimo i meriti, qualcosa mi e' antipatico e quindi ne nego i meriti (o addirittura sostengo che sia stato un male -- questa e' tipicamente la critica che viene da chi usa la versione 'sustaining' di una tecnologia che e' stata rimpiazzata da qualcosa di disruptive). Per il resto, davvero, non vedo come possiamo continuare la discussione con un minimo di interesse -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
Il 17/07/2015 14:50, Carlos Catucci ha scritto: non avrebbe senso. Potrei farlo solo se avessi un a = True o a = False Forse intendi: if a is True: ... altrimenti è esattamente come se facessi: if a: ... proprio perché il seguente if risulterà vero: a = 1 if a == True: ... Il motivo è che il primo if controlla anche il tipo mentre gli altri due no. Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-16 23:53 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com: On 07/13/2015 11:55 AM, enrico franchi wrote: Il problema con l'overloading e' che rende un sacco di cose drammaticamente piu' complicate: in presenza dello stesso caso che menzioni (ovvero che non sai quale tipo sia una variabile) vuole dire che effettivamente il tuo codice compilera', ma tu non avrai idea di cosa faccia. Mmm... non sono del tutto convinto, ovvero se io implemento Sum(int, int) e Sum(float, float), io so che posso avere o un int o un float e comportarmi di conseguenza Allora, in Go, si, perche' non hai type cohercion. In altri linguaggi? Devi certamente ricordarti tutte le conversioni implicite. Per dire, in molti linguaggi un long chiamerebbe la versione per float invece che quella per int. Per dire... super intuitivo ;) Ricordati che i bachi hanno la tendenza a rendersi manifesti alle 2 di notte quando a guardare il problema c'e' tipicamente qualcuno che non e' l'ingegnere che ha scritto il codice. E' un peccato che tu abbia tagliato il mio altro esempio che mostrava in modo completamente evidente quale sia il problema grosso (e che la mancanza di conversioni automatiche non e' sufficiente ad evitarlo). Se lo avessi studiato un pochetto ti saresti chiarito quale e' il punto. Se non sai quale e' il tipo della variabile, vuole dire che non sai quale variante del metodo verra' chiamata. E quindi di fatto non sai che codice stai eseguendo. Ecco che un'innocua seccatura in assenza di overloading e' diventata una possibile fonte di bachi. Mmm... In altre parole, stai dicendo che Python, in quanto (di solito) non sai il tipo della variabile masolo il suo contenuto, e` altamente problematico ;) Per assurdo molto meno. Almeno non ci sono dubbi su quale sia il codice della funzione che viene chiamato. Poi c'e' sempre il problema di quale sia il codice che la funzione che hai chiamato chiama a sua volta, ma quello fa parte del concetto di polimorfismo e tipicamente non vuoi farne a meno. E' un male quasi necessario. Senza offesa, ma da come rispondi sembrerebbe che ti soffermi piu` sul codice che sul concetto che volevo esprimere. Quello che interessa a me e` fare il catch del panic, in quanto, ad esempio, potrei voler fare in modo che l'applicazione non debba terminare assolutamente la sua esecuzione se non tramite intervento manuale. La soluzione, come dico in seguito (e come ho scoperto proprio grazie a questo thread) e` usando recover() in una deferred function, che di per se non e` anche una cattiva soluzione, anche se limitata dalla gestione dei defer in Go (ovvero a cascata non appena la funzione viene eseguita completamente) Eh, ma se mostri codice per rappresentare il problema, ma il codice che mostri non rappresenta il problema io posso solo parlare del codice in se... la sfera di cristallo non mi funziona troppo bene. :) Comunque, dipende come e' concepito il sistema. Ci sono casi in cui vuoi catturare un'eccezione piuttosto esterna. Tipicamente posso pensare ad un webserver essenzialmente stateless: fallisci la richiesta, tiri un 5xx e vai avanti. Essendo stateless, non hai il problema che il panic sia un sintomo di memoria corrotta. E se il sistema e' messo su da persone normodotate avrai un quache allarme se il rate di 5xx e' troppo alto (che indicherebbe a sua volta che il sistema e' compromesso e che bisogna intervenire). Quindi anche in questo caso devi comunque avere qualche tipo di supporto a livello di sistema/operations. Su un sistema stateful in molti casi preferisco abbattere l'applicazione e non pensarci due volte. Tanto (sempre siccome parliamo di individui normodotati) il sistema avra' qualche tipo di ridondanza e questo non e' un problema. E ci sara' qualche tipo di nanny che ritira su il tutto (possibilmente partendo da uno stato non corrotto). Se ancora una volta l'applicazione va giu' troppe volte in poco tempo vuole dire che c'e' un problema, ci sara' un allarme e qualcuno dovra' correre a guardarci. Oppure se abbiamo abbastanza capacity (che so... siamo in N+K) ci si guarda il giorno dopo e tanti saluti. Nota, questo approccio funziona anche (e come sempre meglio) in un sistema stateless: semplicemente se hai stato catturare un'eccezione, loggare e andare avanti puo' volere dire che quell'istanza da quel momento in poi serve merda, hai un gray failure ed e' molto peggio: meglio abbattere tutto e tanti saluti. Nel caso specifico di Go, ritirare su un'applicazione e' generalmente una cosa molto veloce. *E* i panic non dovrebbero segnalare condizioni normali. Quindi e' assolutamente concepibile pulire tutto e fare morire e saluti. Posso essere d'accordo, ma secondo me lo sconsigliare una pratica del genere e` difettata dalle varie casistiche. Vedi ad esempio il caso di un'applicazione che non deve morire mai Salvo che nel tuo caso l'applicazione moriva comunque. Tra l'altro mi aspetto che tu conosca la differenza fra except: ed except Exception:,
Re: [Python] Why Go is not good
2015-07-17 14:01 GMT+01:00 Davide Muzzarelli d.muzzare...@dav-muz.net: Il motivo è che il primo if controlla anche il tipo mentre gli altri due no. In realta' il primo e' anche il piu' broken. Dalla PEP8: - Don't compare boolean values to True or False using == . Yes: if greeting: No:if greeting == True: Worse: if greeting is True: -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-17 13:50 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: Sara' che preferisco avere codice leggibile e tranquillo. E non idiomatico. Il Python idiomatico presuppone che tu spesso e volentieri hai nella guardia dell'if (o del while) cose che *non* sono booleani. Non farlo ti costringe a scrivere pessimo Python (e a dovere scrivere soluzioni terribilmente piu' complicate). -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
2015-07-17 15:10 GMT+02:00 enrico franchi enrico.fran...@gmail.com: si il codice fa cacare, e' solo un esempio per mostrare come in Python hai nell'if qualcosa che non e' un booleano (ma che viene valutato in contesto booleano). Ok mai io quello intendevo, la valutazione e' sempre boolean. Se poi gli passo un oggetto not bool sono io che ho fatto la frittata. Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
2015-07-17 14:07 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: Il giorno 17/lug/2015, alle ore 12:43, Marco Beri marcob...@gmail.com ha scritto: On Jul 17, 2015 12:26 PM, Enrico Bianchi enrico.bian...@ymail.com wrote: On 07/17/2015 11:45 AM, Carlos Catucci wrote: Sperem. Sopratutto i frameworks dovrebbero fare tutti il grande passo Ma a parte Twisted, cos'e` rimasto da portare? Tutte le mie applicazioni per esempio… IL punto è che la fatica è molta, il rischio è molto e la ricompensa è incerta. Per Marco, fervente cattolico (!), voglio dire che python 3 mi pare come il Paradiso che puoi conquistare a prezzo di sacrifici e che ti promette una miglior vita dopo la tua morte. Ammazzarmi di lavoro su questa base, in questo momento è al 48 posto nelle mia scala delle urgenze, appena dopo la traversata della Manica in pedalò… Vedo che il mio messaggio è passato forte e chiaro. Bravo Giovanni :-) Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro http://beri.it/articoli/ - Qualche articolo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Why Go is not good
Il 17/07/2015 15:13, enrico franchi ha scritto: In realta' il primo e' anche il piu' broken. Dalla PEP8: * Don't compare boolean values to True or False using == . Yes: if greeting: No:if greeting == True: Worse: if greeting is True: Nel suggerimento la differenza tra Yes e No è solo sintassi. Il terzo caso invece non è affatto sintassi e lo usi quando vuoi essere sicuro anche del tipo. Diventa worse se usi l'is quando non serve, ovvero nella maggioranza dei casi. Può darsi che io abbia intuito male cosa volesse fare Carlos. Byez, Davide Muzzarelli ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
enrico franchi wrote: La cosa piu' innovativa che Python ha avuto e' stata l'intuizione sulla leggibilita'. [...] Se consideriamo esclusivamente i meriti tecnici/tecnologici Python non e' per nulla innovativo [...]. Eppure usando un diverso concetto di innovazione e' invece un linguaggio estremamente innovativo... Esattamente. E quasi vent'anni dopo Go ne raccoglie l'eredità, quasi esattamente nello stesso spazio. La stessa enfasi su semplicità e leggibilità, la stessa parsimonia, anzi perfino maggiore, nell'adottare funzionalità, e un migliore e più moderno posizionamento su vari assi: tipi statici/dinamici, modello compilato/interpretato, tipi e oggetti, concorrenza, infrastruttura e strumenti standard. Il tutto lo rende un linguaggio applicabile meglio di Python a un numero maggiore di casi applicativi. C'è ovviamente una differenza di maturità sia nel linguaggio che nell'ecosistema, ma la velocità dei miglioramenti in entrambi sembra almeno doppia di quella dei primi anni di Python. Aggiungiamo che negli anni in cui Go si consolidava, Python affrontava la difficile e non ancora conclusa transizione tra due versioni incompatibili, ed è difficile evitare la conclusione che la dominazione del mondo non sia più a portata di mano (se mai lo è stata). La vita è cambiamento. Come dicevano in Pomodori verdi fritti, una signora sa quando è il momento di andare. Credo si applichi a tutti. :-) -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] I Pythonisti parlano spesso di Go (era: Re: [OT] Cheap MapReduce in Go)
Grande idea, piu siamo meglio è C'è da dire che la semplicità del linguaggio, l'approccio minimale a tutto la sue performance spavantose il trend dei microservizi e la comunità anche piu rude :) rendono il python molto meno attraente Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG è molto leggero gli consiglio di leggere il libro introduttivo a go parla delle motivazioni nello sviluppo del linguaggio http://yager.io/programming/go.html se gli esempi li porti al PHP in quel post risulta che il PHP è il miglior linguaggio del mondo si è focalizzato solo sul tipo, è molto piu complesso di così Poi alla fine ogni linguaggio ha i suoi vantaggi ma non si deve sottovalutare le comunità che fanno l'ecosistema del linguaggio che poi diventa il vero valore del linguaggio, e poi se si vuole utilizzare un qualsiasi linguaggio non per forza si devono trovare scuse sul nascituro :) Il giorno giovedì 16 luglio 2015 10:26:14 UTC+2, Nicola Larosa (tekNico) ha scritto: Nelle ultime settimane ci sono state parecchie discussioni su Go sulla mailing list italiana di Python. Esempi nell'ultimo mese: [OT] Cheap MapReduce in Go http://lists.python.it/pipermail/python/2015-July/024036.html http://www.google.com/url?q=http%3A%2F%2Flists.python.it%2Fpipermail%2Fpython%2F2015-July%2F024036.htmlsa=Dsntz=1usg=AFQjCNF60bNjkY-6yvJdQ0Um6Z-qY_nzxw Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG http://lists.python.it/pipermail/python/2015-July/023951.html Why Go is not good http://lists.python.it/pipermail/python/2015-July/023855.html Sembra esserci una certa sovrapposizione tra pythonisti e gopher italiani, e la collaborazione è benvenuta. :-) Massimiliano Pippi wrote: Ciao GollumOne! 2015-07-16 10:02 GMT+02:00 Gollum1 gollum1.smeag...@gmail.com: Ma esiste una ml di utenti italiani di go? Potremmo anche crearla, almeno queste cose non sarebbero più ot. Stavo per segnalarlo ma non sapevo bene come fare a non sembrare bacchettone ma visto che sei andato avanti tu... :) Si c'è: https://groups.google.com/forum/#!forum/golangit è a scarsissimo traffico ed è un peccato, le discussioni fatte qui negli ultimi mesi meritavano di andare di là, o meglio, gente che sta di là meritava di assistere alle discussioni in oggetto. Oppure modifichiamo il nome a questa lista, visto che sono più i post su go (peraltro interessantissimi) che i post su python. Sì, ultimamente l'OT è una fetta importante del traffico :P Certo, è difficile differenziale totalmente, visto che la maggior parte dei post nascono come comparazione. Se di là sono daccordo, a me il crosspost quando è utile piace Buon fresco -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python innovation -- no longer OT --[Re: OT ma interssante]
2015-07-17 16:26 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Io ho cercato di leggere il codice di TeX, ma non ci sono riuscito. Praticamente non ci capisco nulla o quasi di come funziona il tutto... Beh, credo che li il problema travalica literate programming... e' proprio che Tex e' sufficientemente cervellotico come linguaggio che e' difficile immaginare implementazioni particolarmente semplici. Tanto e' vero che in pratica non ne esistono molte... -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
Nicola Larosa wrote: La stessa enfasi su semplicità e leggibilità, Manlio Perillo wrote: Però Python non è poi così semplice. Anche Go ha le sue idiosincrasie: niente e nessuno è perfetto. :-) L'importante è che ci sia un principio ispiratore dietro, e una pratica implementativa che ne dimostri una decente applicazione. Python si è complicato nel corso degli anni: vedremo se Go riuscirà a tenersi più leggero. Le premesse ci sono. -- Nicola 'tekNico' Larosa http://www.tekNico.net/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python innovation -- no longer OT --[Re: OT ma interssante]
2015-07-17 17:32 GMT+02:00 enrico franchi enrico.fran...@gmail.com: 2015-07-17 16:26 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Io ho cercato di leggere il codice di TeX, ma non ci sono riuscito. Praticamente non ci capisco nulla o quasi di come funziona il tutto... Beh, credo che li il problema travalica literate programming... e' proprio che Tex e' sufficientemente cervellotico come linguaggio che e' difficile immaginare implementazioni particolarmente semplici. Tanto e' vero che in pratica non ne esistono molte... Ci hanno provato in Java. È vero che come al solito lo hanno sovra-ingegnerizzato ma il problema era semplicemente: troppo inefficiente. Se studi il codice di TeX vedi che è tutto accoppiato, specialmente la gestione delle stringhe e della memoria fa paura. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
2015-07-17 16:56 GMT+02:00 Nicola Larosa n...@teknico.net: enrico franchi wrote: La cosa piu' innovativa che Python ha avuto e' stata l'intuizione sulla leggibilita'. [...] Se consideriamo esclusivamente i meriti tecnici/tecnologici Python non e' per nulla innovativo [...]. Eppure usando un diverso concetto di innovazione e' invece un linguaggio estremamente innovativo... Esattamente. E quasi vent'anni dopo Go ne raccoglie l'eredità, quasi esattamente nello stesso spazio. La stessa enfasi su semplicità e leggibilità, Però Python non è poi così semplice. [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python innovation -- no longer OT --[Re: OT ma interssante]
2015-07-17 16:40 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Se studi il codice di TeX vedi che è tutto accoppiato, specialmente la gestione delle stringhe e della memoria fa paura. Oh, d'altra parte quello deve fare. Costruire quintali di stringhe di testo. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
On 07/17/2015 11:45 AM, Carlos Catucci wrote: Sperem. Sopratutto i frameworks dovrebbero fare tutti il grande passo Ma a parte Twisted, cos'e` rimasto da portare? Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
2015-07-17 11:35 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com: E non solo lei, ma anche Debian e Ubuntu stanno pianificato il salto. Che sia la volta buona? Sperem. Sopratutto i frameworks dovrebbero fare tutti il grande passo Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Fedora Planning to switch to Python 3
https://fedoraproject.org/wiki/Changes/Python_3_as_Default E non solo lei, ma anche Debian e Ubuntu stanno pianificato il salto. Che sia la volta buona? Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
2015-07-17 11:35 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com: https://fedoraproject.org/wiki/Changes/Python_3_as_Default E non solo lei, ma anche Debian e Ubuntu stanno pianificato il salto. Che sia la volta buona? Lo spero bene. Io per me l'ho fatto e sto portando a py3 tutto quello che gestisco. Molti meno malditesta (una volta finito il porting...) -- | Raffaele Salmaso | http://salmaso.org | https://bitbucket.org/rsalmaso | http://gnammo.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Fedora Planning to switch to Python 3
On Jul 17, 2015 12:26 PM, Enrico Bianchi enrico.bian...@ymail.com wrote: On 07/17/2015 11:45 AM, Carlos Catucci wrote: Sperem. Sopratutto i frameworks dovrebbero fare tutti il grande passo Ma a parte Twisted, cos'e` rimasto da portare? Tutte le mie applicazioni per esempio... L Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
2015-07-17 19:35 GMT+02:00 Giovanni Porcari giovanni.porc...@softwell.it: Mi piacerebbe sentire la vostra opinione su questo tema… Io ho cambiato linguaggio quasi ogni anno o due dal 1983 fino al 1999. Poi non ho più cambiato (in quell'anno ho cominciato a usare Python). Non cambiare potrebbe essere un segno di eccessiva maturità, non lo discuto, ma io sto bene così e in ogni caso mi trovi d'accordo :-) Ciò detto, penso che, quasi certamente, mi metterò a imparare Go. Per curiosità (e fiducia) più che altro. Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro http://beri.it/articoli/ - Qualche articolo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Quanto conta il linguaggio ?
Non metto OT perchè con sto caldo ci sono così tanti OT che sarebbe più OT parlare esplicitamente di Python. La mia domanda comunque nasce dalle recenti mail relative a python vs go e ai richiami ad altri linguaggi. Ho visto appassionanti comparazioni su features più o meno esotiche, ho visto vantare leggibilità o possibilità di scrivere procedure meno esposte a bug, ho letto con interesse tutte queste cose ma alla fine mi sono chiesto: Ma quanto conta il linguaggio per scrivere buone applicazioni ? Io identifico come elemento primario nella scrittura di un’applicazione di una certa complessità la sua architettura. Ovvero come si riesce ad analizzare il problema e come questo si traduce in sotto problemi in un modo elegante e facile da mantenere. Se la nostra applicazione fosse un edificio assomiglierebbe ad una torre svettante nel cielo e ricoperta da una facciata tutta a specchi o sarebbe un edificio basso con profonde cantine e lunghi corridoi ? Assomiglierebbe al duomo di Milano o al Partenone ? Insomma io credo che il modo in cui un’applicazione si struttura in servizi condivisi, il modo in cui distribuisce le risorse di memorizzazione e di elaborazione, il modo in cui pianifica da subito i possibili futuri cambiamenti conti alla fine ben più del linguaggio usato. Il linguaggio è uno strumento di lavoro, il modo che ho per costruire l’edificio. Ma posso fare ottimi edifici persino in PHP e con questo credo di aver già rischiato di farmi strangolare. Quando sento dire che di volta in volta si può scegliere il linguaggio migliore per lo specifico problema io penso che sia un’affermazione valida per un ristretto numero di eletti (spesso grandi bevitori di birra) che riescono a padroneggiare i linguaggi con la stessa facilità con cui un bravo giocoliere fa volteggiare 12 mazze sulla sua testa mentre attraversa una stretta passerella su un precipizio. Io credo invece che uno sviluppatore non così abile, dovrebbe limitarsi a conoscere bene un linguaggio in modo da sfruttarlo al meglio e conoscerne soprattutto i limiti e i punti deboli. Quando si cambia cavallo si rischia spesso di ottenere un risultato meno valido non perchè questo sia un brocco, anzi, ma perchè non lo si conosce bene e si commettono errori che solo anni di esperienza ti portano ad evitare. Quindi io amo python perchè mi permette di concentrarmi sull’architettura della soluzione e mi aiuta a scrivere con naturalezza del codice che funziona bene e che riesco a mantenere. So benissimo che mi perdo un sacco di raffinate features, ma so anche che essendo comunque un ottimo linguaggio, non mi mette nella necessità di cambiare. Neppure per passare a python 3. Per le stesse ragioni che enunciavo prima. Mi piacerebbe sentire la vostra opinione su questo tema… G. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
2015-07-17 17:01 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: Però Python non è poi così semplice. Lo era. Oggi... credo che buona parte degli sviluppatori non siano a loro agio con molte features user level dello stesso. -- * user level: non sto parlando di dettagli implementativi o di edge case di librerie dovuti a bachi et similia. Parlo semplicemente di features del linguaggio. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
On 17 July 2015 at 19:56, Simone Federici s.feder...@gmail.com wrote: suggerisco alla prossima pycon di aggiungere la sub community degli expythonistigolanghisti Tu dicevi li nello stanzione dell scope? Quello che quando si chiude la porta non si riesce piu' ad aprire (sopratutto dopo che hai buttato la chiave a mare)? ;) Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] OT ma interssante
Per il resto, davvero, non vedo come possiamo continuare la discussione con un minimo di interesse Troppo caldo per polemizzare. Accetto il tuo punto di vista (il chiudiamola qui, non e' una cosa cattiva avere differenti pow). Carlos -- EZLN ... Para Todos Todo ... Nada para nosotros ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
marco perché java 2 volte? cmq non la facciamo una guerra di religione, ognuno di noi da focus alle attività che fa e ha fatto nella propria carriera. Mica abbiamo tutti fatto le stesse cose. Io un progetto dove posso usare GO ancora non ce l'ho, mi sembra interessante ma finche non ho un caso reale con cui posso interagire, rimarrà solo letteratura. Python invece riesco a infilarlo ovunque, in qualsiasi ambito mi capiti a tiro. Tra parentesi guardatevi Java 8 che finalmente ha introdotto le lambda e gli streams con un po' di funzionale che non guasta. Gli streams funzionano anche in parallelo. io di esperienze con altri linguaggi ne ho davvero poche, certo ho giocato a 12 ani con basic e ho imparato a programmare con pascal e qualche tipo action scripts, assembler, C, C++... però di lavori pagati direi che si riassumono in java python e javascript sui browser. Per l'ambito dove sto io per ora, passare a go è un suicidio. Però il concept alla base è ottimo e sicuramente nei prossimi anni potrebbero aprirsi delle strade in tal senso. Io credo che più che imparare a programmare con un nuovo linguaggio, serva tenersi aggiornati su tutte le novità del mercato per trovarsi nel momento che serve una scelta a fare quella corretta. Non sempre siamo tenuti a scegliere, non sempre vale la pena scegliere. Ma sempre vale la pena spulciare, studiare, guardare, crescere... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
Il giorno 17/lug/2015, alle ore 23:40, enrico franchi enrico.fran...@gmail.com ha scritto: 2015-07-17 21:56 GMT+01:00 Giovanni Porcari giovanni.porc...@softwell.it: Si… capisco che è bello conoscere molti linguaggi. Ma, non per essere pedante, quanto conta il linguaggio nella risoluzione di un problema ? Tanto la domanda chiave nel messaggio iniziale e' sempre questa. Quanto conta? Tantissimo. Allora, per intenderci, il linguaggio conta poco se lo usi male o se lo conosci poco. Per intenderci, se conosci bene Java (per dire) arriverai in fondo anche ad un progetto in Python. Verosimilmente avrai scritto Java in Python. Sara' lento come Python, sovra-ingegnerizzato come Java e ti sarai perso una serie di possibilita' a livello di libreria standard e di librerie accessorie. Pero', probabilmente, sarai in grado di consegnare. Questo e' il famoso problema di Blurb (http://www.paulgraham.com/avg.html): se volete leggere poco, leggete solo la sezione chiamata Blurb Paradox. Se il linguaggio lo usi bene, conta tantissimo. Perche' semplicemente certi linguaggi hanno come costrutti nativi cose che possono essere molto rilevanti (o meno) per il tuo problema specifico. Che so... facciamo un esempio concreto per non pontificare. Supponi che la tua applicazione abbia bisogno di un concetto di plugin. Sempre per semplificare, immaginiamo che puoi astrarre il tuo plugin come una classe (o come un set di funzioni/API ben definite) la cui implementazione effettiva viene caricata a runtime sulla base di un parametro di configurazione. Questo problema in Python lo risolvi con importlib, che ti suca la tua classe sulla base di una stringa tipo project.authentication.kerberos.Plugin ora, e' vero che devi sempre implementarti Plugin, ma e' anche vero che per il resto tutto il resto te lo da la libreria standard (e il fatto che il tuo linguaggio e' altamente dinamico). Hai ancora il problema di gestire gli import path (ovvero il tuo plugin viene separato dalla tua applicazione, ci vorra' un modo di dire dove sucare i plugin) che potrebbe essere una seconda stringa (il path) e tre righe di python che rendono qulla directory visibile a Python. Davvero, hai finito. Ora, immagina di risolvere la cosa in C++. Intanto devi in qualche modo astrarre il meccanismo di loading di un .so, poi devi trovare un modo di gestire i problemi di compatibilita' binaria di C++, poi avrai sempre problemucci tipo il problema di deallocare/allocare roba sui bordi della libreria. Il problema e' molto piu' complicato. A seconda di quanto tempo hai, l'intera feature potrebbe dovere essere soppressa. Questa per una cosa banale e concreta che tutti masticano. Poi ci sono cose piu' filosofiche: certi costrutti che semplicemente semplificano la vita perche' programmi ad un livello piu' alto (o ti danno piu' controllo sul basso livello). Non tutti i progetti ne hanno bisogno, ma spesso saltano fuori questo tipo di requirement in modo inaspettato. Ci sono interi costrutti che ti aprono la mente ad un modo di pensare che semplifica moltissimo l'architettura e il design. Poi ci sono limiti intrinseci del linguaggio... per esempio il problema di Python e' che devi *sempre* spostare a livello di architettura problemi che vorresti risolvere a livello di design. Ogni qual volta in Python hai un componente che deve fare sia molto I/O che molta CPU e non puoi isolarlo completamente (che a sua volta e' una scelta architetturale) devi introdurre una complicazione achitetturale non indifferente. Devi prendere code di comunicazione ed esternalizzarle, affrontare il problema di serializzazione e deserializzazione. La stessa applicazione in Java potrebbe avere un'architettura simile in termini di macro-componenti, e tuttavia essere significativamente piu' semplice (si, Redis, per quanto semplice, e' piu' complicato e piu' costoso di una Bounded Queue e tirare a mano Celery per spezzare task CPU bound da task I/O bound e' sensibilmente piu' complicato di avere due thread pool). A volte non importa, a volte e' un problema. Ma non solo... certe idee architetturali vengono in modo naturale dall'avere visto possibilita' a livello di linguaggio che non si conoscevano. Per esempio... l'idea della lambda architecture, e di lavorare essenzialmente con un set di dati immutabili, append only e' direttamente figlio di un modo di programmare che si ha nei linguaggi funzionali, se puri e' meglio. Se hai visto il mondo funzionale, pensare in termini di map-reduce e' drammaticamente semplice e l'idea stessa che la mutabilita' dei database e' il vero problema che rende il CAP theorem uno scoglio mastodontico viene sempre da li. Non necessariamente in termini che devi usare un linguaggio funzionale per risolvere il problema (anzi), ma dal fatto che il tuo cervello si trova a tuo agio in questo mondo. Supponi che io ti dicessi che il
Re: [Python] Non solo le signore (era: Re: Python innovation -- no longer OT --[Re: OT ma interssante])
Il 17 luglio 2015 16:56, Nicola Larosa n...@teknico.net ha scritto: Approposito di innovazione... Esattamente. E quasi vent'anni dopo Go ne raccoglie l'eredità, quasi esattamente nello stesso spazio. e magari non proprio 20 anni dopo ma che fine ha fatto Dart? JS troppo complicato da uccidere (come meriterebbe) sotto una montagna di letame? ciao -- Gian Mario Tagliaretti GNOME Foundation member gia...@gnome.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
On Jul 17, 2015 9:04 PM, Karim lemieli...@gmail.com wrote: 2015-07-17 20:46 GMT+03:00 Marco Beri marcob...@gmail.com: Io ho cambiato linguaggio quasi ogni anno o due dal 1983 fino al 1999. Poi non ho più cambiato (in quell'anno ho cominciato a usare Python). Marco, si parla di almeno una decina di linguaggi... Usati per almeno un progetto nella mia vita: - basic - cobol - c - clipper - pascal - c++ - visual basic - java - lotus script - perl - javascript - java - abap - lisp A mani basse vince Python... Ma proprio a mani basse. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
On Jul 17, 2015 10:36 PM, Simone Federici s.feder...@gmail.com wrote: marco perché java 2 volte? Perché ho bevuto 4 birre alla grigliata della squadra di basket... :-D ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] OT ma interssante
2015-07-17 20:50 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com: Troppo caldo per polemizzare. Accetto il tuo punto di vista (il chiudiamola qui, non e' una cosa cattiva avere differenti pow). No, certo. Beh, qui non fa troppo caldo. Mi limito a dire che se vogliamo proseguire, secondo me bisogna costruire un po' di linguaggio comune (e considerare i punti di cui sopra), senza non puo' che finire con X ha Y, si ma Y non e' veramente perche' Z, ah, ma Z no... accidenti ho finito l'alfabeto. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Quanto conta il linguaggio ?
Il giorno 17/lug/2015, alle ore 22:36, Simone Federici s.feder...@gmail.com ha scritto: marco perché java 2 volte? cmq non la facciamo una guerra di religione, ognuno di noi da focus alle attività che fa e ha fatto nella propria carriera. Mica abbiamo tutti fatto le stesse cose. Io un progetto dove posso usare GO ancora non ce l'ho, mi sembra interessante ma finche non ho un caso reale con cui posso interagire, rimarrà solo letteratura. Python invece riesco a infilarlo ovunque, in qualsiasi ambito mi capiti a tiro. Tra parentesi guardatevi Java 8 che finalmente ha introdotto le lambda e gli streams con un po' di funzionale che non guasta. Gli streams funzionano anche in parallelo. io di esperienze con altri linguaggi ne ho davvero poche, certo ho giocato a 12 ani con basic e ho imparato a programmare con pascal e qualche tipo action scripts, assembler, C, C++... però di lavori pagati direi che si riassumono in java python e javascript sui browser. Per l'ambito dove sto io per ora, passare a go è un suicidio. Però il concept alla base è ottimo e sicuramente nei prossimi anni potrebbero aprirsi delle strade in tal senso. Io credo che più che imparare a programmare con un nuovo linguaggio, serva tenersi aggiornati su tutte le novità del mercato per trovarsi nel momento che serve una scelta a fare quella corretta. Non sempre siamo tenuti a scegliere, non sempre vale la pena scegliere. Ma sempre vale la pena spulciare, studiare, guardare, crescere… Si… capisco che è bello conoscere molti linguaggi. Ma, non per essere pedante, quanto conta il linguaggio nella risoluzione di un problema ? Ovvero, facendo un paragone magari sciocco, abbiamo opere meravigliose scritte in tutte le lingue note all’uomo. Nessuno confonderebbe la lingua usato con i contenuti espressi, la costruzione della vicenda, nel caso di un romanzo, o la capacità di evocare un’immagine poetica usando una specifica parola o rima. Probabilmente pensiamo che il francese sia perfetto per una poesia romantica mentre magari siamo portati a credere che il tedesco risulti meno adatto a questo compito. Io dico che il linguaggio conta alla fine molto poco e che bisognerebbe anche trovare il tempo di chiacchierare di architettura delle soluzioni e di come passare dal problema alla sua implementazione. Quando sono a pycon mi godo sempre con grande piacere i talk di Alex Martelli perchè, pur parlando di python, non si focalizza tanto sul linguaggio in sè, quanto sui pattern, sui problemi e sulle possibili strategie di risoluzione mostrando vantaggi e svantaggi. Io di python apprezzo il fatto che mi pesa poco e mi consente facilmente di passare dall’idea al prototipo e alla realizzazione finale. Poi magari la risoluzione finale in GO sarebbe stata più valida e avrebbe prestazioni superiori ma non so se consente la stessa agilità di prototipazione e risoluzione. G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
