C++, Java o Python

[Daniels118]

Il c è noto che non sia un linguaggio ad oggetti, ma oggi ci sono tecniche per poterlo usare alla stregua del c++, il c però è nato imperativo perciò sarà un accrocchio ad oggetti perchè nonostante potremmo usarli faremo molta piu fatica rispetto a qualsiasi altro linguaggio nato cosi!

Siamo su due lunghezze d'onda differenti, continui a confondere le caratteristiche del linguaggio con le caratteristiche legate all'esecuzione del codice, io non ho mai detto che le varie tipologie di linguaggio sono equivalenti.

STESSO discorso per compilato ed interpretato, un linguaggio nasce per determinate caratteristiche quali anche la sua compilazione o interpretazione.
Vedi ad esempio il Phyton che nato interpretato è superiore a qualsiasi accrocchio di interprete c o c++

E' questa affermazione che non condivido, non tanto per quella che è la mia opinione, ma per la mancanza di prove oggettive al riguardo. Una cattiva implementazione di un interprete non dimostra l'impossibilità di ottenerne una buona.
Per contro posso portarti l'esempio del visual basic, che è nato per essere eseguito da un interprete e che successivamente ha avuto il suo compilatore: nella versione 6 era possibile compilare sia in p-code da interpretare, sia in codice nativo. E ti assicuro che quello compilato in codice nativo girava più veloce del p-code, sebbene il linguaggio fosse "nato interpretato".

[Daniels118]

Non solo java può fondere i vari linguaggi!Lo si può fare un pò con tutti,quindi rimane una caretteristica poco rilevante.

Ah certo, il mio era solo un esempio

[vbextreme]

Nonostante io sia un incallito sostenitore di vb devo ammettere che è stato un aborto da sempre!Chiamarlo poi linguaggio...
Ma queste sono considerazioni personali ricevute dalla mia esperienza. Tutto qui.
Quando un linguaggio è fatto bene vuol dire che ha uno scopo e i suoi creatori ne hanno tenuto in considerazione.
Il phyton ad esempio sa di essere interpretato quanto il c sa di essere compilato.
Per questo che il phyton non espone ad esempio l'inline assembly mentre il c si!
Tanto quanto il c++ sa di essere ad oggetti mentre il c no!
Un linguaggio non è solo un insieme di costrutti, ma anche come vengono eseguiti.
In definitiva un interprete c sarà sempre un accrocchio perchè non potrà mai e poi mai emulare tutte le funzionalità del reale c perchè il c è nato compilato.
Tanto quanto un compilatore phyton non potrà mai e poi mai emulare le potenzialità offerte dal linguaggio c perchè nato interpretato.
Poi esistono accrocchi per qualche ragione funzionante che permettono anche al vb6 di essere multithread, ma queste non sono la normalità, valgono solo per alcuni rari casi.

ma continuo a non capire:

Ad esempio rimanendo nell'inline assembly nel c# puoi usarlo direttamente compilare ed eseguire.
In java non puoi, allora devi ricorrere a qualche accrocchio che ti permetta di farlo, non dico che non si possa fare, ma è stata fatta una modifica perchè il linguaggio non lo permetterebbe.
Quindi se io ho scritto un programma in c# e lo voglio dopo x tempo ottimizzare con una funzione in assembly modifico e fatto.
In java molto probabilmente dovrei sbattere la testa in qua e la incrociandole le dita che il tutto funzioni.

[mone.java]

E quindi siccome in Java (per la sua natura multipiattaforma) non si può fare direttamente codice inline (ma cmq esiste JNI o JNA, quest'ultimo nemmeno richiede codice 'collante') sarebbe un linguaggio che PROVA ad essere un linguaggio?

[Daniels118]

Il phyton ad esempio sa di essere interpretato quanto il c sa di essere compilato.
Per questo che il phyton non espone ad esempio l'inline assembly mentre il c si!
Tanto quanto il c++ sa di essere ad oggetti mentre il c no!

Non vedo come un linguaggio possa avere la facoltà di "sapere"...

Un linguaggio non è solo un insieme di costrutti, ma anche come vengono eseguiti.

Beh, ma questa massima da dove l'hai presa?

Ad esempio rimanendo nell'inline assembly nel c# puoi usarlo direttamente compilare ed eseguire.
In java non puoi, allora devi ricorrere a qualche accrocchio che ti permetta di farlo, non dico che non si possa fare, ma è stata fatta una modifica perchè il linguaggio non lo permetterebbe.

Le jni non sono un accrocchio nato da una modifica, ma una parte vitale di java che collega la jvm al sistema operativo. Per esempio, l'implementazione della classe Thread fa uso di jni su tutti i sistemi che supportano nativamente il multithread (che sono il 99% dei dispositivi dove metteresti una jvm ).

[van9]

Originariamente inviato da vbextreme

La compilazione jit java e c# sono un pò diverse
c# compila direttamente frammenti di bytecode secondo alcune specifiche.
java analizza il bytecode e decide quale compilare e quale no

C# e Java sono *linguaggi* e *i linguaggi non compilano un bel niente*. Sono le loro implementazioni ad avere o meno certe caratteristiche. Se non si comprendono robe così semplici non ci può essere discussione.

Secondo la tua tesi, poi:
- usando C# con il .Net Framework (JIT finale una ed una sola volta verso codice macchina nativo interpretabile dalla CPU) -> "si vede chi è un linguaggio";
- usando C# con il .Net Compact Framework (JIT dinamico più volte se e quando ritenuto opportuno) -> "chi cerca di esserlo (un linguaggio)";
- usando C# con il .Net Micro Framework ("interpretazione nel senso classico", niente JIT) -> cosa, catastrofe? "linguaggio giocattolo"?

Che dici, hai scritto o meno un sacco di sciocchezze?

[van9]

Originariamente inviato da Daniels118

Beh, tecnicamente hai ragione, nel senso che un programma teoricamente puoi sia compilarlo che interpretarlo in qualunque linguaggio esso sia scritto, in pratica però per alcuni linguaggi attualmente esiste solo il compilatore e per altri solo l'interprete.

Personalmente avendo iniziato con Scheme, Common Lisp e C nei '90, la netta distinzione tra interpreti e compilatori mi è sempre sembrata una roba da confronto FORTRAN/Bourne shell. Molto più preciso e veritiero parlare di interpretazione della CPU e di livelli di traduzione via via che si considerano diversi livelli d'astrazione.

Per esempio si potrebbe creare un compilatore per vbscript, ma la realtà è che attualmente non esiste. Così come si potrebbe creare un interprete per il c++, ma mi sa che attualmente non esiste neanche quello. Poi ci sono le eccezioni come VB6 che poteva essere sia "compilato" in p-code (assimilabile al bytecode di java) che in codice macchina.
La tua affermazione resta comunque verissima e degna di nota.

Au contraire, un giapponese mi pare circa venti anni fa scrisse un sistema d'interprete per il C, che poi è diventato la base per Cling, l'interprete interattivo per il C++ sviluppato e in uso al CERN e che ho visto in azione su diversi cluster massivi di dati. Tra l'altro sempre lì hanno anche pyROOT (in Python) per l'interazione con il sistema ROOT - un buon esempio "dell'inutilità di python" per quell'altro genio nella prima pagina del thread. Ma onestamente passa pure la voglia di rispondere quando il livello delle discussioni vola così basso.

[van9]

Originariamente inviato da Daniels118

Non capisco inoltre tutta questa paura del c++, è un linguaggio come tanti altri, se uno vuole complicare la comprensione del codice ci può riuscire in qualunque linguaggio.

Cambierai idea il giorno che dovrai lavorare su code base di una certa dimensione insieme ad altri, anche loro convinti di quello che hai scritto qui sopra. E' solo questione d'esperienza ci siamo passati tutti

[Daniels118]

Originariamente inviato da van9

Personalmente avendo iniziato con Scheme, Common Lisp e C nei '90, la netta distinzione tra interpreti e compilatori mi è sempre sembrata una roba da confronto FORTRAN/Bourne shell. Molto più preciso e veritiero parlare di interpretazione della CPU e di livelli di traduzione via via che si considerano diversi livelli d'astrazione.

Verissimo anche questo, sono assolutamente d'accordo.

Au contraire, un giapponese mi pare circa venti anni fa scrisse un sistema d'interprete per il C, che poi è diventato la base per Cling, l'interprete interattivo per il C++ sviluppato e in uso al CERN e che ho visto in azione su diversi cluster massivi di dati. Tra l'altro sempre lì hanno anche pyROOT (in Python) per l'interazione con il sistema ROOT - un buon esempio "dell'inutilità di python" per quell'altro genio nella prima pagina del thread. Ma onestamente passa pure la voglia di rispondere quando il livello delle discussioni vola così basso.

Non a caso ho portato come esempio vbscript e non il c.

Originariamente inviato da van9

Cambierai idea il giorno che dovrai lavorare su code base di una certa dimensione insieme ad altri, anche loro convinti di quello che hai scritto qui sopra. E' solo questione d'esperienza ci siamo passati tutti

"Fortunatamente" credo che non ne avrò più l'occasione, comunque grazie per la dritta

[WarDuck]

Originariamente inviato da van9

Cambierai idea il giorno che dovrai lavorare su code base di una certa dimensione insieme ad altri, anche loro convinti di quello che hai scritto qui sopra. E' solo questione d'esperienza ci siamo passati tutti

Quello diventa un problema di ingegneria del software e di definizione di interfacce (API) soprattutto.

Nonostante questo comunque C++ rimane un linguaggio molto complesso, e forse il punto è che la forbice di "skill" tra gli sviluppatori può essere più ampia rispetto ad altri linguaggi, il che potrebbe penalizzare il lavoro in team.

[cdimauro]

Sono di frettissima, ma: http://nuitka.net/

[van9]

Originariamente inviato da WarDuck

Quello diventa un problema di ingegneria del software e di definizione di interfacce (API) soprattutto.

Si e il punto è che il C++ è tra i meno adatti a risolverlo.

Nonostante questo comunque C++ rimane un linguaggio molto complesso, e forse il punto è che la forbice di "skill" tra gli sviluppatori può essere più ampia rispetto ad altri linguaggi, il che potrebbe penalizzare il lavoro in team.

Avere una roadmap che per decenni è stata aggiungere sulle aggiunte non è che potesse portare ad altro.

[WarDuck]

Originariamente inviato da cdimauro

Sono di frettissima, ma: http://nuitka.net/

Interessante, e comunque non scordiamoci neanche di PyPy (a proposito di compilatori JIT) .

[van9]

Originariamente inviato da cdimauro

Sono di frettissima, ma: http://nuitka.net/

Mi piango ancora Unladen Swallow se è per quello. Il fatto che gente come Wouters non ce l'ha fatta mi ha sempre dato da pensare...
Di Pypy ho visto l'annuncio della stable ma non dovendo più scrivere Python da un pò non seguo e non so nulla.

[WarDuck]

Originariamente inviato da van9

Mi piango ancora Unladen Swallow se è per quello. Il fatto che gente come Wouters non ce l'ha fatta mi ha sempre dato da pensare...
Di Pypy ho visto l'annuncio della stable ma non dovendo più scrivere Python da un pò non seguo e non so nulla.

Fino a questo momento non mi è capitato di usarlo, ma:

http://speed.pypy.org/



La sezione "How has PyPy performance evolved over time?" è abbastanza illuminante.

Anche se già si intravede un limite superiore (non possono crescere all'infinito, ma questo è normale), allo stato attuale PyPy risulta mediamente 6 volte più veloce di CPython (l'attuale interprete Python).

In ogni caso ritengo che poi alla fine lì dove servono le prestazioni vere si implementa un bel modulo C e via .

[van9]

Originariamente inviato da WarDuck

Fino a questo momento non mi è capitato di usarlo, ma:

http://speed.pypy.org/



La sezione "How has PyPy performance evolved over time?" è abbastanza illuminante.

Anche se già si intravede un limite superiore (non possono crescere all'infinito, ma questo è normale), allo stato attuale PyPy risulta mediamente 6 volte più veloce di CPython (l'attuale interprete Python).

In ogni caso ritengo che poi alla fine lì dove servono le prestazioni vere si implementa un bel modulo C e via .

Si ma quello delle prestazioni più spinte è un problema risolto come dici e conta per una percentuale d'impiego in fondo modesta (i classici tight loops, uso di numpy e scipy, etc.). Se si potesse non dico raggiungere, ma almeno avvicinarsi un pò ad esempio a SBCL (che è dinamico e velocissimo ed è un ottimo metro di paragone per diverse cose in Python) tornerebbe utile per tutti e tutti i giorni.
Poi certo restano i soliti GIL, il gc non parallelo/concorrente, la noiosa ignoranza di Van Rossum circa quello che non gli piace... Ma non si può avere tutto. Anni fa lavorai in produzione con Stackless e mi divertii un mondo - peccato davvero non fosse quello il default.

Quella sezione è illuminante si. PyPy ha qualcosa come 11 anni. Undici anni... Purtroppo raggiungere certi risultati costa (e ne so qualcosa in prima persona) e non tutti hanno dietro gli investimenti di una Microsoft o Sun (compreso ad esempio OCaml con cui lavoro e a cui ancora manca un parallel gc performante).

[devil_mcry]

Originariamente inviato da Freaxxx

il C++ non è semplice, il C++ è davvero un linguaggio che devi sempre studiare constantemente, insieme al C sono i due maggiori linguaggi che forzano la mano su praticamente tutti gli aspetti della programmazione .

Hai mai letto parte o tutto il documento che definisce uno degli standard C++ ?

Con C++ devi prima determinare la versione che vuoi usare, poi ti scegli una implementazione del linguaggio e quindi un compilatore, una libreria standard e una libreria per le ABI, e poi puoi iniziare il cammino che non finirai mai, e questo solo per 1 piattaforma con 1 compilatore e 1 libreria standard.

In C++ ci sono persino i templates che da molti vengono definiti come un linguaggio nel linguaggio, prova a fare meta programmazione con C++ e vedrai, prova Boost::MPL e implementa qualcosa di simile da solo, tanti auguri.

Inizia con Java, è un linguaggio che va scomparendo, ma ha sempre 1 bel vantaggio sostanziale rispetto agli altri: ha una gestione automatizzata della memoria, tu scrivi il codice ed nel 99% dei casi puoi tranquillamente lasciare che la JVM faccia il resto nel gestire da sola la memoria, e la gestione della memoria in C e C++ non è davvero così semplice a volte.

Non focalizzarti sulle keyword, focalizzati sul come implementare algoritmi e strutture dati, lascia stare Python ( 1.x , 2.x e 3.x ) , è un linguaggio inutile e dannoso per quanto mi riguarda, sembra più uno scherzo che un linguaggio, tanto vale imparare Perl che almeno qualcosa lo ha apportato al mondo della programmazione.

Java è uno dei linguaggi più usati oggi giorno per la programmazione, altro che sta scomparendo.

Comunque per l'autore del topic, io ti consiglierei JAVA, non so che finalità ha la tua domanda ma diventare bravo con il JAVA apre facilmente sbocchi lavorativi, sopratutto sul mobile e lato server, che al momento tirano molto.

Noto che hanno citato il C#, altra buona base di partenza sia per la relativa semplicità, sia per l'ottimo IDE, considera che lo sviluppo delle app per WP passa da li (ma anche per Windows).

Credo che più che sulla differenza tra i linguaggi e i compilatori (o gli interpreti) dovresti considerare quale linguaggio oggi come oggi è più appetibile.

Se poi non ti interessa a livello professionale ma solo amatoriale, probabilmente la migliore soluzione per smanettare è punta al vb.net o c#

[cdimauro]

Originariamente inviato da WarDuck

Interessante, e comunque non scordiamoci neanche di PyPy (a proposito di compilatori JIT) .

E' quello che uso quando ho bisogno di prestazioni. :P

Peccato non posso integrarlo in PythonTools for VisualStudio (e mi pare pure con DreamPie).

Originariamente inviato da van9

Mi piango ancora Unladen Swallow se è per quello. Il fatto che gente come Wouters non ce l'ha fatta mi ha sempre dato da pensare...

Wouters non lo conosco, ma Unladen Swallon non mi ha convinto, e dopo qualche mese coi primi risultati mi fu chiaro che non sarebbe stato molto utile e, al contrario, avrebbe complicato enormemente CPython. Infatti mi opposi al merge di US in CPython.

Di Pypy ho visto l'annuncio della stable ma non dovendo più scrivere Python da un pò non seguo e non so nulla.

Va migliorando, anche se ormai non ci sono più i notevoli incrementi prestazionali delle prime versioni. Adesso puntano molto alla stabilità e compatibilità. L'ho usato e lo uso quando mi serve velocità, e devo dire che è molto compatibile e stabile.

[marco.r]

Originariamente inviato da van9

Cambierai idea il giorno che dovrai lavorare su code base di una certa dimensione insieme ad altri, anche loro convinti di quello che hai scritto qui sopra. E' solo questione d'esperienza ci siamo passati tutti

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.

Originariamente inviato da WarDuck

In ogni caso ritengo che poi alla fine lì dove servono le prestazioni vere si implementa un bel modulo C e via .

Questo pero' vuol dire che uno che vuole scrivere codice performante deve pero forza sobbarcarsi il C. Ammeso che lo sappia, resta poi il problema della portabilita' tra sistemi operativi diversi e tra implementazioni diverse del linguaggio. La quantita' di librerie python che fanno uso di moduli C non ha di certo aiutato la diffusione di implementazioni alternative.
Ci sono molti altri linguaggi dinamici che hanno ottenuto ottime performance senza dover ricorrere al C, e non sempre grazie a fondi generosi. Evidentemente gli sviluppatori e la comunita' non sono interessati, ma e' un peccato

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