C++, Java o Python

[ingframin]

Originariamente inviato da cdimauro

Sono interessati, ma a mio avviso sono troppo legati a CPython e all'enorme mole codice (in particolare C) che da esso dipende, e quindi anche dalla compatibilità. Questo frena lo sviluppo di soluzioni alternative e votate alle pure prestazioni. Infatti anche PyPy, pur essendo molto maturo, non viene ancora visto come valido sostituto.

Si potrebbe anche dare una spintarella a CPython (anche se non potrebbe mai raggiungere i livelli di PyPy), perché le idee ci sono (e io ne ho accumulate tante con la mia esperienza con WPython), ma manca il tempo e la voglia di imbarcarsi in un progetto molto complesso e difficile da portare avanti, a causa... del codice già scritto e delle scelte già fatte.

Ormai sono 2 anni che non seguo più la mailling list degli sviluppatori, causa cronica mancanza di tempo, ma la mia impressione è che aspettino che qualcuno tiri fuori un nuovo progetto, che funzioni bene e sia abbastanza retrocompatibile con CPython. Per cui... campa cavallo.

Parlando di recente con un mio collega di queste problematiche, si chiedeva come mai non fosse possibile realizzare qualcosa di simile al compilatore JIT di LUA, che consente di ottenere eccellenti prestazioni (a volte compete col C!), nonostante il linguaggio non abbia una variegata tipizzazione dei dati (Python è più ricco e, sulla carta, potrebbe meglio beneficiare della type inference). Il tutto, tra l'altro, è stato scritto da una sola persona.

Forse questo potrebbe essere un punto di partenza, anche se c'è da dire che Python richiederebbe molto più tempo a causa della maggior complessità del linguaggio.

Un'altra cosa molto importante è che, come diceva van9, un altro grosso problema è rappresentato da Guido, che ha una visione diversa di come dovrebbe essere implementato il linguaggio, ed è troppo legato a una concezione "didattica". Lo vediamo, ad esempio, quando si oppone all'introduzione delle tail optimization per le chiamate a funzione.

Ecco, questa è una cosa che da una parte apprezzo (perché a me piace che Python sia usato a livello didattico), ma dall'altra trovo sia castrante per chi è consapevole di eventuali rischi e sia disposto ad accollarseli pur di ottenere prestazioni migliori. Spesso nella mailing list ho sentito dire dagli sviluppatori che bisogna essere adulti e prendersi le responsabilità.
Ma allora perché questo principio non potrebbe essere applicato anche a CPython, ad esempio abilitando la compilazione dei moduli con l'assunzione che le builtin-in function non possano essere cambiate da nessuno e, quindi, generando codice di gran lunga più ottimizzato quando se ne fa uso (tipo la famigerata funzione len, che per essere invocata si fa una trafila enorme nel codice)? Perché non consentire le tail-optimization per le funzioni? Perché non dare la possibilità di assumere che certe variabili dichiarate nel modulo siano globali, sì, ma nessuno le altererà da fuori dal modulo? E così via, perché di esempi ne potrei fare a bizzeffe.

A parte questo, personalmente avrei fatto scelte molto diverse per CPython. Non mi piacciono diverse soluzioni che sono state adottate per tante cose, e mi riferisco in particolare alla struttura di PyObject & discendenti, e a come funziona il main loop della virtual machine (ceval).

Per me, quindi, sarebbe meglio cominciare con un progetto nuovo, e procedere incrementalmente implementando man mano le varie caratteristiche del linguaggio. Il problema è che ci vorrebbe troppo tempo. Parlando con Antonio Cuni (uno dei core developer di PyPy) alla recente PyCon, mi diceva che secondo lui ci vorrebbero almeno un paio d'anni per cominciare un progetto del genere da zero. E gli posso credere sulla parola, sia per la sua esperienza sia perché anch'io ho avuto modo di sbatterci la testa.

Ma alla fine chi dovrebbe accollarsene l'onere? Questa è la domanda più importante, a mio avviso. Python ormai è un linguaggio mainstream, utilizzato ampiamente da un sacco di gente, di aziende, e tantissime multinazionali. A mio avviso dovrebbero mettere in piedi una task force, cacciando fuori un po' di soldi per risolvere una volta per tutte questo problema. Anche perché le ricadute ci sarebbero sicuramente per tutti, e loro in primis...

WPython era un progetto interessante, peccato che non abbia una community attiva di sviluppatori...
Pypy l'ho provato ma non è che mi abbia esaltato... Ho notato ad esempio che se il codice usa cose tipo struct.unpack(...) non va per niente più veloce di CPython, anzi... Anche codice che si interfaccia con moduli C non va meglio (pygame ). Sicuramente è promettente ma direi che per sfruttarne appieno le potenzialità bisognerebbe cominciare a scrivere in python puro e risolvere il limite di velocità imposto dalle chiamate a moduli scritti in C (o evitarle proprio...).
Non sapevo che fosse guido ad opporsi alla tail optimization...
Inoltre secondo me si potrebbero prendere tante idee da Lisp per rendere python un po'migliore.
La cosa che più mi fa rabbia è che non ho abbastanza conoscenze informatiche per partecipare attivamente allo sviluppo!

[marco.r]

Originariamente inviato da cdimauro

Un'altra cosa molto importante è che, come diceva van9, un altro grosso problema è rappresentato da Guido, che ha una visione diversa di come dovrebbe essere implementato il linguaggio, ed è troppo legato a una concezione "didattica". Lo vediamo, ad esempio, quando si oppone all'introduzione delle tail optimization per le chiamate a funzione.

Capisco la volonta' di mantere la chiarezza e da debuggabilita', nula vieterebbe pero' di aggiungere ottimizzazioni "opt-in" da usare solo quando uno ha imparato, o vuole spremere l'ultimo ciclo.
In Common Lisp ad esempio uno puo' dichiare la priorita' tra "speed" "debug", "safety".
Se speed e' piu' importante di safety il compilatore puo' decidere di non effettuare il controllo sui limiti di un array, oppure optare per effettuare la tail call di una chiamata ricorsiva se "speed" > "debug". Puoi pure deciderlo funzione per funzione. Questo mi sembrerebbe un buon compromesso.

[cdimauro]

Originariamente inviato da ingframin

WPython era un progetto interessante, peccato che non abbia una community attiva di sviluppatori...

Ero il solo: altro che community.

Pypy l'ho provato ma non è che mi abbia esaltato... Ho notato ad esempio che se il codice usa cose tipo struct.unpack(...) non va per niente più veloce di CPython, anzi... Anche codice che si interfaccia con moduli C non va meglio (pygame ).

E' un problema noto di PyPy, che ha difficoltà con ctypes. Infatti ha proposto un altro metodo d'interfacciamento col codice C, chiamato cffi se non ricordo male, che oltre a essere di gran lunga più veloce con PyPy è fatto anche molto meglio a livello di funzionamento e API.

Ne ha parlato sempre Antonio Cuni all'ultima PyCon. Forse lo ricordi.

Sicuramente è promettente ma direi che per sfruttarne appieno le potenzialità bisognerebbe cominciare a scrivere in python puro e risolvere il limite di velocità imposto dalle chiamate a moduli scritti in C (o evitarle proprio...).

Se CPython fosse (molto) più veloce si potrebbe pensare di riscrivere tanti moduli in Python. Infatti è quello che fanno con PyPy.

Non sapevo che fosse guido ad opporsi alla tail optimization...

Tail Recursion Elimination
Final Words on Tail Calls

Inoltre secondo me si potrebbero prendere tante idee da Lisp per rendere python un po'migliore.

Il LISP lo conosco poco (ho studiato Scheme all'università, più che altro), e non so nulla delle implementazioni.

La cosa che più mi fa rabbia è che non ho abbastanza conoscenze informatiche per partecipare attivamente allo sviluppo!

Beh, c'è sempre tempo per imparare. Anzi, mettendo le man in pasta in genere si impara anche più velocemente.

Originariamente inviato da marco.r

Capisco la volonta' di mantere la chiarezza e da debuggabilita',

Sì, è esattamente questa la sua posizione.

nula vieterebbe pero' di aggiungere ottimizzazioni "opt-in" da usare solo quando uno ha imparato, o vuole spremere l'ultimo ciclo.
In Common Lisp ad esempio uno puo' dichiare la priorita' tra "speed" "debug", "safety".
Se speed e' piu' importante di safety il compilatore puo' decidere di non effettuare il controllo sui limiti di un array, oppure optare per effettuare la tail call di una chiamata ricorsiva se "speed" > "debug". Puoi pure deciderlo funzione per funzione. Questo mi sembrerebbe un buon compromesso.

Proposi qualcosa del genere (in stile pythonico) un po' di anni fa, in risposta a una mail nella mailing list degli sviluppatori. Ma la proposta non fu apprezzata...

[van9]

Originariamente inviato da marco.r

E' l'ecosistema nel suo complesso che conta. Puoi avere una linguaggio semplice come Java ma poi se le librerie e i framework principali sono immense torri di babele dove non trovi un singolo programmatore che le usi o le conosca allo stesso modo.

Il punto però era l'inerente complessità del C++, in risposta a "Non capisco inoltre tutta questa paura del c++". Poi volendo si può discutere anche di altro - tra Java e C++ in quanto a linguaggi/ecosistemi è un bel testa a testa su chi storicamente ha fatto e continua a fare di peggio. Personalmente saprei dire con certezza solo un tot (di negativo, ofc) sull'ecosistema Java/JVM perché lavoro a tempo pieno con altro (OCaml,Haskell,C,C++ e ultimamente F#) e quello che ho visto in passato mi è bastato e avanzato.

[mone.java]

Originariamente inviato da van9

Poi volendo si può discutere anche di altro - tra Java e C++ in quanto a linguaggi/ecosistemi è un bel testa a testa su chi storicamente ha fatto e continua a fare di peggio. Personalmente saprei dire con certezza solo un tot (di negativo, ofc) sull'ecosistema Java/JVM

Ovvero?

[AnonimoVeneziano]

Impara Swift e taglia la testa al toro

[van9]

Originariamente inviato da mone.java

Ovvero?

Difficile risponderti senza incorrere in una sorta di "blub paradox" per dirla alla Graham.