Linguaggi a confronto.

[AmigaCori]

• 

:auto-car: ----->----->-----> :auto-checkeredflag:  Dall'OT del thread: [Hollywood] Introduzione + Help Library


Continuate  :angry-teeth:



 :mrgreen:

[Z80Fan]

• 

se si modernizzasse di spazio ce ne sarebbe abbastanza.

Esatto, al giorno d'oggi. Ovviamente quando è stato concepito tutti quei codici erano importanti.

Ma sai com'è, gli standard non si toccano, meglio rimpiangere le vecchie scelte ;-)

Mi sembra anche ovvio; ASCII è perfetto per quello che deve/doveva fare, non puoi prenderlo, modificarlo e chiamarlo ancora ASCII, o ISO 646 (o meglio, modificarlo nei codici di controllo, perchè modifiche locali ad alcuni simboli sono state già fatte, anche se il cosiddetto ASCII è quello primo americano).
Modificare lo standard significa rendere inutilizzabili tutte le macchine vecchie che dipendono da tali codici di controllo, e ciò concorderai non è fattibile.
Se vuoi migliorare la situazione, attui le opportune modifiche e rilasci un nuovo standard.

[Z80Fan]

• 

Feature che reputo inutile, il codice andrebbe scritto in un linguaggio che tutti dovrebbero comprendere (tipo inglese).

Perchè, inglese è un linguaggio che tutti conoscono?
E' solo perchè la tecnologia si è sviluppata negli USA e si sono poi diffuse le macchine statunitensi che usiamo linguaggi che ricordano la lingua inglese, e che il linguaggio di Internet è diventato quello.
Cosa sarebbe successo se (guerra a parte) si fossero diffusi gli Zuse? Saremmo qua tutti a discutere dei pregi e difetti del Plankalkül in tedesco? Immagina poi se fossero diventati famosi i giapponesi...
Si da la possibilità di scrivere nel modo in cui si vuole, e con i simboli che si preferisce (rimanendo all'interno della sintassi generale del linguaggio, ovvio). Se poi il listato è illeggibile al di fuori di uno sperduto villaggio dell'Asia, chi se ne frega, non lo userà nessuno.
Bisogna dare delle responsabilità al programmatore, e non sempre puntare il dito al linguaggio che "non obbliga a una scrittura corretta", "non previene tali errori" ecc...
Un linguaggio di programmazione deve fornire un modo per dare istruzioni a un computer; ci sarà della simbologia da seguire, ovvio, ma poi il programmatore deve poter fare come vuole. Se è necessario lavorare in gruppo, ci si metterà d'accordo sulle linee da seguire.

Chiedo scusa per lo sfogo e per il semi-OT (ora AmigaCori mi apre un nuovo thread sulle responsabilità del programmatore :lol:), ma per tanto tempo e in molti luoghi (non qui) ho visto dare colpe dei programmatori ai linguaggi, che di colpa hanno ben poco.

[cdimauro]

• 

Premetto che sono d'accordo con dsar per quanto detto prima. Aggiungo qualcosina di mio.

Il compound assignment è la seconda caratteristica peggiore del C dopo l'equivalenza expression/statement.

Come sopra, non ci trovo nulla di male, idem per la seconda. Poi, se qualcuno le usa a sproposito rendendo il tutto una matassa illeggibile, non penso si possano dare tutte le colpe al linguaggio.

Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.

E' una delle cause principali di bug nei programmi. Un'altra è dimenticare l'& in roba come scanf et similia.

Visto che tu sei "quello delle citazioni" , te ne propongo una che avevo letto da qualche parte: "UNIX non impedisce all'utente di fare cose molto stupide, perchè gli impedirebbe di fare anche cose molto intelligenti".
Se poi era solo una scusa per nascondere i bug e farli sembrare features, questo non posso dirlo! :lol:

La seconda che hai detto.

E così C divenne un linguaggio che piace a tutti perché molto diffuso :-)

Può piacere o Deve piacere. Nella tua frase stà meglio la seconda versione.
Lo uso (insieme al C++) senza grossi problemi, non trovo tutta 'sta anarchia nella sintassi come molti urlano in giro.
Ho usato/userò ancora Python, vari Basic, vari linguaggi di Script; non sono stato tanto li a interrogarmi sui motivi filosofici della sintassi, la usavo e basta (ad esempio: perchè in Python devo terminare la riga di un if con i due punti ":"? il newline non bastava a delimitare?).

Qui trovi qualcosa sul perché dei :

Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.

E non dite che è perchè arrivo dal C++ e quindi sono pronto a tutto!  

Purtroppo sei già stato contaminato.

se si modernizzasse di spazio ce ne sarebbe abbastanza.

Esatto, al giorno d'oggi. Ovviamente quando è stato concepito tutti quei codici erano importanti.

Ma sai com'è, gli standard non si toccano, meglio rimpiangere le vecchie scelte ;-)

Mi sembra anche ovvio; ASCII è perfetto per quello che deve/doveva fare, non puoi prenderlo, modificarlo e chiamarlo ancora ASCII, o ISO 646 (o meglio, modificarlo nei codici di controllo, perchè modifiche locali ad alcuni simboli sono state già fatte, anche se il cosiddetto ASCII è quello primo americano).
Modificare lo standard significa rendere inutilizzabili tutte le macchine vecchie che dipendono da tali codici di controllo, e ciò concorderai non è fattibile.
Se vuoi migliorare la situazione, attui le opportune modifiche e rilasci un nuovo standard.

Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/

Ricordo che l'agenzia spaziale russa dovette rifiutare un software perché documentazione, commenti e nomi di identifier erano in francese e nessuno ci capì nulla. Bene o male chi lavora in questo settore l'inglese lo conosce.

Tutti i miei progetti (personali e non) hanno identifier e commenti in inglese.

Certo si potrebbe adottare un linguaggio funzionale, formato solo da simboli matematici, universale per tutti! Magari adottare pure la tastiera usata per Algol 60.

Io non ho nulla contro un linguaggio universale a simboli, il problema è che viviamo una realtà molto diversa da quella ideale. Se il linguaggio matematico, a partire dalla logica, fosse insegnato dalla scuola elementare, allora lì saremmo talmente abituati che potremmo leggere 200 - 300 pagine di un programma fatto di simboli senza stancarci.
Purtroppo la realtà è un'altra. Io studio fisica e per me se una dimostrazione matematica superasse le due pagine la troverei stancante.

Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente, probabilmente io potrei far parte di quella categoria, perché il codice scritto da altri non sempre lo capisco ;-)

Guardati i sorgenti di Elastix... in spagnolo. :lol:

[AmigaCori]

• 

Chiedo scusa per lo sfogo e per il semi-OT (ora AmigaCori mi apre un nuovo thread sulle responsabilità del programmatore :lol:), ma per tanto tempo e in molti luoghi (non qui) ho visto dare colpe dei programmatori ai linguaggi, che di colpa hanno ben poco.

Gli OT sono tollerati  :geek:  i Thread "annidati" no  :angry-cussingwhite:

 :mrgreen:

[Z80Fan]

• 

Ricordo che l'agenzia spaziale russa dovette rifiutare un software perché documentazione, commenti e nomi di identifier erano in francese e nessuno ci capì nulla. Bene o male chi lavora in questo settore l'inglese lo conosce.

Se un software lo scrivi per poi darlo in giro, è ovvio che devi scegliere un linguaggio adatto.
Metti invece un software a uso interno, scriverlo nella lingua nativa dei programmatori sarebbe un vantaggio; conosco gente "del settore" che esegue i più banali errori di grammatica e/o sintassi in inglese, immaginateli a scrivere una documentazione (poi ovviamente il codice riflette la loro conoscenza della lingua ).
Quindi, tornando al fatto di permettere l'uso di Unicode nei listati: io penso che sia Cosa Buona e Giusta © .

Certo si potrebbe adottare un linguaggio funzionale, formato solo da simboli matematici, universale per tutti! Magari adottare pure la tastiera usata per Algol 60.

Però gli identificatori bisogna lo stesso scriverli in lettere, e torniamo al discorso di prima .

Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente

Quindi scriverlo nella lingua nativa lo può rendere più accessibile.

perché il codice scritto da altri non sempre lo capisco ;-)

Ci sono talmente tanti modi di scrivere un codice e implementare un algoritmo che questo frase è vera per tutti i programmatori.

Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.

L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) .

Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.

Come dice uno dei commenti a quel post: allora bisognerebbe anche preservare il punto e virgola alla fine di ogni statement.

Purtroppo sei già stato contaminato.

Invece, provenendo da questo linguaggio, sono più resistente e adattabile a stranezze di nuovi linguaggi. :ugeek:

Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/

Solo l'interpretazione dei simboli è stata modificata nello standard; il significato sei singoli simboli non è cambiato (che è quello che conta di più ed è quello per cui si discuteva).

[cdimauro]

• 

Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente

Quindi scriverlo nella lingua nativa lo può rendere più accessibile.

Sì, ma ha senso farlo a scopo didattico. Ed è questo il motivo per cui a partire da Python 3 i sorgenti sono codificati in UTF-8 e il linguaggio permette di utilizzare simboli Unicode come identificatori.

Questo ha senso perché Python è nato come linguaggio didattico, e continua in questa sua strada.

Ma NESSUN PROFESSIONISTA scriverebbe mai commenti in una lingua diversa dall'inglese, o identificatori non ASCII.

Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.

L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) .

Il linguaggio (mi riferisco al K&R e al draft ISO) NON specifica nulla del genere.

Questa è un'AGGIUNTA, NON standardizzata, a quello che è un evidentissimo difetto di progettazione del linguaggio. Esattamente come qualche anno dopo spuntò fuori lint per eseguire un controllo più rigoroso dei sorgenti scritti correttamente in C, ma che potevano avere problemi come quelli segnalati.

Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.

Come dice uno dei commenti a quel post: allora bisognerebbe anche preservare il punto e virgola alla fine di ogni statement.

Bisogna anche capirle le cose. Il : evidenzia una decisione presa dal programmatore. E' successo un evento che modifica il normale flusso del programma -> eseguo determinate, specifiche, azioni. Ecco perché lo ritrovi negli if, while, def, class, ecc.

Il ; si continua a usare pure in Python (sebbene NON sia preferito) per lo stesso motivo per cui in inglese (ma anche in italiano) vogliamo aggiungere qualcos'altro alla STESSA frase (nel caso di Python, frase = riga di codice).

Se si usa il whitespace al posto del . (perché avrebbe avuto senso il . e non il ; da usare per delimitare un'istruzione) è perché si ricalca l'uso dello pseudocodice. O, da essere umano, vedila come la lista della spesa / cose da fare, o una ricetta.

Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/

Solo l'interpretazione dei simboli è stata modificata nello standard; il significato sei singoli simboli non è cambiato (che è quello che conta di più ed è quello per cui si discuteva).

[/quote]
L'interpretazione attiene al significato, ed è stato cambiato. Perché un Carriage Return ha un bel preciso significato, e un Line Feed pure.

Non si può prendere un Line Feed e farlo diventare magicamente un New Line, che è una cosa completamente diversa.

Per il resto, continuo a concordare con dsar.

EDIT: rileggendo mi rendo conto di essere stato un po' duro. Non mi riferivo a te, ma quelli che hanno scritto quei commenti su : & co.

[TheKaneB]

• 

Però gli identificatori bisogna lo stesso scriverli in lettere, e torniamo al discorso di prima .

Se il linguaggio non ti aiuta, una buona scelta degli identifier non aiuta nella leggibilità del software. Vedi Haskell:

Codice: [Seleziona]

insertBy :: (a -> a -> Ordering) -> a -> [a] -> [a]
insertBy _   x [] = [x]
insertBy cmp x ys@(y:ys')
 = case cmp x y of
     GT -> y : insertBy cmp x ys'
     _  -> x : ys
O ancora peggio:

Codice: [Seleziona]

trimLookupLo :: Ord k => k -> (k -> Ordering) -> Map k a -> (Maybe (k,a), Map k a)
trimLookupLo lo cmphi Tip = (Nothing,Tip)
trimLookupLo lo cmphi t@(Bin sx kx x l r)
  = case compare lo kx of
      LT -> case cmphi kx of
              GT -> (lookupAssoc lo t, t)
              le -> trimLookupLo lo cmphi l
      GT -> trimLookupLo lo cmphi r
      EQ -> (Just (kx,x),trim (compare lo) cmphi r)
E questi sono casi semplici di algoritmi semplici.

I linguaggi funzionali li capisco (anche se non sono abituato alla lettura), ma dopo un po' mi fanno venire il mal di testa.

L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) .

Lasciando perdere l'equivalenza.
Un linguaggio che permette (anzi, il K&R lo consiglia per gli esperti!) questo mix tra statement ed expression per copiare una stringa:

Codice: [Seleziona]

while ((s[i++] = t[j++]) != '');
non merita di essere chiamato linguaggio.

Quotoski!

l'Haskell non si può leggere, per cortesia X_x
Ho provato a studiare un po' lo Scheme, seguendo le videolezioni di Berkeley... potente come linguaggio, ma va bene (secondo me) solo per programmini da pippa mentale accademica che non superino le 100 righe di codice.
Per fare un software applicativo è inaccettabile.

PS: Ma lo schema di uno spreadsheet moderno, con formule condizionali e operazioni su array, può definirsi come una forma di programmazione funzionale?

[cdimauro]

• 

Penso di sì. Alla fine tutto viene ricondotto a chiamata e/o composizione di funzioni (per valutare espressioni).

P.S. Nemmeno a me piacciono i linguaggi funzionali. Python mette a disposizione alcuni costrutti di questo tipo, ma fortunatamente rimane leggibile.

[Z80Fan]

• 

Un linguaggio che permette (anzi, il K&R lo consiglia per gli esperti!) questo mix tra statement ed expression per copiare una stringa:

Codice: [Seleziona]

while ((s[i++] = t[j++]) != '');
non merita di essere chiamato linguaggio.

Il C/C++ permette di scrivere ciò; non obbliga.
Ora non so perchè il K&R consigli quella scrittura; fatto sta che torniamo al discorso di prima: è colpa del linguaggio, o è colpa del programmatore?
Se un programmatore scrive quella cosa li, vabbè, verrà riconosciuto come un magari bravo analista ma come discreto programmatore.
Qualcosa forse impedisce di scrivere:

Codice: [Seleziona]

while (t[j] != '')
{
    s[i] = t[j];
    i++;
    j++;
}? No, e questo secondo me è assolutamente lecito, perchè un linguaggio di programmazione, in quanto strumento utile all'uomo, deve lasciargli ampio raggio d'azione; se poi il programmatore non è capace, è colpa del programmatore. Per assurdo, sarebbe come dar la colpa al cemento o ai mattoni se il muratore fa il muro storto.
Come tutti gli strumenti, ci sono linguaggi più facili da usare, linguaggi adatti a esprimere calcoli matematici complessi, linguaggi per comandare un robot industriale... a ognuno il suo strumento.

Bisogna anche capirle le cose. Il : evidenzia una decisione presa dal programmatore. E' successo un evento che modifica il normale flusso del programma -> eseguo determinate, specifiche, azioni. Ecco perché lo ritrovi negli if, while, def, class, ecc.

Il ; si continua a usare pure in Python (sebbene NON sia preferito) per lo stesso motivo per cui in inglese (ma anche in italiano) vogliamo aggiungere qualcos'altro alla STESSA frase (nel caso di Python, frase = riga di codice).

Se si usa il whitespace al posto del . (perché avrebbe avuto senso il . e non il ; da usare per delimitare un'istruzione) è perché si ricalca l'uso dello pseudocodice. O, da essere umano, vedila come la lista della spesa / cose da fare, o una ricetta.

Provo a fare una piccola analisi partendo da queste definizioni di Wikipedia (prese da li per comodità):
- Due Punti
- Punto e virgola

Nella lingua italiana, la funzione fondamentale dei due punti è quella esplicativa: una frase introdotta da essi (come quella che si sta leggendo in questo momento) serve difatti a chiarire il significato della proposizione che la precede. Nonostante questo sia l'uso più affermato dei due punti, ne esistono anche di diversi:
    + i due punti, come si può notare in questo testo, possono precedere una lista numerata o dotata di punti elenco;

Il punto e virgola indica la fine del concetto espresso nella frase al cui termine si trova il segno di interpunzione in questione; tale concetto si ricollega alla più grande idea di cui tratta l'intero periodo. Il punto e virgola non indica perciò né la fine dell'idea generale (come farebbe il punto), né la continuazione del concetto minore (che costituisce il ruolo della virgola), ma qualcosa di intermedio tra queste due funzioni.

Se consideriamo il "periodo" come un blocco di codice, "concetto" come linea di codice (qualcosa che partecipa a definire l'intero pensiero espresso dal codice), allora è corretto usare i due punti all'inizio di un blocco (come se fosse un elenco puntato), il punto e virgola per separare le linee nel blocco, e il punto finale per chiudere un blocco. La virgola dividerebbe istruzioni all'interno di una singola riga; il C/C++ la ha (io veramente non la ho mai usata, la ho vista usare all'interno del terzo campo del for per incrementare più variabili insieme, che forse è l'unico utilizzo dove ha un significato appropriato. Python la usa già meglio per fare le assegnazioni tipo a,b,c = 1,2,3 che voi Pythoniani sapete come si chiamano ).

Questo è come la penso io; sarà per questo che non vedo tutti questi problemi del C/C++.

Ah, giusto per mettere le cose in chiaro, non voglio dire che i linguaggi che proponete voi non siano adatti o siano errati; il Python ad esempio (proprio uno a caso ) lo reputo un gran linguaggio; sto solo difendendo il C/C++ che da più parti è sempre maltrattato. :cry:

[cdimauro]

• 

E lo è a buon ragione, perché il nocciolo della questione, come tra l'altro rimarcato dagli stessi creatori, è che il C è nato con uno scopo ben preciso: velocizzare le scrittura del codice.

Le scelte sintattiche riflettono questo concetto, come penso sarà chiaro a tutti. Inoltre per rendere più semplice e veloce (ancora una volta) la scrittura del relativo compilatore, il linguaggio nacque povero di costrutti sintattici tesi alla scrittura di codice meno suscettibile a commettere errori.

Lo si vede dalla clamorosa mancanza del passaggio dei parametri per riferimento, che costringe fin dal più semplice programma a far uso dei puntatori (vedi il solito esempio della scanf).

Lo si vede anche dall'uso del preprocessore persino nella definizione di costanti (prima non esisteva la keyword const!), per non parlare delle macro (e dei terribili effetti collaterali che possono provocare!). Roba da assemblatore, insomma.

Lo si vede anche nella facilità di passaggio da intero a puntatore e viceversa, che tanti danni ha fatto.

Ciò che tu ritieni un'espressione di libertà, in realtà è frutto della ricerca di velocità di scrittura del codice e del compilatore. Che tanti danni ha fatto, e continua a fare. E non è un caso che, come nell'esempio di cui sopra, per sopperire a queste mancanza si è provveduto nel tempo a utilizzare tool esterni come lint, oppure all'aggiunta di warning per segnalare del codice che FORSE è errato.

E' innegabile che dipende tutto da come lo usa il programmatore, ma è altrettanto innegabile che parliamo di un linguaggio che ti porta con molta più facilità a commettere errori rispetto ad altri linguaggi di programmazione.

Senza considerare, e chiudo, che in genere i linguaggi di programmazione hanno portato a una qualche novità nella letteratura informatica. Il C cos'ha portato? Perché nei primi anni veniva deriso come "Pascal mascherato"?

[Z80Fan]

• 

E' per questo che uso C++! :lol:

Cmq, io alla fine gli unici errori di sintassi che compio sono la mancanza di qualche punto e virgola (tipico), o una parentesi fuori posto ecc...
Non noto tutti questi problemi; si vede che sono un bambino speciale.  :oops:

[TheKaneB]

• 

ma che incubo :-)
Io il C++ lo conosco molto bene quindi OVVIAMENTE so quanto sia cesso

Ho scritto centinaia di migliaia di righe di codice in C e C++, e tutto ciò solo perchè non c'era altra alternativa (e se dovessi ricominciare a scrivere videogiochi di alto livello dovrei ritornare a questi linguaggi, per forza di cose).
Per hobby invece ho studiato ed apprezzo tantissimo il Delphi, che è un linguaggio (si è anche il nome del linguaggio, da non confondersi con l'Objective-Pascal) meraviglioso :-)
Mi sono guadagnato il pane anche con PHP per un certo periodo di tempo e, ripensando al C ed al C++, ho capito che al peggio non c'è mai fine  :lol: con il C++ piango con un occhio solo almeno  :lol:

Attualmente invece ho approfondito il Java, perchè sviluppo su Android, e devo dire che mi piace così e così... Avrei aggiunto alcune caratteristiche come gli iteratori stile C++ (quelli stile Java mi fanno pena al cubo), e la possibilità di gestire la memoria manualmente con il "delete". Moltissimi programmatori Java sono erroneamente convinti che il Garbage Collector ti salvi il culo dai memory leaks.
In realtà, con strutture complesse e intricate, capita molto spesso che alcuni oggetti si portino dietro un grafo di dipendenze con vari reference ad oggetti non più utili.
Se non metti a "null" TUTTI i reference di un oggetto, questo rimarrà in memoria ovviamente. Con un bel "delete" esplicito invece risolverei molti problemi di memoria in modo molto più semplice. Potrei anche aumentare le performances dei programmi. Ad esempio su Android odio quando una lista rallenta durante lo scrolling e, guardacaso, nella debug console spunta un messaggio del GC che ha liberato X byte su Y oggetti deallocati... devo decidere IO se e soprattutto "quando" puoi liberare la memoria, punto!

Poi ci sono altre caratteristiche del java che invece apprezzo, come il meccanismo delle interfacce che risolve in maniera pulita l'inferno dell'ereditarietà multipla del C++ (infatti in C++ usavo la convenzione Java, cioè una sola classe padre + N classi virtuali pure a mo' di interfacce).
Devo studiare meglio la reflection in Java, che è interessante anche se la ritengo una pratica di programmazione pericolosa al pari dei casting selvaggi.

[cdimauro]

• 

ma che incubo :-)
Io il C++ lo conosco molto bene quindi OVVIAMENTE so quanto sia cesso

Sante parole. :clap:

Per hobby invece ho studiato ed apprezzo tantissimo il Delphi, che è un linguaggio (si è anche il nome del linguaggio, da non confondersi con l'Objective-Pascal) meraviglioso :-)

:shock: Da pascaliano di lunghissima data, ho lavorato per parecchi anni con Delphi, che ADORO.

Dopo Python è il mio linguaggio preferito. 8-)

Attualmente invece ho approfondito il Java, perchè sviluppo su Android, e devo dire che mi piace così e così...

Troppo verboso. Anche perché gli mancano tutta una serie di agevolazioni. Passando da C# 3 (con Windows Phone 7) a Java, per me è stato un trauma.

Avrei aggiunto alcune caratteristiche come gli iteratori stile C++ (quelli stile Java mi fanno pena al cubo),

Ovviamente preferisco quelli stile Python:

Codice: [Seleziona]

for Item in List:
  print Itemma in mancanza meglio quelli di C#

Codice: [Seleziona]

foreach(var Item in List)
  Console.WriteLine(Item);

e la possibilità di gestire la memoria manualmente con il "delete". Moltissimi programmatori Java sono erroneamente convinti che il Garbage Collector ti salvi il culo dai memory leaks.
In realtà, con strutture complesse e intricate, capita molto spesso che alcuni oggetti si portino dietro un grafo di dipendenze con vari reference ad oggetti non più utili.
Se non metti a "null" TUTTI i reference di un oggetto, questo rimarrà in memoria ovviamente. Con un bel "delete" esplicito invece risolverei molti problemi di memoria in modo molto più semplice. Potrei anche aumentare le performances dei programmi. Ad esempio su Android odio quando una lista rallenta durante lo scrolling e, guardacaso, nella debug console spunta un messaggio del GC che ha liberato X byte su Y oggetti deallocati... devo decidere IO se e soprattutto "quando" puoi liberare la memoria, punto!

Codice: [Seleziona]

import gc
gc.disable()
# Do whatever you want
gc.collect()
# Do whatever you want
gc.enable()8-)

Poi ci sono altre caratteristiche del java che invece apprezzo, come il meccanismo delle interfacce che risolve in maniera pulita l'inferno dell'ereditarietà multipla del C++

Python usa questo per risolvere il problema dell'uso di membri usando l'ereditarietà multipla.

(infatti in C++ usavo la convenzione Java, cioè una sola classe padre + N classi virtuali pure a mo' di interfacce).

In genere è il mio modello preferito, anche se qualche volta ho usato l'ereditarierà multipla in Python (per classi molto semplici, e più che altro per emulare i mixin).

Devo studiare meglio la reflection in Java, che è interessante anche se la ritengo una pratica di programmazione pericolosa al pari dei casting selvaggi.

Provenendo da Python, la trovo molto incasinata e complicata da usare. Sono abituato troppo bene con Python.

[TheKaneB]

• 

In realtà, con strutture complesse e intricate, capita molto spesso che alcuni oggetti si portino dietro un grafo di dipendenze con vari reference ad oggetti non più utili.
Se non metti a "null" TUTTI i reference di un oggetto, questo rimarrà in memoria ovviamente. Con un bel "delete" esplicito invece risolverei molti problemi di memoria in modo molto più semplice.

Qui non è colpa del GC mica può sapere se ti servono più oppure no.
Se non ci fosse il GC sarebbe pure peggio, perché deallocando la classe causi un numero tremendo di memory leak. In assenza bisogna crearsi procedure che traversano tutto l'algoritmo di dati per deallocare la memoria.
Io sono per l'accoppiata, in Ada e in alcune versioni di Oberon hai il GC e la possibilità di usare il delete/dispose per alleggerire il lavoro del GC. Anche se nei report ufficiali sconsigliano l'accoppiata, devo ancora investigare sui perché.

Ci sono delle tecniche, che conosco e ho implementato, per evitare tutti i memory leaks anche in C++.
Potrei usarle perfettamente anche in Java, se solo avessi il "delete".
In sostanza si elimina l'uso dei puntatori e si usano gli smart pointers, cioè puntatori con ref counting implementato in modo coerente tramite ridefinizione dei costruttori per copia e dell'operatore di assegnazione.
In Java (o perlomeno su Android, non so se sia Java standard) ci sono i SoftReference e i WeakReference che aiutano a spezzare i grafi di interdipendenza. In pratica il GC può decidere di cancellare un oggetto, se gli unici reference ad esso sono tutti di tipo Weak o Soft.
Il danno è che, comunque, non potendo decidere quando deallocare potrei trovarmi con softref che puntano al nulla e dovrei ricostruire tali oggetti, quindi posso farlo solo su oggetti "ricostruibili" (ad esempio per oggetti che incapsulano file XML, file immagini, ecc... cioè roba che posso ricostruire ricaricando e riparsando il relativo file).

@cdimauro:
In Android posso invocare manualmente il "collect" del GC, ma non posso disattivarlo (quindi comunque andrebbe a rompere le scatole nei posti meno opportuni).
Il foreach c'è anche in java

Codice: [Seleziona]

for(Tipo iteratore : insieme)
{

}
Però non è un iteratore vero, perchè va soltanto in avanti e non posso decidere, ad esempio, di usarlo come puntatore ad un elemento del set, ma soltanto per fare cicli semplici. Gli iteratori C++, quelli ad accesso random, invece mi permettono una maggiore comodità in alcune situazioni. Tuttavia, alla fine, stringo i denti e ne faccio a meno. Se non conoscessi il C++ probabilmente nemmeno ci avrei fatto caso.