C++, Java o Python

[van9]

Originariamente inviato da altermetax

Ok, allora continuo con il mio amato PHP (sì, per i miei siti e qualche progettino) e nel frattempo mi imparo un pò di Java, poi più avanti vedrò per gli altri.
Ciao!

PHP è oggettivamente una chiavica. E' come tentare d'imparare la logica intuizionistica da uno perennemente fatto di crack. Usa altro.

[mone.java]

altermetax: Se sei principiante ti consiglio di partire con python e non con java. Quest'ultimo può confondere all'inizio. Te lo dico da Javista

Originariamente inviato da Freaxxx

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.

Sentendoti parlare mi sembra di sentire i tifosi di calcio parlare delle rispettive squadre, nel bene e nel male.

[Daniels118]

L'eterna diatriba!

[mone.java]

Originariamente inviato da vbextreme

mentre col java hai sempre codice interpretato.
Questa è una grossa differenza che oltre ad aumentare le prestazioni del linguaggio ne permettono caratteristiche solo emulative da parte del java.
Molti linguaggi sono molto simili tra loro, ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo.

Spiegheresti meglio queste tue affermazioni.... sopratutto "ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo"

[Daniels118]

Originariamente inviato da mone.java

Spiegheresti meglio queste tue affermazioni.... sopratutto "ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo"

Io non sono d'accordo con il parere di vbextreme. Premesso che anche la jvm compila il codice a runtime grazie ad un componente denominato jit compiler (jit sta per just in time), un linguaggio è solo un formalismo, nulla vieta di scrivere un compilatore che traduce codice java in linguaggio macchina. E' ovvio che da questo punto di vista ci allontaniamo da quella che è la realtà per la maggior parte dei programmatori, ma il jit è reale. Comunque i linguaggi interpretati vanno benissimo per applicazioni di accesso ai dati e piccole elaborazioni, mentre ottengono pessimi risultati su elaborazioni lunghe come il calcolo numerico (a meno che non utilizzino librerie native, ma in questo caso l'elaborazione viene fatta dal codice compilato). Quello che penalizza parecchio le performance invece è la gestione automatica della memoria, però rende sicuramente più semplice lo sviluppo del codice, inoltre se la gestione della memoria è affidata al programmatore e questi si dimentica di deallocare qualcosa, si va incontro a grossi problemi, specie in applicazioni che restano aperte per lunghi periodi.
Sarà che sono vecchio, ma preferisco i linguaggi compilati e la gestione manuale della memoria.

[mone.java]

Infatti era il punto dove volevo arrivare, ovvero che Java ha un compilatore JIT esattamente come C#. Volevo appunto una spiegazione più approfondita, magari sono io che mi sono perso qualcosa

1) mentre col java hai sempre codice interpretato.
2) caratteristiche solo emulative da parte del java.
3) ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo

Il punto 1 abbiamo visto che è errato... sono curioso sui restanti.

[van9]

Originariamente inviato da mone.java

Spiegheresti meglio queste tue affermazioni....

Non può, non conosce nemmeno la piattaforma per cui "parteggia" ("il c sharp non ha quell'obrobrio di virtual machine") figuriamoci quelle che vuole screditare.

[van9]

Originariamente inviato da mone.java

Infatti era il punto dove volevo arrivare, ovvero che Java ha un compilatore JIT esattamente come C#

Sono le implementazioni ad averlo non i linguaggi Java e C#. Una certa molto diffusa implementazione può avere sia un "Classic VM" compiler e un JIT compiler; un altra userà un AoT di default e avrà il JIT solo come opzionale, e via così.

E' una precisazione importante, visto quanti ancora nel 2014 parlano inutilmente degli inesistenti "linguaggi compilati/interpretati".

[mone.java]

Originariamente inviato da van9

Sono le implementazioni ad averlo non i linguaggi Java e C#. Una certa molto diffusa implementazione può avere sia un "Classic VM" compiler e un JIT compiler; un altra userà un AoT di default e avrà il JIT solo come opzionale, e via così.

E' una precisazione importante, visto quanti ancora nel 2014 parlano inutilmente degli inesistenti "linguaggi compilati/interpretati".

Si hai ragione, giusta precisazione, diciamo che facevo riferimento alle implementazioni più utilizzate rispettivamente di Java, Oracle e OpenJDK che sono piu o meno la stessa cosa, (senza contare le 2 implementazioni di android, Delvik JIT, e ART AOT ) e C#, Microsoft e Mono.

[van9]

Originariamente inviato da killercode

Ne avessi detta una giusta... ma una eh, non tutte, una sola

La prima ("il C++ non è semplice") era giustissima. Il problema è che, in tipico macho-style dei '80-90, per lui è un vanto e non un handicap.

[Daniels118]

Originariamente inviato da van9

Sono le implementazioni ad averlo non i linguaggi Java e C#. Una certa molto diffusa implementazione può avere sia un "Classic VM" compiler e un JIT compiler; un altra userà un AoT di default e avrà il JIT solo come opzionale, e via così.

E' una precisazione importante, visto quanti ancora nel 2014 parlano inutilmente degli inesistenti "linguaggi compilati/interpretati".

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

[mone.java]

Per java esiste più di un compilatore nativo.. GCJ della famiglia GNU che però è fermo a java5 (forse anche prima).. E un software della excelsior che crea eseguibili sia per architetture x86 che x64.. quest'ultimo è a pagamento.. C# non ne so niente.. Inoltre java stesso si comporta in modo diverso in base ai parametri con il quale viene avviato (-server) che decidono se applicare o meno certi tipi di ottimizzazione (questo parametro inoltre è abilitato di default se la JVM decide che il computer che la ospita è abbastanza potente)..

Quindi ha ragione anche in pratica è io ho scritto una boiata prima

[Daniels118]

Originariamente inviato da mone.java

Per java esiste più di un compilatore nativo.. GCJ della famiglia GNU che però è fermo a java5 (forse anche prima).. E un software della excelsior che crea eseguibili sia per architetture x86 che x64.. quest'ultimo è a pagamento.. C# non ne so niente.. Inoltre java stesso si comporta in modo diverso in base ai parametri con il quale viene avviato (-server) che decidono se applicare o meno certi tipi di ottimizzazione (questo parametro inoltre è abilitato di default se la JVM decide che il computer che la ospita è abbastanza potente)..

Quindi ha ragione anche in pratica è io ho scritto una boiata prima

Nessuno è onnisciente, e comunque nulla vieta che un domani venga creato un nuovo compilatore/interprete per un linguaggio che fino ad oggi ha solo uno dei due. In effetti java è sempre stato un "linguaggio compilato", solo che il processore per eseguirlo non è mai esistito. Anzi, ricordo di aver letto tempo fa che un'azienda ha realizzato un processore capace di eseguirne direttamente il bytecode, però non ha avuto futuro.

[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,si avrà quindi un miscuglio, e non sapremo mai come la jvm stia elaborando i nostri dati.
Questo ad esempio implica che col java non si può lavorare con dei puntatori reali proprio perchè diventa complesso la gestione della memoria da parte della jvm(segnalata anche proprio dal consumo superiore rispetto al c#).
Cosa differente per il c# che compilando comunque tutto può concedere l'unsafe ed accedere "manualmente" alla memoria.
Ho cercato di dirlo nella maniera piu corta e semplice possibile,quindi tralasciamo i piccolissimi dettagli.

Lasciamo poi perdere i vari accrocchi di interprete/compilatore per tutti i liguaggi esistenti ma basiamoci per quello che sono stati creati.

E' una precisazione importante, visto quanti ancora nel 2014 parlano inutilmente degli inesistenti "linguaggi compilati/interpretati".

No! ci sono reali differenze sostanziali,ancor di piu nel 2014!
Il tutto risiede dal tipo di applicazione che si vuole sviluppare e per che architettura lo si vuole fare.
Un linguaggio nato interpretato avrà caratteristiche ben diverse da un linguaggio nato compilato

[Daniels118]

Lasciamo poi perdere i vari accrocchi di interprete/compilatore per tutti i liguaggi esistenti ma basiamoci per quello che sono stati creati.

Ma questo è un vincolo che hai deciso tu di imporre, e se ci mettiamo in quest'ottica hai perfettamente ragione, però così facendo siamo noi stessi a definire dei limiti, limiti che potremmo banalmente evitare.
Dimmi tu secondo te cos'è un linguaggio se non un formalismo per dire ad un esecutore quali operazioni compiere.
Secondo me troppo spesso si fa confusione tra quelle che sono le caratteristiche di un linguaggio e quelli che sono gli strumenti disponibili in un dato contesto.
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.

[vbextreme]

Ma questo è un vincolo che hai deciso tu di imporre

No,questo vincolo l'ha deciso chi ha sviluppato il linguaggio,solo dopo sono nati accrocchi per esaudire tutte le esigenze dei programmatori nati sopratutto per risolvere casi specifici e non per il corretto funzionamento del linguaggio.

Dimmi tu secondo te cos'è un linguaggio se non un formalismo per dire ad un esecutore quali operazioni compiere.

Estto, ogni linguaggio è quindi strutturato in modo che sia perfetto per l'esecutore che lo andrà ad elaborare.
Cosi come un linguaggio può essere Imperativo altri potranno essere ad oggetti o ancora altri puramente matematici o interpretati o compilati.
Sicuramente esisterà anche un interprete dell'assembly ma il linguaggio non è stato creato per quello e per tanto risulterà impraticabile il suo utilizzo se non per circostanze circoscritte ad una singola applicazione.
Un linguaggio "nato" interpretato allora invece svolgerà sicuramente meglio i compiti di quelli "modificati" interpretati.
Il discorso è molto lungo e complesso e per quello ho voluto sottolineare il fatto di prendere un linguaggio per quello che è nato e non per come l'hanno modificato.

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.

Effettivamente il linguaggio in se stesso non è molto piu complicato del java o altri oop.
Solo che le sue potenzialità lo rendono alquanto complesso,ancor piu del c per il semplice fatto che il c++ ha la pessima caratteristica di nascondere molto al programmatore.
Il c++ poi rimane affetto della scarsa portabilità se non con l'ausilio di framework ad hoc + un cospicuo uso di define e connessa ricompilazione del tutto sulla piattaforma desiderata.
Creare dunque una semplice finestra che faccia semplici cose risulta molto piu complesso e lungo sul c++(seguito dal java) rispetto al phyton.
Ma qui si va poi sempre a finire sul discorso di cosa vogliamo realizzare e generalizzare in questo caso fa piu male che bene.

[mone.java]

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,si avrà quindi un miscuglio, e non sapremo mai come la jvm stia elaborando i nostri dati.
Questo ad esempio implica che col java non si può lavorare con dei puntatori reali proprio perchè diventa complesso la gestione della memoria da parte della jvm(segnalata anche proprio dal consumo superiore rispetto al c#).
Cosa differente per il c# che compilando comunque tutto può concedere l'unsafe ed accedere "manualmente" alla memoria.
Ho cercato di dirlo nella maniera piu corta e semplice possibile,quindi tralasciamo i piccolissimi dettagli.

Si questo è vero. Ma in quanto alle performance saprai mostrarmi benchmark (recenti) che dimostrano la la maggiore velocità di CLR rispetto alla JVM a "parità" di codice eseguito.

ma mancano le risposte alla domanda 2 e la domanda 3 (sopratutto il punto 3):

2) caratteristiche solo emulative da parte del java.
3) ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo

[Daniels118]

No,questo vincolo l'ha deciso chi ha sviluppato il linguaggio,solo dopo sono nati accrocchi per esaudire tutte le esigenze dei programmatori nati sopratutto per risolvere casi specifici e non per il corretto funzionamento del linguaggio.

Ma noi non viviamo nel passato, se oggi una cosa esiste non vedo perché dovremmo ignorarla.

Cosi come un linguaggio può essere Imperativo altri potranno essere ad oggetti o ancora altri puramente matematici o interpretati o compilati.

La tua affermazione non è errata, ma incompleta. Tu stai elencando un insieme di caratteristiche dei linguaggi senza tenere conto di alcuna tassonomia, in altre parole stai confondendo le caratteristiche relative alla modalità di esecuzione con quelle relative alla natura del linguaggio stesso.
Non ha senso distingue i linguaggi <<ad oggetti>> da quelli <<compilati>>, infatti i linguaggi ad oggetti esistono sia compilati (come il C++), sia interpretati (come python). Lo stesso discorso possiamo applicarlo alle altre tipologie di linguaggi.
Il fatto che per alcuni linguaggi esista solo il compilatore o solo l'interprete è un altro discorso, non meno importante certo, ma comunque distinto.
In fin dei conti, se io so di dover scrivere un programma che fa un'elaborazione estremamente pesante sceglierò un linguaggio per il quale so che esiste un compilatore, mentre per applicazioni leggere preferirò un linguaggio per il quale so che esistono numerose librerie semplici da utilizzare, per un'applicazione rivolta al grande pubblico invece sceglierò il linguaggio per il quale so che esistono compilatori o interpreti per il maggior numero di piattaforme, ancora, se devo unire due o più di queste caratteristiche cercherò di sviluppare ogni componente dell'applicazione nel linguaggio che meglio si presta e poi le unirò.
Quest'ultima tecnica è utilizzata ad esempio fondendo java e c/c++ grazie al meccanismo jni, con il quale si possono "mappare" dei metodi su delle funzioni contenute in dll e quindi scritte in codice macchina altamente performante.
Il vantaggio è di poter scrivere la maggior parte del codice in un linguaggio più "semplice", portabile, e per il quale sono disponibili più librerie, e di dover riadattare alle varie piattaforme solo la parte critica dell'applicazione.

[vbextreme]

Si questo è vero. Ma in quanto alle performance saprai mostrarmi benchmark (recenti) che dimostrano la la maggiore velocità di CLR rispetto alla JVM a "parità" di codice eseguito.

Non ho mai parlato di performance, che a ragion di logica è veramente superficiale per tali linguaggi, agguerrirsi quindi per che a va piu veloce di b per eseguire c e b va piu veloce di a ad eseguire d è una pagliacciata.
Se un programmatore vuole realmente le prestazioni al 100% certamente non userà ne java ne c# o ancor piu il phyton.
i punti 2/3 li ho già accennati vedi ad esempio l'uso dei puntatori, ma non prolunghiamoci inutilmente su queste "guerre" inutili.

Ma noi non viviamo nel passato, se oggi una cosa esiste non vedo perché dovremmo ignorarla.

La tua affermazione non è errata, ma incompleta. Tu stai elencando un insieme di caratteristiche dei linguaggi senza tenere conto di alcuna tassonomia, in altre parole stai confondendo le caratteristiche relative alla modalità di esecuzione con quelle relative alla natura del linguaggio stesso.
Non ha senso distingue i linguaggi <<ad oggetti>> da quelli <<compilati>>, infatti i linguaggi ad oggetti esistono sia compilati (come il C++), sia interpretati (come python). Lo stesso discorso possiamo applicarlo alle altre tipologie di linguaggi.

Il mio voleva essere un esempio ma forse sono stato frainteso.
Provo con un altro esempio:
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!
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++,perchè offre potenzialità e comandi dati proprio dalla sua consapevolezza di essere interpretato, cosa che nel c/c++ non esiste! E spesso è anche da modificare il codice c interpretato perchè certi frammenti di codice quali spesso inline assembly non si possono interpretare!
Oggi come oggi esistono dunque interpreti e compilatori per quasi tutti i linguaggi ma le caratteristiche intrinsiche del linguaggio stesso portano a scegliere chi è nato per uno specifico scopo rispetto ad altri.
Poi naturalmente è sempre necessario valutare caso per caso e scegliere quello che piu si adatta alle nostre caratteristiche.

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

[mone.java]

Originariamente inviato da vbextreme

Non ho mai parlato di performance, che a ragion di logica è veramente superficiale per tali linguaggi, agguerrirsi quindi per che a va piu veloce di b per eseguire c e b va piu veloce di a ad eseguire d è una pagliacciata.
Se un programmatore vuole realmente le prestazioni al 100% certamente non userà ne java ne c# o ancor piu il phyton.

Sono completamente d'accordo ma tu hai scritto:

Questa è una grossa differenza che oltre ad aumentare le prestazioni del linguaggio ne permettono caratteristiche solo emulative da parte del java.

ma continuo a non capire:

3) ma nelle loro piccole differenza si vede chi è un linguaggio e chi cerca di esserlo

Mi spiego meglio: cosa significa ESSERE UN LINGUAGGIO e CERCARE DI ESSERE UN LINGUAGGIO?