di  -  mercoledì 25 agosto 2010

Quando parliamo di Sun e di Oracle difficilmente possiamo pensare all’eredità della prima presa in consegna dalla seconda: troppo diverse le finalità e le azioni, con l’azienda di Redwood votata a batter cassa cercando di capitalizzare il più possibile il portfolio di strumenti e proprietà intellettuali della ex casa di Santa Clara.

Una recente notizia sembra, però, accomunarle nuovamente, all’insegna di un ritorno al passato in quella che all’apparenza si prospetta come una difesa di uno dei gioielli di famiglia, il linguaggio di programmazione Java che, nel bene e nel male, tanto ha dato all’informatica e alle giovani leve.

In estrema sintesi, Oracle rivendica l’infrazione di proprietà intellettuali (brevetti e copyright) che riguardano Java da parte di Google, che per il suo Android ha realizzato una virtual machine (chiamata Dalvik) diversa da quella standard, e soprattutto che fa uso di una libreria alternativa (che fa parte di Harmony, progetto di Apache Foundation volto a realizzare una piattaforma Java open source, ma con licenza Apache appunto), già a sua volta presa di mira da Sun.

C’è da dire che Sun è stata sempre molto gelosa del suo progetto, su cui ha investito enormi risorse e che ha difeso già altre volte, dimostrando un attaccamento a dir poco viscerale, volto a fornire al mondo intero una sola, omogenea, soluzione che vi facesse capo. Da questo punto di vista possiamo affermare che la similitudine con Oracle risulta evidente, e l’eredità raccolta.

A mio avviso da qui le due strade divergono, perché troppe sono le differenze a livello di politica aziendale, come ho sottolineato all’inizio dell’articolo. Onestamente non credo nemmeno nella “difesa della patria”, ma vedo l’azione di Oracle come l’n-esimo tentativo volto a monetizzare le tante risorse made in Sun.

Ciò fermo restando che ha tutto il diritto di difendere, ed eventualmente chiedere compensi, per ciò che le appartiene. Se Google ha sbagliato (e non sarebbe nemmeno la prima volta, ormai), deve giustamente pagare, com’è toccato a Microsoft quando anche lei ha messo le mani su Java.

La situazione, infatti, è praticamente la stessa, come abbiamo già avuto modo di affrontare nei commenti di un articolo su IE9 di Raffaele Fanizzi. Anche Microsoft realizzò una virtual machine in parte diversa da quella di Sun (più aggiornata, alla versione 2 del linguaggio, mentre la MSJVM era ferma alla 1.1), in quanto mancava il supporto alle JNI, a cui la casa di Redmond aveva preferito una sua estensione chiamata J/Direct (per invocare direttamente API Win32).

Nuovamente, il vero pomo della discordia fu l’adozione di una libreria diversa da quella ufficiale. Microsoft non credeva nella Java Foundation Class, che riteneva troppo pesante, preferendo affidarsi alle consolidate (e già presenti nel sistema) Win32, facendo di Java sostanzialmente un linguaggio come tutti gli altri per la piattaforma Windows.

Si potrebbe pensare che le finalità di Microsoft e Google siano diverse. Alla prima, infatti, si potrebbe rinfacciare la classica politica di Embrace, Extend, Extinguish (EEE) con la quale ormai viene etichettata ogni sua azione. Per la seconda, che male potrebbe mai fare una virtual machine e una libreria diverse, visto che il raggio d’azione è ristretto a una porzione del mondo mobile?

In realtà non cambia poi molto: entrambe le aziende hanno personalizzato Java per le proprie esigenze, col risultato che i prodotti per essi realizzati non possono girare sulla piattaforma standard, che poi è il motivo (“write once, run everywere“) per cui Sun l’ha sempre difesa con le unghie e coi denti.

Le conseguenze di quest’arroccamento sono state che Microsoft ha abbandonato Java, realizzando .NET e C# che rappresentano, di fatto, la sua risposta e lo strumento personalizzato e al contempo flessibile che le serviva.

Google può, a questo punto, puntare sull’SDK C++ che ha rilasciato da poco per Android, e che si è affiancato all’originale Java-only, con la speranza che se ne affianchi qualcuno magari basato su Python (linguaggio di primo piano per il colosso di Mountain View) che è sicuramente più semplice e comodo da utilizzare (come abbiamo anche avuto modo di sperimentare qui su Appunti Digitali).

Con Microsoft e Google che si allontanano da Java, il futuro di questo linguaggio non sembra affatto roseo. Chiuso alle personalizzazioni che sono necessarie per far fronte alle necessità di ambiti specifici, lento nelle innovazioni (la versione 7 del linguaggio “arriverà quando sarà pronta“), e presta il fianco ai linguaggi cosiddetti “dinamici” che offrono una produttività ben più elevata.

Aggiungiamo anche il fatto che, nella ricorsa alle innovazioni, Java è finito per copiare malamente le soluzioni altrui, snaturando quello che era un linguaggio che, di fatto, nelle prime incarnazioni era semplice da leggere e facile da apprendere, caratteristiche queste che gli hanno permesso di scalzare Pascal e C nell’ambito didattico, forte anche di una ricca libreria standard.

Con queste premesse, se Oracle non troverà il modo di rilanciarlo, campando soltanto di rendita come si suol dire, le prospettive non possono che essere funeree. Ciò non vuol dire che dall’oggi al domani troveremo il suo cadavere galleggiare sul letto di un fiume, ma similmente al C rimarrà relegato sempre più in settori di nicchia, grazie alla base legacy di applicazioni (in particolare di classe enterprise) installate.

Poi, come si sa, morto un re se ne farà un altro (penso a C#, che ha tutte le carte in regola per prenderne il posto; non credo né nel C++ né tanto meno nel ben più complesso C++0x gli succederà fra qualche anno), anche se oggi assistiamo a un fiorire di nuovi linguaggi e, come dicevo prima, sempre più piede prenderanno quelli “dinamici” (con Python che raccoglie sempre più consensi; vedi Google e YouTube in particolare).

106 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    goldorak
     scrive: 

    @ Cesare di Mauro : ci sono un po’ di inesattezze nel tuo articolo.
    Primo quando citi il caso Microsoft, e dici che la situazione era analoga a quella che ce’ oggi tra Oracle e Google.
    Questo non e’ vero. Sun non ha mai impedito che aziende terze estendessero Java, quello contro cui e’ sempre stata contraria ed era specificato nel contratto di licenza nero su bianco (che Microsoft violo’ in piena regola e per questo motivo persero la causa e pagarono 1 miliardo e rotti di $ a Sun) era che le aziende andassero a modificare le librerie di base (sun.java.io e simili per intenderci)di Java. IBM per esempio ha una implementazione alternativa di Java, usa estensioni proprietarie ma non va a toccare le librerie di base. IBM usa appunto la sua versione da un buon decennio e non mi pare che Sun abbia mai fatto causa. Quindi il problema non erano le implementazioni terze, ma le implementazioni terze che andavano a modificare le librerie di sistema. Quella debacle brucio’ cosi’ tanto alla Microsoft che abbandonarono Java e crearono C# (che a livello sintattico e non solo e’ una copia spudorata di Java).Punto primo.

    Punto secondo : sulla causa di Oracle a Google. Oracle sta sparando a zero perche’ da una parte la Java Micro Edition (che e’ l’unica variante di Java che andava pagata profumatamente per poter usarla su terminali mobili) e’ obsoleta e non piu’ al passo coi tempi. La causa di Oracle si divide in due parti, il presunto copyright infringement di Google e la questione sui 6 brevetti che Dalvik non rispetterebbe. Non e’ per niente chiaro che ci sia stato copyright infringement da parte di Google (anche usando parte delle documentazione liberamente accessibile di Java). E per quello che riguarda i brevetti, beh sono molto generali (e per parecchi di loro ci sono prior art che li invalidano). Quelli che rimangono beh si possono applicare tanto a Dalvik, cosi’ come al CLR di Microsoft. Sono brevetti talmente generici che qualsiasi Virtual Machine e’ sotto attacco.

    Infine sul futuro di Java. Il fatto che Java sia open source e’ solo uno specchietto per le allodole. E solo fumo negli occhi, perche’ per non essere vulnerabili a Oracle, una implementazione di Java deve passare al 100% il Java Compatibility Toolkit. JCT che viene dato da Oracle, ma non e’ obbligata a farlo. Questo fa si che’ implementazioni alternative che possano essere competitive a livello prestazionale con l’implementazione canonica quella di Oracle non avranno mai la certificazione da parte di quest’ultima. E praticamente quello che succede con Harmony.
    In questo modo Oracle si assicura che la sua implementazione sia quella migliore. Non male per una azienda considerata open source friendly.

    Finisco infine parlando di Dalvik. Dalvik non e’ una JVM, e’ soltanto una macchina virtuale, cosi’ come ne esistono tante. Macchina virtuale non e’ sinonimo di Java Virtual Machine. Dalvik inoltre non esegue Java bytecode ma un bytecode del tutto diverso. Dire che Dalvik e’ un implementazione terza di Java e proprio non aver capito un h di cosa sia Dalvik in realta’. L’unico posto dove si usa Java e’ nel front end. Quando usi il linguaggio Java per scrivere il tuo programma. Poi pero’ viene compilato in Dalvik bytecode. E non viene usato niente della infrastruttura di Java (ne’ il runtime, ne’ le librerie). Infatti Dalvik non e’ come ho gia’ detto una implementazione di Java.
    Il linguaggio Java non e’ proprietario, quindi Oracle non puo’ fare causa solo perche’ i programmi per Dalvik vengono scritti in Java. Ecco perche’ sta cercando altre motivi per fare causa a Google.

    Finisco col dire che Google ha usato pezzi di Harmony, ma poiche’ Harmony non e’ una implementazione di Java, neanche Dalvik lo e’ (anche se usa alcune librerie di Harmony). E questo brucia moltissimo a Oracle che non ha alcun modo per monetizzare la Java Micro Edition che ormai nessuno piu’ sano di mente usa.

    Io penso che Google vincera’ per Oracle si sta arrampicando sugli specchi in questo caso. Peccato che la causa durera’ anni, ma il danno che fara’ al ecosistema di Java sara’ immenso. Proprio perche’ non potranno esistere implementazioni competive alla versione di Oracle (cito sempre il caso di Apache Harmony che e’ emblematico).

  • # 2
    Peppe
     scrive: 

    @Cesare Io sul fatto che il C sia relegato in settori di nicchia…avrei qualche cosa da dire, nel bene o nel male è + che vivo e forte in moltissimi ambiti.
    Perché ogni volta che si parla di programmazione sembra che l’unico ambito che contaè quello delle applicazioni web?
    Siamo più che circondati da milioni di apparati grandi e piccoli che funzionano grazie a del codice scritto in C o in C++ (dall’auto alla vostra nuova lavatrice, dagli apparati dove passa il traffico di rete ai sistemi di monitoraggio delle catene di produzione).

    Sai il perché di questa mia puntualizzazione? Perché poi quando c’è una ricerca di personale arrivato tutti espertissimi nel copia e incolla di CMS in Php e nella scrittura di codice Java (purtroppo spesso anche questo frutto di copia e incolla) e se poi gli domandi “sai cos’è un albero?” ti guardano male!

  • # 3
    goldorak
     scrive: 

    Meego e’ letteralmente GNU/linux su terminali mobili.
    E li’ puoi usare il linguaggio ed il/i toolkit che piu’ preferisci. Mandandoo al diavolo c#, java e dalvik e altri linguaggio dinamici interpretati che sono totalmente inefficienti (in primis Python).
    Quando Python avra’ una implementazione competitiva con quella di Java o anche del C/C++ se ne riparlera’. In caso contrario rimarra’ confinato come linguaggio di prototipizzazione. Da evitare in tutti i casi in cui prestazioni decenti siano necessari.
    Le QT sono qualcosa di estremamente avanzato, ideali anche per sviluppo su terminali mobili. E salutano da lontano Java, C# e Python. ^_^

  • # 4
    Andrea Del Bene
     scrive: 

    Pienamente d’accordo con goldorak. A mio avviso sia Oracle che Google stanno in qualche modo danneggiando la comunità Java. Oracle lo sta facendo con un maldestro tentativo di difendere qualcosa di obsoleto (la JavaME) usando presunte violazioni di brevetti Java e spaventando in questo modo chiunque voglia farsi una sua implementazione di Java.

    Google dal suo canto ha creato qualcosa di “ibrido” che usa linguaggio Java ma che non è un implementazione di Java e che quindi produce software che non è eseguibile su una JVM standard. Personalmente penso che la natura multipiattaforma di Java sia uno dei suoi punti di forza e penso che creare qualcosa che è simile a Java ma gira solo su un certo OS (sia esso Windows o Android) indebolisca l’intera comunità Java.

    Detto questo mi dispiace che Cesare nell’ultima parte dell’articolo non abbia resistito a lanciarsi nell’ennesimo requiem per Java (ennesimo riferito in generale, non solo a Cesare). Mi dispiace perchè Cesare espone delle argomentazioni un pò fumose e forse contradditorie.
    A prescindere da Java non capisco che significhi per un linguaggio essere “lento nelle innovazioni”. In che modo dovrebbe “innovarsi” un linguaggio già stabile e ampiamente diffuso? Sono lenti anche PHP, C e compagnia bella? O forse innovare significa cambiare la sintassi e/o le parole chiave ogni 2 anni come fa .NET?
    Infine Cesare non distingue affatto tra LINGUAGGIO Java e PIATTAFORMA Java (la JVM). Sulla JVM possono girare un numero arbitrario di linguaggi ed in certi ambiti la sostituzione del “vecchio” linguaggio è già in atto, si pensi alla crescente adozione di Scala o JRuby.

  • # 5
    Human_Sorrow
     scrive: 

    A quanto vedo dai commenti, chiunque abbia il dono della parola si sente in diritto di parlare di informatica a vanvera …

    Che tristezza :(

  • # 6
    homero
     scrive: 

    Java è sempre stato una dannazione per chiunque vi abbia programmato qualcosa di meramente simile ad una applicazione che non potesse girare su un vecchio sistema dos 286….
    java fa LETTERALMENTE SCHIFO!
    quando nel 97 sun introdusse l’meta-architettura basata sugli opcode tutti gridarono al miracolo…ma nella realtà questa architettura non è ne multipiattaforma tantomeno efficente…
    java ormai è stata sostituita dalle virtual machine piu’ efficenti e che non solo non richiedono la compilazione ma funzionano come e precisamente la macchina di oridine…

    oracle che basa tutta la sua architettura server side programming su java ha cucito letteralmente adosso alla virtual machine di sun il suo efficentissimo database, tanto da essere interlocutore privilegiato…chi usa oracle necessariamente usa java….

    su C sharp stendo un velo pietoso ennesima brutta copia di microsoft di un brutto linguaggio che aggiunge software layer su abstraction layer insomma l’ennesimo macello che per fare 2+2 ti spara un’applicazione di 1 mb

    si va invece contro al C++ che è l’unico linguaggio realmente multipiattaforma cross compiler e con il quale si sono costruite applicazioni eccellenti…praticamente la quasi totalità delle applicazioni che hanno un numero di righe superiore a 30.000 sono state programmate in C/C++, compresi sistemi operativi, web server, applicazioni grafiche, librerie e quant’altro…
    parlare male del C/C++ significa parlare male dell’unico linguaggio che funziona nelle nostre macchine, perfettamente canonizzato e con uno standard aperto e chi piu’ ne ha piu’ ne metta…
    stavolta CDMAURO l’hai scritta proprio grossa…quanto ti ha pagato microsoft per scrivere quello che hai scritto?!?!?!
    ma siamo impazziti o cosa!
    dio ci salvi dai cloud, dagli opcode e dagli script language remoti…

  • # 7
    AT
     scrive: 

    Sinceramente sono felice che Oracle abbia acquistato Java: 2 piccioni con una fava. Oracle distrugge quello schifo di linguaggio proprietario chiamato Java(non ha mai portato avanti la standardizzazione ecma) e che negli ultimi anni copiava solotanto le feature dagli “avversari” (e non sonoi un estimatore di C#), dando così spazio alle varie alternative aperte derivate da esso, e allo stesso tempo distrugge se stessa. L’unica cosa brutta è che anche mysql ne fa le spese…

    PS: parlare male di C e soprattutto C++ significa non capire una beata sega di programmazione. Tutte le critiche che si fanno ad essi sono puttanate visto che ogni linguaggio ha un suo contesto e una sua specializzazione e funzionalitàà gente che chiede garbage per C e C++ è gente che melgio lasci stare la tastiera e vada a raccogliere pomodori per i campi.. l’unica cosa a cui si può criticare è che vengono standardizzati solo dai iso e i relativi documenti finali sono a pagamento.. Tralasciando che appunto C e C++ con le librerie standard sono gli unici veri linguaggi multipiattaforma (i tipi primitivi possono avere dimensioni differenti? è giusto che sia così, è sacrosoanto che sia così visto che sono linguaggi volti all’ottimizzazione)..

  • # 8
    ghost011
     scrive: 

    Sinceramente, sentire ancora discussioni sul tema del “miglior linguaggio di programmazione” è un po’ sconsolante.

    Seriamente, com’è possibile affermare che quel linguaggio fa schifo e quest’altro è eccezionale? Sarebbe impossibile definire una serie di criteri di confronto, figurarsi un giudizio complessivo…

    Con questo non voglio contraddire i commenti di nessuno, ma non sarebbe più semplice lasciare che ognuno abbia le proprie preferenze e sviluppi con gli strumenti con cui si trova a suo agio?

    Personalmente, da sviluppatore ma anche (e forse specialmente) da utente finale, non è tanto importante con cosa viene realizzata un’applicazione, ma piuttosto COME. E non credo ci sia bisogno di fare esempi (ancora una volta, nessuna particolare accezione!).

  • # 9
    mjordan
     scrive: 

    Non sono d’accordo quando molti asseriscono che Java ME è “obsoleto”. Allo stato attuale lo è, ma non dimentichiamoci che le specifiche MIDP 3.0 sono state finalizzate e l’unica cosa che manca è un’implementazione funzionante del wireless toolkit che implementi tali specifiche. MIDP 3.0 ha richiesto parecchi anni per essere definito e “standardizzato” e include parecchie caratteristiche nuove interessanti (come per esempio la inter-MIDlet communication). Purtroppo quando molti articoli citavano il fatto che “Java è salvo” nelle mani di Oracle, non si faceva mai riferimento a quale edizione si stava considerando. Java EE, in mano a una società enterprise, era salvo sicuro (non richiedeva di certo dei veggenti) ma la situazione mobile è parecchio diversa. In ogni caso la specifica c’è. Dov’è l’implementazione? MIDP 3.0 non va a fare concoerrenza alle API native dei vari sistemi ma è un’ottimo layer generico per scrivere applicazioni non legate al sistema: LWUIT è interessante cosi come lo è il progetto JavaFX Mobile.

  • # 10
    Alex
     scrive: 

    Non mi addentro in dettagli tecnici
    ma leggevo come i servi delle grandi case: specie quelle che si proclamano progressisti dell’open source dove non si deve pagare il software paladini della copia libera e del nocopyright.

    Sono servi devoti che contribuiscono alle ditte miliardarie che sono con bilanci pari o quasi alla Microsoft che sempre i paladini odiano:
    Oracle, IBM, Sun, Google, Apple, e compagnia

  • # 11
    homero
     scrive: 

    non dico che un linguaggio e meglio di un’altro
    dico che JAVA fa schifo, ha sempre fatto schifo da quando è nato…
    mai vista tanta aria fritta venduta a caro prezzo…
    ovviamente microsoft invece di adottare java ne ha fatto una brutta copia chiamandola C sharp…ovviamente la brutta copia di qualcosa che già in origine fa schifo fa’ ancora piu’ schifo e questo il punto…
    un linguaggio di programmazione si misura dal software che con questo è possibile sviluppare…

    se penso il tempo che gli studenti hanno perso a studiare java all’università….mi fa rabbrividire…roba da denunciare sun e compagnia bella…

  • # 12
    Mirko
     scrive: 

    Il C# e’ una delle cose più belle che Microsoft abbia mai realizzato.
    Con il progetto Mono poi, questo linguaggio è entrato anche in Linux e altri S.O.
    Infine, con MonoTouch e MonoDroid sta arrivando anche sui sistemi mobile.
    Java… per me può anche andare a finire nel dimeticatoio

  • # 13
    blugo
     scrive: 

    che tristezza, adesso vengo su AD e mi tocca leggere che c# sarebbe una brutta copia di java?
    complimenti, che commenti di spessore!
    bah, ormai anche questo blog che prometteva bene sta andando a buttane

  • # 14
    IndovinaChi
     scrive: 

    ghost011 è l’unico che ha centrato il cuore della questione e tutti quelli che dicono che un linguaggio fa schifo e che un altro è il top sinceramente mi fanno ridere!
    Il punto è che tutto dipende da che applicazione si deve realizzare e su che terminale andrà a girare!

    Se devo scrivere un firmware di sicuro non lo faccio in Java come se devo scrivere un’applicazione web di sicuro non lo faccio in C…

  • # 15
    Giulio85
     scrive: 

    @homero: fino a prova contraria Java è uno dei linguaggi più usati attualmente, per cui non è vero che si è perso tempo a studiarlo.

    Primo perché molti concetti di Java si possono ritrovare in altri linguaggi, e secondo perché i dati ti smentiscono.

    Inoltre dire che fa schifo… su quali basi? Argomenta almeno.

    Sintassi? Prestazioni?

    Inoltre C# sarebbe una brutta copia di Java? Da Java riprende solo essere il suo linguaggio C-like, anzi è più C-Like C# che Java (forse è voluto).

    Inoltre ci sono tutta una serie di funzionalità comodissime in C#, che in Java non ci sono, ad esempio LINQ e i metodi delegati tanto per citare le prime due cose che mi vengono in mente, l’inferenza dei tipi e l’overload degli operatori che Java non ha e l’ottima integrazione con il sottosistema Windows, oltre a svariati costrutti sintattici che possono risultare comodi, le partial classes e il fatto che si possa estendere di fatto le classi fornite con esso aggiungendo metodi, cosa tipica dei linguaggi dinamici.

    Queste sono tutte cose che Java non ha.

    Senza contare il plus offerto da Visual Studio.

  • # 16
    lalla521
     scrive: 

    ma se java morisse sarebbe anche meglio per il mondo dell’informatica eh.

    che poi il famoso “write once, run everywhere” e’ solo uno slogan e niente piu’, certo a meno non ci si accontenti del solito hello world…

  • # 17
    Andrea Del Bene
     scrive: 

    Anch’io non riesco a capire il tono da “guerra santa” di certi commenti. Bisognerebbe cercare di argomentare le proprie posizioni, evitando magari frasi del tipo “il linguaggio X fa schifo, ha sempre fatto schifo da quando è nato…”, frasi che francamente non sono riconducibili ad una persona adulta.
    Io all’università ho avuto la fortuna di studiare c, c++ e Java.

    Li ritengo tutti e tre molto interessanti e utili per dare una panoramica dei modelli computazionali che stanno dietro ai linguaggi odierni. Poi ognuno è libero di scegliere lo strumento che meglio crede come ha giustamente detto IndovinaChi.

  • # 18
    Giulio85
     scrive: 

    @lalla: davvero? E per quale motivo? Argomentare please…

    Programmi che si appoggiano alla libreria di Java, usando le classi opportune in alcuni contesti (ad esempio per stabilire il carattere di fine linea) perché mai dovrebbero dare problemi su altri sistemi?

    Certo se ti appoggi a feature specifiche di un dato SO è chiaro che la portabilità va a farsi benedire.

    Tanto per la cronaca è possibile scrivere codice portabile anche in C/C++, chiaramente è più facile farlo in Java.

  • # 19
    Cesare Di Mauro (Autore del post)
     scrive: 

    @goldorak: una precisazione su questo

    Finisco infine parlando di Dalvik. Dalvik non e’ una JVM, e’ soltanto una macchina virtuale, cosi’ come ne esistono tante. Macchina virtuale non e’ sinonimo di Java Virtual Machine. Dalvik inoltre non esegue Java bytecode ma un bytecode del tutto diverso. Dire che Dalvik e’ un implementazione terza di Java e proprio non aver capito un h di cosa sia Dalvik in realta’. L’unico posto dove si usa Java e’ nel front end. Quando usi il linguaggio Java per scrivere il tuo programma. Poi pero’ viene compilato in Dalvik bytecode. E non viene usato niente della infrastruttura di Java (ne’ il runtime, ne’ le librerie). Infatti Dalvik non e’ come ho gia’ detto una implementazione di Java.

    nell’articolo l’avevo scritto chiaramente: “Google, che per il suo Android ha realizzato una virtual machine (chiamata Dalvik) diversa da quella standard”

    “Una virtual machine” non significa JVM, appunto, per quanto sia inutile ormai parlare di virtual machine specifiche per un certo linguaggio, visto che sulla Java Virtual Machine girano altri linguaggi.

    Per il resto, e come dicevo sempre nell’articolo, la situazione la trovo analoga a quella di Microsoft. Primo perché Google e Microsoft hanno realizzato una loro VM. Secondo perché non hanno utilizzato la libreria standard. D’altra parte quando tu affermi questo:

    perche’ per non essere vulnerabili a Oracle, una implementazione di Java deve passare al 100% il Java Compatibility Toolkit. JCT che viene dato da Oracle, ma non e’ obbligata a farlo. Questo fa si che’ implementazioni alternative che possano essere competitive a livello prestazionale con l’implementazione canonica quella di Oracle non avranno mai la certificazione da parte di quest’ultima. E praticamente quello che succede con Harmony.

    e questo:

    Finisco col dire che Google ha usato pezzi di Harmony, ma poiche’ Harmony non e’ una implementazione di Java, neanche Dalvik lo e’ (anche se usa alcune librerie di Harmony).

    Non fai che confermare la similitudine anche per la libreria…

    @Peppe:

    @Cesare Io sul fatto che il C sia relegato in settori di nicchia…avrei qualche cosa da dire, nel bene o nel male è + che vivo e forte in moltissimi ambiti.

    Mai negato questo. Nel settore embedded C è molto usato, ma è un settore di nicchia appunto.

    Perché ogni volta che si parla di programmazione sembra che l’unico ambito che contaè quello delle applicazioni web?

    Io non sviluppo applicazioni web (ne ho realizzate poche rispetto alla totalità di quelle che ho sviluppato a lavoro) eppure… non uso né C né C++ (a parte un moduletto di 71 righe di codice) né Java.

    Siamo più che circondati da milioni di apparati grandi e piccoli che funzionano grazie a del codice scritto in C o in C++ (dall’auto alla vostra nuova lavatrice, dagli apparati dove passa il traffico di rete ai sistemi di monitoraggio delle catene di produzione).

    Parli sempre del settore embedded.

    Sai il perché di questa mia puntualizzazione? Perché poi quando c’è una ricerca di personale arrivato tutti espertissimi nel copia e incolla di CMS in Php e nella scrittura di codice Java (purtroppo spesso anche questo frutto di copia e incolla) e se poi gli domandi “sai cos’è un albero?” ti guardano male!

    Dipende sempre da quello che devi fare. Ad esempio, da quando lavoro in Python raramente ho avuto bisogno di implementare degli alberi.

    @goldorak:

    Meego e’ letteralmente GNU/linux su terminali mobili.
    E li’ puoi usare il linguaggio ed il/i toolkit che piu’ preferisci. Mandandoo al diavolo c#, java e dalvik e altri linguaggio dinamici interpretati che sono totalmente inefficienti (in primis Python).

    Ti farà piacere sapere che Nokia introdurrà Python nella versione finale di Meego. L’ha confermato uno sviluppatore che ha presentato le Qt alla scorsa PyCon.

    Quando Python avra’ una implementazione competitiva con quella di Java o anche del C/C++ se ne riparlera’.

    Questo non succederà mai, per com’è fatto il linguaggio. E nonostante tutto Python sarà sempre più utilizzato.

    In caso contrario rimarra’ confinato come linguaggio di prototipizzazione. Da evitare in tutti i casi in cui prestazioni decenti siano necessari.

    Le prestazioni non sono tutto. Inoltre non è affatto vero che Python rimarrà relegato al ruoto di prototipazione.

    Tant’è che YouTube è realizzato quasi interamente in Python, tanto per citare l’esempio più noto. E non venirmi a dire che le prestazioni non sono importanti per YouTube; si vede che quelle ottenute con questo linguaggio sono più che sufficienti per lo scopo che s’è prefissa questa rinomata azienda.

    Idem per Google, dove il motto è “Python were we can, C++ were we must”, che è piuttosto eloquente.

    Le QT sono qualcosa di estremamente avanzato, ideali anche per sviluppo su terminali mobili. E salutano da lontano Java, C# e Python. ^_^

    Le QT sono utilizzabili anche da Python; dovresti aver già sentito parlare delle PyQT.

    Ma non solo. Nokia è talmente convinta della bontà di questo linguaggio che negli ultimi modelli della serie S60 è già disponibile (non dev’essere installato a parte, come succedeva prima). Inoltre ha realizzato un binding alternativo per le QT (di cui adesso non ricordo il nome; è stato presentato sempre all’ultima PyCon), che al momento è compatibile con PyQT, ma che dovrebbe essere più flessibile e comodo.

    Questo per dire che le tue affermazioni su Python lasciano il tempo che trovano. Evidentemente non lavorando con questo linguaggio non sei a conoscenza di ciò che ci gira attorno.

    Detto ciò non ho nulla contro C++, Java et similia. Penso che ogni linguaggio abbia dei naturali ambiti applicativi.

    Poi è anche una questione di gusti, sia chiaro.

    @Andrea Del Bene:

    Detto questo mi dispiace che Cesare nell’ultima parte dell’articolo non abbia resistito a lanciarsi nell’ennesimo requiem per Java (ennesimo riferito in generale, non solo a Cesare).

    Che Java sia in calo come linguaggio non è certo una mia impressione.

    Mi dispiace perchè Cesare espone delle argomentazioni un pò fumose e forse contradditorie.

    Spiegati meglio, perché non è chiaro.

    A prescindere da Java non capisco che significhi per un linguaggio essere “lento nelle innovazioni”. In che modo dovrebbe “innovarsi” un linguaggio già stabile e ampiamente diffuso?

    Integrando funzionalità comode per il lavoro di tutti i giorni.

    D’altra parte ti faccio notare che la prima versione di Java non è certo la stessa della sesta: è stata aggiunta un po’ di roba. Alla faccia della “stabilità”.

    Sono lenti anche PHP, C e compagnia bella?

    Per il C è sicuramente vero. Per PHP meno, visto che dalla 4 alla 5 le innovazioni sono state notevoli (sebbene come linguaggio continui a non piacermi).

    O forse innovare significa cambiare la sintassi e/o le parole chiave ogni 2 anni come fa .NET?

    .NET non è un linguaggio.

    Forse ti riferivi a C#, ma non ha cambiato sintassi dalla 1.0 alla 4.0: semplicemente è stato esteso.

    Infine Cesare non distingue affatto tra LINGUAGGIO Java e PIATTAFORMA Java (la JVM).

    Scusami, ma questo da dove l’hai dedotto?

    Sulla JVM possono girare un numero arbitrario di linguaggi ed in certi ambiti la sostituzione del “vecchio” linguaggio è già in atto, si pensi alla crescente adozione di Scala o JRuby.

    Ma qui non parliamo più Java, quanto di altri linguaggi appunto.

    @homero:

    Java è sempre stato una dannazione per chiunque vi abbia programmato qualcosa di meramente simile ad una applicazione che non potesse girare su un vecchio sistema dos 286….
    java fa LETTERALMENTE SCHIFO!

    Sui gusti non si discute. A me Java non piace, ma da qui a parlare di “dannazione”… Allora per il C cosa dovremmo dire? Dovremmo coniare nuovi vocabili…

    quando nel 97 sun introdusse l’meta-architettura basata sugli opcode tutti gridarono al miracolo…

    Mah. Una VM basata su bytecode non è certo una novità. Il P-Code è stato usato per alcune implementazioni Pascal, come l’UCSD Pascal, che risalgono agli anni ’80…

    ma nella realtà questa architettura non è ne multipiattaforma tantomeno efficente…

    Che non sia multipiattaforma è un’assurdità. In base a cosa lo affermi?

    Quanto all’efficienza, Java è paragonabile al C. E scusa se è poco…

    java ormai è stata sostituita dalle virtual machine piu’ efficenti e che non solo non richiedono la compilazione ma funzionano come e precisamente la macchina di oridine…

    Questa non l’ho capita.

    su C sharp stendo un velo pietoso ennesima brutta copia di microsoft di un brutto linguaggio che aggiunge software layer su abstraction layer insomma l’ennesimo macello che per fare 2+2 ti spara un’applicazione di 1 mb

    Questa è la classica leggende metropolitana.

    Inoltre puoi benissimo compilare un programma C# in codice eseguibile nativo della piattaforma.

    si va invece contro al C++ che è l’unico linguaggio realmente multipiattaforma cross compiler

    Questo è del tutto falso. C e C++ non sono linguaggi multipiattaforma.

    Se vuoi realizzare applicazioni multipiattaforma che vanno oltre un banale hello, world, devi cominciare a far uso estensivo di #DEFINE e #IFDEF.

    Si vede che non hai mai lavorato con progetti realmente multipiattaforma scritti in C o C++, perché son cose arcinote.

    e con il quale si sono costruite applicazioni eccellenti…

    Mai negato questo. Applicazioni “eccellenti” (qualunque cosa tu voglia dire con questo termine) possono esistere per qualunque linguaggio.

    praticamente la quasi totalità delle applicazioni che hanno un numero di righe superiore a 30.000 sono state programmate in C/C++, compresi sistemi operativi, web server, applicazioni grafiche, librerie e quant’altro…

    Senza dati ufficiali i tuoi sono numeri che non sono buoni nemmeno per giocare al lotto.

    Giusto per essere chiari, il codice JavaScript di GMail ammonta all’incirca a 300mila righe di codice (se non ricordo male).

    parlare male del C/C++ significa parlare male dell’unico linguaggio che funziona nelle nostre macchine,

    Prima di tutto non parlo male di C/C++: semplicemente sono linguaggi che NON mi piacciono. Un po’ come a te fa schifo Java, e io non ho nulla da dirti, dovresti capire che ad altri programmatori questi due linguaggi possono fare altrettanto schifo e tu, non foss’altro per coerenza, dovresti rispettare i loro gusti.

    Inoltre anche gli altri linguaggi “funzionano nelle nostre macchine”. Potresti farmi un esempio di linguaggi per cui quello che hai scritto non si verifichi?

    perfettamente canonizzato e con uno standard aperto e chi piu’ ne ha piu’ ne metta…

    C e C++ non sono gli unici linguaggi standard. Dovresti informarti meglio…

    stavolta CDMAURO l’hai scritta proprio grossa…quanto ti ha pagato microsoft per scrivere quello che hai scritto?!?!?!
    ma siamo impazziti o cosa!

    Vorrei saperlo anch’io, perché quello che hai scritto non sta né in cielo né in terra.

    E’ evidente dal mio articolo che a me piace Python, linguaggio che è sicuramente MOLTO più vicino a Google che a Microsoft, per cui la presunta marchetta a Microsoft non so da dove l’hai tirata fuori.

    Fermo restando che parlare di articolo prezzolato oltre che offensivo è confuigurabile come diffamazione a mezzo stampa.

    dio ci salvi dai cloud, dagli opcode e dagli script language remoti…

    Tranquillo: ci siamo già in mezzo. E direi che è il caso di farsene una ragione.

    Anche perché, da quel che hai scritto, a me sembra che tu viva in un mondo tutto tuo.

    non dico che un linguaggio e meglio di un’altro
    dico che JAVA fa schifo, ha sempre fatto schifo da quando è nato…
    mai vista tanta aria fritta venduta a caro prezzo…

    Questa è una tua personalissima opinione, che di tecnico non ha proprio nulla.

    Ma se è una questione di gusti, beh, non ho nulla da rimproverarti.

    ovviamente microsoft invece di adottare java ne ha fatto una brutta copia chiamandola C sharp…

    Come ho scritto nell’articolo, Microsoft ha provato a utilizzare Java su e per Windows, ma Sun non ha permesso versioni diverse da quella “canonica” di questa piattaforma, per cui ha dovuto abbandonarla a realizzarne una sua.

    ovviamente la brutta copia di qualcosa che già in origine fa schifo fa’ ancora piu’ schifo e questo il punto…

    Opinabilissimo. Poi personalmente C# e .NET li trovo superiori alla piattaforma Java, anche se C# come linguaggio non mi piace.

    un linguaggio di programmazione si misura dal software che con questo è possibile sviluppare…

    Questa è l’unica cosa sensata che hai scritto e che condivido.

    Dovresti rifletterci sopra.

    se penso il tempo che gli studenti hanno perso a studiare java all’università….mi fa rabbrividire…roba da denunciare sun e compagnia bella…

    Per caso rimpiangi i tempi del C? Io proprio no.

    Grazie a Java gli studenti hanno avuto una formazione come programmatori sicuramente migliore.

    C ha fatto soltanto danni, dal punto di vista didattico (e non). Non dovrebbe mai essere usato come linguaggio per imparare a programmare.

  • # 20
    Andrea R
     scrive: 

    Ma “proprietà intellettuale” è una espressione che merita di essere importata o è meglio lasciarla agli americani?
    Nel nostro ordinamento non vuole dire nulla, anche se suona bene.

  • # 21
    The Solutor
     scrive: 

    @ cesare

    Fermo restando che non amo le aziende che parassitano l’open source per farci soldi, le faccende Sun V.S. Microsoft e quella Oracle V.S. Google non potrebbero essere più distanti.

    In un caso abbiamo M.S. che ha palesemente violato degli accordi precisi presi con SUN allo scopo di minare alla base quella che è (o almeno dovrebbe essere) la principale virtù di Java, ovvero l’interoperabilità.

    Nel secondo abbiamo i fenomeni di oracle che sperano di monetizzare il successo altrui senza avervi collaborato minimamente.

    Dalvick non è compatibile java (e anche se lo fosse…) è stata scritta da zero, per fare girare sw che java non è.

    Se proprio vuoi trovarci similitudini è il caso che guardi a SCO, il caso è tecnicamente differente, ma la moralità del gesto è più o meno la stessa.

  • # 22
    Andrea Del Bene
     scrive: 

    @Cesare Di Mauro
    Trovo le tue argomentazioni contradittorie perchè da un lato affermi che Java è “lento nelle innovazioni” e dall’altro dici che “la prima versione di Java non è certo la stessa della sesta: “.
    A me sembra che a livello di linguaggio Java non sia cambiato così tanto rispetto alle prime versioni, tantè che la stragrande maggioranza delle linee di codice scritte in un programma Java fa uso solo di quel nucleo sintattico originale.
    Il fatto che non sia cambiato molto a me non dispiace perchè ha permesso di mantenere “pulito” il suo modello ad oggetti. Vedremo se ciò cambiera con la 7 , dove sembra vogliano introdurre le Closure.

    PS: la versione 5 PHP è stata pubblicata nel 2004, quindi anche lì le cose non evolvono tanto rapidamente.

  • # 23
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Andrea R: la proprietà intellettuale esiste anche nel nostro ordinamento giuridico.

    @The Solutor: come puoi leggere nell’articolo, le similitudini di cui parlo si riferiscono alla realizzazione di VM e libreria standard diverse dall’originale. Inoltre le finalità sono le stesse: personalizzare la piattaforma Java per le proprie esigenze.

    Comunque il linguaggio utilizzato per Android è Java. Non importa che la VM sia diversa: il codice è scritto in quel linguaggio.

    @Andrea Del Bene: hai parlato di “contraddizioni” PRIMA che io parlassi della prima e della sesta versione di Java, per cui aspetto ancora le tue motivazioni sulle mie “argomentazioni un pò fumose e forse contradditorie” (cit.).

    Inoltre il fatto che Java sia arrivato alla sesta versione non vuol dire che non sia lento nell’innovazione, come appunto dicevo prima.

    E no, Java dalle prime versioni alle ultime è cambiato, decisamente. Già soltanto i generic ti fanno cambiare nettamente il modo di scrivere il codice, tanto per citare il caso più concreto.

    Infine su PHP 5, dal 2004 a oggi non è rimasto fermo, ma sono state aggiunte altre funzionalità al linguaggio. Fra PHP 4 e 5 chiaramente sono state introdotte delle notevoli e diverse caratteristiche al linguaggio, ma le innovazioni non arrivano soltanto con le major version.

  • # 24
    Andrea Del Bene
     scrive: 

    @Cesare Di Mauro
    Ho solo citato un tuo commento in linea con quello che avevi appena scritto nell’articolo, ossia \nella ricorsa alle innovazioni, Java è finito per copiare malamente le soluzioni altrui, snaturando quello che era…\
    Quindi non si capisce se il linguaggio si sia evoluto poco, o se si sia evoluto talmente tanto da snaturarsi.

    Infine non sono convinto che la versione attuale di Java sia così diversa dalla versione pre 5.0. Sicuramente i generics e compagnia bella hanno reso il codice più coinciso e spesso più leggibile, ma si tratta quasi sempre di “zucchero sintattico” e niente più.

  • # 25
    goldorak
     scrive: 

    @ Cesare di Mauro ha scritto : “Comunque il linguaggio utilizzato per Android è Java. Non importa che la VM sia diversa: il codice è scritto in quel linguaggio.”

    Ed io ti ho risposto che Oracle non puo’ fare causa a Google solo perche’ le applicazioni sono scritte in linguaggio Java. La sintassi di un linguaggio formale non e’ coperto da copyright o brevetti.
    Per intenderci, Oracle avrebbe fatto lo stesso causa a Google se le applicazioni venissero scritte in Python, o C o C# o nel linguaggio del mese.
    Quindi cerca di focalizzare il problema. Il problema di Oracle e’ che il sistema (macchina virtuale + librerie+ runtime) che Google usa in Android fa concorrenza alla Java Micro Edition. E questo Oracle non lo puo’ permettere. E cosi’ semplice. Tutto il resto e’ soltanto fumo negli occhi.

  • # 26
    The Solutor
     scrive: 

    @The Solutor: come puoi leggere nell’articolo, le similitudini di cui parlo si riferiscono alla realizzazione di VM e libreria standard diverse dall’originale. Inoltre le finalità sono le stesse: personalizzare la piattaforma Java per le proprie esigenze.

    Facendo un parallelo automobilistico la JVM di STA sta alla VM di microsoft come la FIAT 127 stava alla SEAT 127, c’erano degli accordi commerciali dietro (che per inciso furono disattesi anche li, tanto che SEAT dovette acmbiare il nome all’auto), si trattava di due auto sostanzialmente identiche.

    Invece dalvik sta a java come la tipo sta alla golf, con la differenza che VW non si sogna di far causa alla FIAT solo perche la tipo, come la golf è lunga e larga uguale, porta 5 persone, ed è una 2 volumi.

    Sono due auto simili per target di mercato e stop.

    Comunque il linguaggio utilizzato per Android è Java. Non importa che la VM sia diversa: il codice è scritto in quel linguaggio.

    Ecco, ci manca solo che ci mettiamo a brevettare anche l’inglese e le espressioni matematiche usate nei linguaggi di programmazione e la follia galoppante che regna di questi tempi potrà dirsi completa…

  • # 27
    homero
     scrive: 

    ok il mio tono da guerra santa è stato un po’ eccessivo…ma JAVA merita questo ed altro…
    adesso non ho tempo ne voglia di riprendere la campagna di marketing che dal 1997 la sun introdusse con il suo linguaggio che nel 2000 voleva addirittura estendere a livello di sistema operativo un po’ come quello che oggi si fa con le virtual machine doveva essere fatto con le java application ossia, l’utente doveva disinteressarsi dell’hardware su cui girava il software ma basarsi soltanto sulla compatibilità con la java virtual machine che doveva sostituire l’OS…le prestazioni abominevoli hanno impedito che questo avvenisse…ricordate sui processori sotto il ghz le prestazioni di java?
    ricordate quando netscape provo’ a sviluppare applicazioni e browser in java?
    o addirittura una specie di office?
    bene java ha fallito miseramente perchè neppure un foglio di calcolo elementare poteva essere sviluppato in java senza rallentamenti epocali…
    o vi dimenticate l’applicazioni di foglio di calcolo sviluppata da yahoo?
    oggi che abbiamo computer dual core da 2 ghz e 4 gb di ram java lo utiliziamo soltanto per far girare il programma dell’agenzia delle entrate che potrebbe tranquillamente funzionare su un vecchio 286 se fosse scritto in un linguaggio decente…oggi invece ha bisogno di un sistema compatibile di una java machine aggiornata e quant’altro…
    questo per scrivere 4 dati in croce….
    questo lo chiamate linguaggio di programmazione? ma voi avete mai programmato qualcosa che funziona? tutte le volte che ho cominciato lo sviluppo di una applicazione java mi sono travato con i seguenti problemi
    1. prestazioni degne di un bradipo in vacanza
    2. occupazione di memoria ram
    3. integrazione con il sistema che ospitava la virtual machine.
    e questa cosa è stata sistematica per qualunque tipo di applicazione mediamente complessa…
    non sai mai che cavolo stia in realtà facendo il tuo sistema non sai perchè occupa tanta memoria per un array di pochi dati…non sai perchè va cosi’ lento ne’ perchè con la nuova versione della virtual machine si rifiuta di avviarsi o viceversa con la nuova funziona bene e con la vecchia non va, a questo si aggiunge il fatto che passare il software da un sistema ad un altro è un terno all’otto ed al 90% delle volte non funziona e non funzionerà mai…..neppure se ti metti a piangere turco…
    chi parla delle classi e del linguaggio ad oggetti è totalmente fuori dalla teoria della programmazione, il liguaggio ad oggetti è nato per sviluppare software di decine di migliaia di righe di codice, con java se sviluppi un software con piu’ di 10.000 righe di codice sei praticamente sicuro che questo software non funzionerà, perchè avrà problemi di gestione della memoria, gestione delle prestazioni, non parliamo poi se bisogna accedere ad altre risorse come il desktop o il file system…
    questo è un dato di fatto incontrovertibile…
    allora le classi in java sono un esercizio di stile e dire agli studenti di utilizzare le classi anche per scrivere un hello world! vuol dire non conoscere la storia della programmazione e come questa si sia sviluppata…
    a coloro che odiano il C dico soltanto che il 90% delle applicazioni che utiliziamo ogni giorno sono sviluppate o hanno parte di codice sviluppata in questo linguaggio, imparare il C è quanto di piu’ importante sia per un programmatore che voglia sviluppare codice di decine di migliaia di righe di codice senza temere di trovarsi a mal partito…
    python, perl, ruby, e chi piu’ ne ha piu’ ne metta sono tutti alla pari per quanto mi riguarda ossia quello che si puo’ fare con uno di questi si puo’ fare con gli altri senza grosse pretese ne’ in termini di prestazioni ne’ in termini di complessità certamente sono piu’ portabili di java….

    per quanto riguarda microsoft resta il velo pietoso sui suoi prodotti, in particolari C sharp che è un linguaggio con sintassi simile al C ma senza i puntatori con la programmazione ad oggetti ma senza ereditarietà multipla sostituita dalle interfacce, il tutto compilato in un meta-codice-oggetto che viene poi reinterpretato dal framework .NET…vi rendete conto di che minestrone abbiamo di fronte? io ho utilizzato ed in parte utilizzo ancora visual studio della microsoft dalla lontana versione 6…
    sapete quanti hanno programmato di J++ presente in questa versione?
    e tutti quei poveri sventurati che hanno programmato in visual basic di gran moda alla fine degli anni 90?
    allora la microsoft non mi frega piu’ con il suo marketing….
    C sharp è il peggio del peggio a priori e senza appello….
    ossia ha la sintassi del C e la lentezza ed i limiti di una applicazione .NET che poi è una specia di virtual machine targata microsoft…
    i puntatori in C sono l’unica cosa che ancora ci lega all’hardware che vi ricordo è quello che fa girare e risolve le nostre applicazioni…
    pertanto sapere quanta ram effettivamente vogliamo consumare e sapere quanti cicli di processore occupa il nostro algoritmo è una libertà che ci vuol venir tolta dall’astrazione…
    programmazione non significa astrazione… programmazione significa sfruttare l’hardware che abbiamo a disposizione…che è quello che di fatto esegue il nostro programma..solo cosi’ è possibile gestire applicazioni enormi migliaia di righe di codice senza impazzire per comprendere cosa la nostra macchina di calcolo sta facendo ma questo nella vostra testa non sembra poter entrare…vi perdete nell’ereditarietà delle funzioni o l’overload degli operatori…e in sistemi virtuali che si frappogono tra voi e l’hardware…

  • # 28
    goldorak
     scrive: 

    @ Homero ha scritto :

    “programmazione non significa astrazione… programmazione significa sfruttare l’hardware che abbiamo a disposizione…che è quello che di fatto esegue il nostro programma..solo cosi’ è possibile gestire applicazioni enormi migliaia di righe di codice senza impazzire per comprendere cosa la nostra macchina di calcolo sta facendo ma questo nella vostra testa non sembra poter entrare…vi perdete nell’ereditarietà delle funzioni o l’overload degli operatori…e in sistemi virtuali che si frappogono tra voi e l’hardware…”

    Scusa Homero, ma questa tua valutazione e’ totalmente sbagliata. Con il tuo modo di concepire le cose oggi dovremo programmare a livello circuitale perche’ cosi’ abbiamo il contatto diretto con la macchina fisica. La programmazione (e l’uso di uno specifico linguaggio di programmazione) e’ l’ultimo passo di un processo mentale che ci porta a concettualizzare/astrarre sistemi complessi affinche’ siano trattabili da un computer. In questo senso il C non e’ ne’ meglio ne’ peggio dei linguaggio assembler, o del Cobol, o di Java, o di Smalltalk, o di Objective-C o di Fortran etc…
    I linguaggi non scalano tutti nello stesso modo. Ecco perche’ e’ possibile creare programmi in assembler da qualche migliaio di righe di codice. Se vai oltre la complessita’ aumenta a dismisura ed ecco che devi usare un linguaggio che astrae dippiu’ dalla macchina fisica (e ti ritrovi con il C o linguaggi equivalenti). Anche qui non e’ che il C sia la panacea di tutti i mali, il C ha i suoi ambiti in cui predomina ma ha anche difetti che non lo rendono idoneo per sviluppare progetti di milioni di righe di codice. E quindi ecco che ce’ bisogno di linguaggi che astraggano ancora dippiu’. Sei allergico per caso ai linguaggi logici, a quelli funzionali ? A tutto quello che non sintatticamente e semanticamente C-like ? E un modo di vedere la disciplina del software engineering/programmazione alquanto ristretta la tua.

    Poi non devi confondere il linguaggio con la “sua” implementazione canonica. Il C e’ naturalmente un linguaggio compilato, ma esitono anche interpreti del C (gasp gulp !!!!). Haskell che e’ un linguaggio funzionale come il Lisp, e’ naturalmente interpretato ma esistono anche compilatori che generano codice nativo. E quello che ottieni e qualcosa che a livello prestazionale fa concorrenza al C.
    Ci sono aziende che vendono compilatori/librerie ad alte prestazioni per il Lisp !!!!

    Un linguaggio di programmazione e’ soltanto uno strumento. Occorre sapere usare lo strumento giusto per ogni situazione. Chi si focalizza su un singolo linguaggio ragiona come colui che usa un martello per risolvere ogni tipo di problema. Anche quelli per i quali ci sarebbe bisogno di un cacciavite di precisione.

  • # 29
    Gennaro Tangari
     scrive: 

    Spiace che il “fanboysmo” non sia legato solo alle classiche discussioni Mac vs. Windows vs. Linux ma anche in campi in cui si dovrebbe valutare tutto in maniera estremamente razionale.

  • # 30
    goldorak
     scrive: 

    @ Gennaro Tangari : il politically correct sta ammazzando l’arte di polemizzare. ^_^

    Meglio Inter o Juve ?
    Meglio Vi o Emacs ?
    Meglio PL/I o C ?
    Meglio La Isola dei Famosi o Il Grande Fratello ?
    Meglio Emilio Fede o Vespa ?
    Meglio Apple o Microsoft ?
    Meglio Sega o Nintendo ?
    etc, etc, etc…

    Se non vuoi polemizzare (il che non significa necessariamente inguiriare il tuo interlocutore) vai a vivere su un isola deserta. Cosi’ non avrai problemi e non ti sentirai offeso da una critica qualsiasi.

  • # 31
    Gennaro Tangari
     scrive: 

    @goldrak
    vedo che non mi sono spiegato bene: la voglia di polemizzare certo non mi manca … ma con chi ha posizioni da tenere in base a ragioni razionali non con chi dice che C# è merda a prescindere solo perché è made in Redmond (o viceversa con chi dice che PHP è merda solo perché è opensource).

  • # 32
    Peppe
     scrive: 

    @Cesare

    Una piccola precisazione, neanche io in C++ scrivo un albero un giorno si e uno no, non è che se nn li usi dipende dal fatto che scrivi codice python, mi riferivo semplicemente al fatto che forse il C non è un linguaggio adatto a chi impara a programmare, ma sono fermamente convinto che per quanto siano comodi i linguaggi dinamici, imparare a sviluppare con un linguaggio a forte tipizzazione e conoscere determinate cose (tipo i suddetti alberi) sia un must per chi fa il nostro lavoro.

    Detto questo mi sarò anche riferito all’embedded (che sarà anche una nicchia…ma bella grande), ma anche i sistemi operativi (scegline uno qualunque) e le applicazioni di sistema mi pare che siano ancora scritte in questi linguaggi in declino… definire il C di nicchia mi risulta ancora complicato, non stiamo mica parlando di Forth…

  • # 33
    Andrea R
     scrive: 

    @Cesare Di Mauro:
    No, il termine “proprietà intellettuale” da noi è usato con riferimento soprattutto ai marchi di ditte e prodotti. Non comprende il diritto d’autore.
    Questa espressione infatti è molto criticata e compare nell’ordinamento (un numero irrisorio di volte) solo accostata a “proprietà industriale”, che è il termine corretto e non è la stessa cosa che intendono gli americani.

    Se sai come è definita la proprietà, sai anche che è impossibile che ci sia una proprietà di tipo intellettuale.

    Cioè dire “proprietà intellettuale” non è parlar bene.
    E’ come parlare di “legittimo impedimento”, quando si sà che per legge nessun “impedimento” è legittimo.

  • # 34
    Marco
     scrive: 

    Parlare di “nicchia” per il C mi pare un po’ eccessivo:

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

    e per mia esperienza diretta in ambito aziendale direi che è ancora più diffuso.

  • # 35
    Jacopo
     scrive: 

    Si leggono tanti commenti denigratori su Java, ma chi ne parla così l’ha mai provato, almeno?

    Per grandi progetti (dove le perfomance contano), se non si vuole usare un linguaggio compilato le uniche alternative reali sono Java e .NET.
    Sono gli unici due framework ad avere virtual machine molto veloci (a volte la JVM può addirittura sfiorare le performance del codice nativo), i vari Python, Perl, Ruby, ecc infatti sono mooolto più lenti, basta guardare qualsiasi benchmark per rendersene conto.
    Oltre a questo, le api sono moltissime, ben organizzate e documentate in modo eccellente.
    Sfido qualcuno a trovare qualcosa che non si possa fare con Java (chiaramente escludendo tutte quelle applicazioni nell quali sia necessario dialogare direttamente con l’hardware).

    Java ad oggi è maturo, stabile e performante, non a caso è la scelta preferita in ambito enterprise.
    E da amante del software libero, spero vivamente che il progetto OpenJDK vada avanti, visto che Mono è un rischio attualmente Java è l’unico linguaggio non compilato ad alte prestazioni che il mondo del software libero ha.
    Un linguaggio non compilato permette di delegare a uno strato sottostante tutto quel lavoro sporco tipico dei linguaggi compilati: uso dei puntatori, allocazione/deallocazione della memoria, ecc…

    Se si ritiene che qualcosa sia bello, o viceversa faccia schifo, bisogna motivare e non semplicemente sparare a zero.

  • # 36
    Giulio85
     scrive: 

    @homero: sembri ignorare totalmente il fatto che sia Java che C# sfruttano un compilatore JIT, e che in alcuni contesti sia addirittura più performante di linguaggi nativi.

    Non mi ricordo dove, ma ho letto che in alcuni ambiti scientifici vorrebbero sostituire Fortran con Java.

    L’inefficienza ce l’hai se non conosci come programmare efficientemente in quei due linguaggi, poi è chiaro che in alcune situazioni essendo parzialmente interpretato può essere meno performante su alcune operazioni.

    In alcuni contesti è persino meglio far gestire la memoria al garbage collector piuttosto che al programmatore.

    Riguardo i puntatori, non sono un problema, in C# hai anche i delegati che sono sostanzialmente dei puntatori a funzione, non hai l’aritmetica, ma pazienza, i programmi si possono fare lo stesso ;).

    Ignori anche il beneficio in termini di sicurezza e facilità di debugging dei linguaggi sopra citati, cosa non di poco conto.

  • # 37
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Andrea Del Bene:

    Ho solo citato un tuo commento in linea con quello che avevi appena scritto nell’articolo, ossia \nella ricorsa alle innovazioni, Java è finito per copiare malamente le soluzioni altrui, snaturando quello che era…\
    Quindi non si capisce se il linguaggio si sia evoluto poco, o se si sia evoluto talmente tanto da snaturarsi.

    Sono due cose diverse. Si è evoluto poco rispetto a quello che hanno fatto altri linguaggi. E rispetto alle prime versioni, con le evoluzioni a cui è stato sottoposto, lo trovo snaturato.

    Infine non sono convinto che la versione attuale di Java sia così diversa dalla versione pre 5.0. Sicuramente i generics e compagnia bella hanno reso il codice più coinciso e spesso più leggibile, ma si tratta quasi sempre di “zucchero sintattico” e niente più.

    La mia opinione è diametralmente opposta: con roba come i generic il codice è diventato decisamente meno leggibile. E con la versione 7 la situazione non andrà che a peggiorare.

    Comunque e a scanso di equivoci ribadisco che si tratta di mie opinioni. D’altra parte la rubrica parla chiaro: “Pensieri da coder”. ;)

    @goldorak:

    @ Cesare di Mauro ha scritto : “Comunque il linguaggio utilizzato per Android è Java. Non importa che la VM sia diversa: il codice è scritto in quel linguaggio.”

    Ed io ti ho risposto che Oracle non puo’ fare causa a Google solo perche’ le applicazioni sono scritte in linguaggio Java. La sintassi di un linguaggio formale non e’ coperto da copyright o brevetti.
    Per intenderci, Oracle avrebbe fatto lo stesso causa a Google se le applicazioni venissero scritte in Python, o C o C# o nel linguaggio del mese.
    Quindi cerca di focalizzare il problema. Il problema di Oracle e’ che il sistema (macchina virtuale + librerie+ runtime) che Google usa in Android fa concorrenza alla Java Micro Edition. E questo Oracle non lo puo’ permettere. E cosi’ semplice. Tutto il resto e’ soltanto fumo negli occhi.

    Allora non vedo perché continuiamo a discutere: la pensiamo allo stesso modo. Io ho sempre parlato di VM e librerie in relazione alla causa di Oracle.

    Quando, invece, parlo delle ricadute su Java, lo faccio perché è chiaro che le azioni di Sun prima e Oracle poi hanno portato e portano problemi al linguaggio e alla sua diffusione.

    Spero che adesso sia chiaro.

    @The Solutor:

    Facendo un parallelo automobilistico la JVM di STA sta alla VM di microsoft come la FIAT 127 stava alla SEAT 127, c’erano degli accordi commerciali dietro (che per inciso furono disattesi anche li, tanto che SEAT dovette acmbiare il nome all’auto), si trattava di due auto sostanzialmente identiche.

    Invece dalvik sta a java come la tipo sta alla golf, con la differenza che VW non si sogna di far causa alla FIAT solo perche la tipo, come la golf è lunga e larga uguale, porta 5 persone, ed è una 2 volumi.

    Sono due auto simili per target di mercato e stop.

    Il paragone mi piace, ma cerchiamo di rimanere nell’ambito di cui ho parlato nell’articolo.

    La VM di Microsoft e quella di Google non hanno nulla a che spartire con quella di Sun prima e Oracle poi: sono state realizzate da zero e non sono compatibili con la JVM standard.

    Quanto alle librerie, Microsoft ha preferito orientarsi verso le Win32 e Google su una soluzione basata su Harmony. Anche qui siamo ben lontani da quanto offerto dalla JVM standard.

    Dal quadro emerge che Microsoft e Google hanno realizzato piattaforme Java alternative alla versione ufficiale, a misura delle loro esigenze / obiettivi.

    Mi sembra che queste affermazioni siano vere e si possa parlare di similitudine fra i due casi, come dicevo nell’articolo.

    Poi per Microsoft parli di accordi commerciali violati, e siamo d’accordo. Per Google si parla di brevetti violati, e vedremo se è vero oppure no.

    D’altra parte tu stesso nel precedente commento hai parlato di mancanza d’interoperabilità nel caso Microsoft, ma la stessa cosa si può dire anche per l’implementazione “Java” di Google.

    Ecco, ci manca solo che ci mettiamo a brevettare anche l’inglese e le espressioni matematiche usate nei linguaggi di programmazione e la follia galoppante che regna di questi tempi potrà dirsi completa…

    Cerchiamo però di contestualizzare. Tu prima hai scritto che su Dalvik non gira software Java, e io ti ho risposto che il linguaggio usato su Android è Java.

    Se tu con Java intendevi la versione di Sun, allora stai identificando IL linguaggio con UNA sua implementazione, e da programmatore non posso accettarlo.

    Giusto per essere chiari, se scrivo un’applicazione per Android io posso affermare che sto usando Java come linguaggio; non posso mica dire che il linguaggio è Android o, addirittura Dalvik!

    E’ un po’ come se scrivessi un’applicazione Python e la facessi girare su PyPy, IronPython, o sulla VM Parrot anziché sulla versione “ufficiale” (CPython): pur con delle (leggere) differenze, sempre di Python come linguaggio stiamo parlando.

    Idem se scrivo codice C che gira soltanto su Windows, o su Linux, ecc.: non identifico il linguaggio che sto usando per scrivere il mio codice, con la piattaforma su cui gira.

    @homero:

    ok il mio tono da guerra santa è stato un po’ eccessivo…ma JAVA merita questo ed altro…
    adesso non ho tempo ne voglia di riprendere la campagna di marketing che dal 1997 la sun introdusse con il suo linguaggio

    Java è più vecchio: all’università l’ho studiato nel ’96, e non si parlava di “marketing”.

    che nel 2000 voleva addirittura estendere a livello di sistema operativo un po’ come quello che oggi si fa con le virtual machine doveva essere fatto con le java application ossia, l’utente doveva disinteressarsi dell’hardware su cui girava il software ma basarsi soltanto sulla compatibilità con la java virtual machine che doveva sostituire l’OS…

    L’idea non mi sembra certo malvagia. Hai presente la situazione del Commodore Vic 20 col suo BASIC v 2.0?

    le prestazioni abominevoli hanno impedito che questo avvenisse…ricordate sui processori sotto il ghz le prestazioni di java?
    ricordate quando netscape provo’ a sviluppare applicazioni e browser in java?
    o addirittura una specie di office?
    bene java ha fallito miseramente perchè neppure un foglio di calcolo elementare poteva essere sviluppato in java senza rallentamenti epocali…
    o vi dimenticate l’applicazioni di foglio di calcolo sviluppata da yahoo?
    oggi che abbiamo computer dual core da 2 ghz e 4 gb di ram java lo utiliziamo soltanto per far girare il programma dell’agenzia delle entrate che potrebbe tranquillamente funzionare su un vecchio 286 se fosse scritto in un linguaggio decente…oggi invece ha bisogno di un sistema compatibile di una java machine aggiornata e quant’altro…
    questo per scrivere 4 dati in croce….

    Credo che tu sia rimasto fermo alla preistoria di Java, come si suol dire, visto che le prestazioni della sua VM sono ENORMEMENTE migliorate col tempo, e allineate a quelle del C.

    C’è da dire che Java consuma molta più memoria. E’ il prezzo da pagare per le prestazioni, ma già da un po’ di anni la memoria (di sistema) si misura in GB, per cui non capisco perché continui a stracciarti le vesti.

    questo lo chiamate linguaggio di programmazione?

    Direi proprio di sì, se ne conosci il significato.

    ma voi avete mai programmato qualcosa che funziona?

    UN PO’ di esperienza, anche con Java, ce l’ho, grazie. E sì, è roba che ha funzionato.

    tutte le volte che ho cominciato lo sviluppo di una applicazione java mi sono travato con i seguenti problemi
    1. prestazioni degne di un bradipo in vacanza
    2. occupazione di memoria ram
    3. integrazione con il sistema che ospitava la virtual machine.
    e questa cosa è stata sistematica per qualunque tipo di applicazione mediamente complessa…
    non sai mai che cavolo stia in realtà facendo il tuo sistema non sai perchè occupa tanta memoria per un array di pochi dati…non sai perchè va cosi’ lento ne’ perchè con la nuova versione della virtual machine si rifiuta di avviarsi o viceversa con la nuova funziona bene e con la vecchia non va, a questo si aggiunge il fatto che passare il software da un sistema ad un altro è un terno all’otto ed al 90% delle volte non funziona e non funzionerà mai…..neppure se ti metti a piangere turco…

    Per quanto mi riguarda è falso. Dipende dai singoli casi. Stai generalizzando troppo.

    chi parla delle classi e del linguaggio ad oggetti è totalmente fuori dalla teoria della programmazione, il liguaggio ad oggetti è nato per sviluppare software di decine di migliaia di righe di codice, con java se sviluppi un software con piu’ di 10.000 righe di codice sei praticamente sicuro che questo software non funzionerà, perchè avrà problemi di gestione della memoria, gestione delle prestazioni, non parliamo poi se bisogna accedere ad altre risorse come il desktop o il file system…
    questo è un dato di fatto incontrovertibile…

    E’ un dato del tutto falso, e te lo dice uno che conosce abbastanza Java, e ancora meglio la teoria che sta alla base della programmazione.

    allora le classi in java sono un esercizio di stile e dire agli studenti di utilizzare le classi anche per scrivere un hello world! vuol dire non conoscere la storia della programmazione e come questa si sia sviluppata…

    Con ciò è evidente che tu non solo non conosci Java, ma nemmeno la modellazione del software sulla base della prospettiva orientata agli oggetti.

    Potresti cortesemente dirmi come si dovrebbe realizzare un hello world con un linguaggio a oggetti? E, visto che ci siamo, con uno funzionale, e uno logico?

    Anzi, ancora meglio: potresti dirmi come si dovrebbe realizzare un hello, world?

    E questa volta cerca almeno di rispondere alle cose che ti vengono contestate.

    a coloro che odiano il C dico soltanto che il 90% delle applicazioni che utiliziamo ogni giorno sono sviluppate o hanno parte di codice sviluppata in questo linguaggio,

    Posto che il numero che tiri fuori è del tutto arbitrario, more solito, chi se ne frega?

    CPython è la versione mainstream di Python, e dal nome si capisce che è scritta in C. Con ciò, posso continuare a rimanere disgustato da quest’ultimo linguaggio, pur adorando il primo?

    O i gusti di tutti i programmatori devono necessariamente allineati?

    imparare il C è quanto di piu’ importante sia per un programmatore che voglia sviluppare codice di decine di migliaia di righe di codice senza temere di trovarsi a mal partito…

    Ma proprio no. Anzi, al contrario, più il codice è complesso, e più un linguaggio come il C non farà che diminuirne la manutenibilità, lo sviluppo, e soprattutto ti farà sbattere la testa contro bug assurdi che in altri linguaggi semplicemente non esistono o sono estremamente ridotti o poco influenti.

    Il che non significa che si debba buttare il C. Bisogna imparare a contestualizzare, come sempre. Infatti nei settori embedded e programmazione di sistema è molto diffuso.

    Ma per il lavoro che faccio io, sia il C che il C++ rappresentano un’inutile perdita di tempo e una complicazione non necessaria, oltre che frequenti mal di testa.

    python, perl, ruby, e chi piu’ ne ha piu’ ne metta sono tutti alla pari per quanto mi riguarda ossia quello che si puo’ fare con uno di questi si puo’ fare con gli altri senza grosse pretese ne’ in termini di prestazioni ne’ in termini di complessità certamente sono piu’ portabili di java….

    Per me sono portabili quanto Java. Questo avendo ben chiaro il significato di linguaggio di programmazione, ovviamente.

    per quanto riguarda microsoft resta il velo pietoso sui suoi prodotti

    Questo è puro fanatismo che di tecnico non ha nulla, e il cui valore è pari a zero.

    , in particolari C sharp che è un linguaggio con sintassi simile al C ma senza i puntatori

    E con questo abbiamo capito che non conosci nemmeno C# e parli a vanvera. Anzi, giusto per fare il bastian contrario nei confronti di quello che hai identificato nel tuo immaginario come “nemico”.

    con la programmazione ad oggetti ma senza ereditarietà multipla sostituita dalle interfacce

    E con ciò? Dove sta scritto che la OOP debba avere l’ereditarietà multipla? Lo sai che i primi linguaggi OOP avevano esclusivamente e rigorosamente l’ereditarietà singola (quindi nemmeno le interfacce)?

    Non parlavi di storia della programmazione prima? A quanto pare te ne manca una buona parte, e sarei curioso di sapere quale parte conosci, a questo punto.

    , il tutto compilato in un meta-codice-oggetto che viene poi reinterpretato dal framework .NET…

    Questo dipende dall’implementazione. Sempre che tu conosca la differenza fra linguaggio di programmazione e UNA sua implementazione.

    vi rendete conto di che minestrone abbiamo di fronte?

    Embé? Se non ti piace, non lo mangi. A me non piace C#, ma la mia è una pura e semplice questione di gusti. Non per questo, però, sparo letame arbitrariamente, soprattutto con giustificazioni che di tecnico non hanno proprio nulla.

    io ho utilizzato ed in parte utilizzo ancora visual studio della microsoft dalla lontana versione 6…

    Quindi?

    sapete quanti hanno programmato di J++ presente in questa versione?
    e tutti quei poveri sventurati che hanno programmato in visual basic di gran moda alla fine degli anni 90?

    Non vedo cosa ci sia di che stracciarsi le vesti per roba che riguarda la preistoria, come dicevo prima.

    Oggi ci sono C# e VisualBasic.NET che ha ben poco da invidiare allo stesso C#.

    allora la microsoft non mi frega piu’ con il suo marketing….

    Che vuoi che ti dica: non usare niente di suo. Nel frattempo tanti altri c’hanno fatto, ci fanno, e ci faranno soldi a palate.

    C sharp è il peggio del peggio a priori e senza appello….

    Questo è puro e cieco fanboyismo, ma l’avevamo già capito.

    ossia ha la sintassi del C

    Falso. Ma è ormai chiaro che tu parli senza sapere e solo per spalare letame. Puro trollaggio, insomma.

    e la lentezza ed i limiti di una applicazione .NET

    Lo sai che potresti realizzare un compilatore C# che produce direttamente codice binario nativo per la piattaforma su cui gira?

    Se non lo sai, prova a immaginare perché sia possibile farlo. Perché è possibilissimo, per chi conosce il significato di “linguaggio di programmazione”.

    che poi è una specia di virtual machine targata microsoft…

    Ma proprio no. .NET è molto di più. Come al solito, prima di parlare dovresti informarti.

    i puntatori in C sono l’unica cosa che ancora ci lega all’hardware

    Anche questo è del tutto falso. Basti pensare a un’applicazione che gira in modalità protetta 386+, e per la quale normalmente puntatore = OFFSET, mentre un puntatore vero e proprio è costituito dalla coppia SEGMENTO:OFFSET, col segmento che viene normalmente “nascosto” e gestito dal s.o. (tra parentesi, i segmenti continuano a esserci ancora in modalità AMD64).

    Con ciò abbiamo capito che non conosci bene nemmeno il linguaggio C e le architetture degli elaboratori.

    che vi ricordo è quello che fa girare e risolve le nostre applicazioni…

    Sì, ma bisogna capire cosa significa “hardware” e in che modo è sfruttabile da un’applicazione, scritta in qualunque linguaggio. Cosa che a te, da quel che hai scritto finora, non è affatto nota.

    pertanto sapere quanta ram effettivamente vogliamo consumare e sapere quanti cicli di processore occupa il nostro algoritmo è una libertà che ci vuol venir tolta dall’astrazione…

    Se non fa parte dei REQUISITI di un progetto, se ne può fare benissimo a meno. L’importante è che il problema venga risolto, col miglior compromesso possibile.

    programmazione non significa astrazione… programmazione significa sfruttare l’hardware che abbiamo a disposizione…che è quello che di fatto esegue il nostro programma..solo cosi’ è possibile gestire applicazioni enormi migliaia di righe di codice senza impazzire per comprendere cosa la nostra macchina di calcolo sta facendo ma questo nella vostra testa non sembra poter entrare…vi perdete nell’ereditarietà delle funzioni o l’overload degli operatori…e in sistemi virtuali che si frappogono tra voi e l’hardware…

    Su questo ti ha risposto goldorak, che ringrazio non soltanto per la precisione, ma anche per la chiarezza espositiva, e di cui ovviamente condivido ogni singola parola.

    Preciso ancora una volta che non ce l’ho aprioristicamente con linguaggi come C, C++, Java, C#, ecc. Non mi piacciono esclusivamente per una questione di GUSTI, ma se capita ci lavoro (e stringo i denti).

    Sono un professionista, non un fanboy, e se c’è da risolvere un problema che richiede necessariamente l’uso di uno di questi linguaggi, non mi tiro certo indietro.

    Nella mia lunga esperienza di programmatore ho imparato decine di linguaggi e tutti e quattro le prospettive di sviluppo.

    Come ho detto prima, ogni linguaggio ha degli ambiti di utilizzo che lo rendono “migliore” e preferibile rispetto ad altri.

    @Peppe:

    Una piccola precisazione, neanche io in C++ scrivo un albero un giorno si e uno no, non è che se nn li usi dipende dal fatto che scrivi codice python, mi riferivo semplicemente al fatto che forse il C non è un linguaggio adatto a chi impara a programmare, ma sono fermamente convinto che per quanto siano comodi i linguaggi dinamici, imparare a sviluppare con un linguaggio a forte tipizzazione e conoscere determinate cose (tipo i suddetti alberi) sia un must per chi fa il nostro lavoro.

    Indubbiamente, ma Python, ad esempio, è fortemente tipizzato pur essendo dinamico, e gli alberi li posso costruire anche con questo linguaggio. ;)

    Questo solo per precisare. Comunque capisco il tuo fine, e ti dirò: prima trovo sia meglio formarsi con un linguaggio come Python, e una volta che ci si è fatti le ossa come programmatori, passare a conoscere dettagli di più basso livello.

    Detto questo mi sarò anche riferito all’embedded (che sarà anche una nicchia…ma bella grande), ma anche i sistemi operativi (scegline uno qualunque) e le applicazioni di sistema mi pare che siano ancora scritte in questi linguaggi in declino… definire il C di nicchia mi risulta ancora complicato, non stiamo mica parlando di Forth…

    Ho scritto prima che è usato anche in ambito sistemistico, infatti. Non è certamente da paragonare al Forth, ma personalmente oltre agli ambiti elencati (o per la scrittura di porzioni critiche, quando necessario) non lo userei.

    @Andrea R:

    @Cesare Di Mauro:
    No, il termine “proprietà intellettuale” da noi è usato con riferimento soprattutto ai marchi di ditte e prodotti. Non comprende il diritto d’autore.
    Questa espressione infatti è molto criticata e compare nell’ordinamento (un numero irrisorio di volte) solo accostata a “proprietà industriale”, che è il termine corretto e non è la stessa cosa che intendono gli americani.

    Se sai come è definita la proprietà, sai anche che è impossibile che ci sia una proprietà di tipo intellettuale.

    Cioè dire “proprietà intellettuale” non è parlar bene.
    E’ come parlare di “legittimo impedimento”, quando si sà che per legge nessun “impedimento” è legittimo.

    OK, ho capito. E condivido. Grazie per la precisazione.

    @Marco:

    Parlare di “nicchia” per il C mi pare un po’ eccessivo:

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

    e per mia esperienza diretta in ambito aziendale direi che è ancora più diffuso.

    Conosco tiobe, e per quanto criticabile nei metodi rimane comunque un punto di riferimento.

    Detto ciò, tu di cosa ti occupi? Gestionali scritti in C? Non credo. O:-)

    @Jacopo & Giulio85: concordo. :)

  • # 38
    goldorak
     scrive: 

    Giulio85 : e’ vero che con compilatori JIT le prestazioni dei programmi Java si avvicinano e a volte superano perfino quelli di programmi scritti in C.
    Ce’ un pero’, questo vale per applicazioni che non sono interattive. Quando parliamo di applicazioni interattive, tipiche dei desktop Java non e’ la soluzione ideale.

    Io devo dire che l’uso di Java nel desktop rimane anacronistico. Poteva avere un senso negli anni 90 quando Microsoft era all’apice del suo predominio e non cerano soluzioni gia’ pronte per sviluppare codice multipiattaforma. E sul desktop questo era ancora piu’ raro. Poi Sun ha fatto un errore strategico che e’ stato quello di non spingere in maniera adeguata Java sul desktop. Java rimase confinato nel settore middleware ed enterprise. Oggi che esistono toolkits come le QT che offrono una soluzione gia’ pronta per sviluppare codice multipittaforma traendo vantaggio dal C++, l’uso di Java nei desktop se non e’ scomparso del tutto poco ci manca.

  • # 39
    Cesare Di Mauro (Autore del post)
     scrive: 

    Per me la colpa non è di Java (come linguaggio), ma della libreria che Sun ha messo a disposizione per realizzare GUI.

    AWT prima e SWT dopo per me sono degli enormi pachidermi, e il motivo della “lentezza” di Java.

    Sarei curioso di vedere la reattività di Java usando direttamente le API Win32 di Windows, ad esempio, sfruttando le JNI: secondo me c’è gente che non si accorgerebbe nemmeno di avere davanti un’applicazione Java. ;)

  • # 40
    homero
     scrive: 

    x goldorak
    cosa della frase “con java non è possibile programmare applicazioni complesse non ti è chiara?”
    io nel lontano 1997 accolsi con grande favore JAVA salvo rassegnarmi dopo 3 anni del buco nell’acqua che rappresentava…
    non sono prevenuto la mia prevenzione viene essenzialmente dalla mia esperienza di programmatore….sapete cosa significa essere lasciati a piedi da un linguaggio di programmazione? chiedetelo a netscape e YAHOO…
    all’inizio acquistai anche il borland JAVA compiler forse qualcuno se lo ricorda? io memore del fantastico borland C di cui ero entusiasta, mi fiondai su java programmi su windows e rulla su unix e viceversa, sintassi C like, praticamente un sogno…in piu’ le classi e quant’altro facevano sperare in un sistema che permettesse applicazioni di un certo rilievo…
    salvo scoprire che era tutto marketing…le mie non sono considerazioni da BAR ma derivano da una esperienza diretta….
    oggi l’unico linguaggio che non mi ha mai lasciato a terra è stato il C/C++
    anche quando il progetto ha richiesto un ampliamento o un adeguamento all’hardware siamo riusciti a tirarci fuori dai pasticci(le classi servono appunto a questo) essenzialmente perchè il C è un linguaggio perfettamente canonizzato, che non vuol dire solo nella sintassi, ma sopratutto nell’implementazione del compilatore, ossia io posso stimare quante risorse in ram, processore e quant’altro occuperà a grandi linee un’applicazione già in fase di progetto… in java ad un certo momento PUFF! nulla va come previsto…

    il resto dei linguaggi interpretati si equivalgono piu’ o meno tutti…
    programmare in python piuttosto che in perl, piuttosto che ruby o il vecchio lisp o vattela a pesca si ottengono gli stessi risultati e nello stesso tempo..

    su microsoft e .net mi piace ricordare il celeberrimo runtime di visual basic qualcuno se lo ricorda? all’inizio degli anni 2000 tutti i non programmatori programmavano in visual basic c’era persino qualche seminario all’università…

    visual basic ado e access qualcuno se li ricorda?
    tutti i data base sviluppati da pseudo programmatori all’inizio del 2000 con questi linguaggio oggi sono defunti perchè semplicemente non erano scalabili e facevano letterlamente SCHIFO…..e dei listati sapete cosa ne hanno fatto? spazzatura allo stato puro…. la stessa cosa si ripete con C sharp simile al java che si basa sul framework (un tempo lo chiamavano runtime libraries) in somma marketing allo stato puro e qualche vecchio programmatore visual basic si permette anche di dire “il C++ è obsoleto, io programmo in C sharp quello è il futuro” sentendosi alla moda e pronto ad affrontare il futuro con le sue applicazioni spazzatura…

    per quanto riguarda la didattica distinguete tra la forma sintattica e la sostanza, avere una sintassi simile al C come alcuni interpreti non significa avere per le mani un sistema di sviluppo potente come il C…
    ma alle volte mi sembra di parlare al vento…

  • # 41
    Jacopo
     scrive: 

    @Cesare:
    Non so come fosse AWT ma posso parlare di Swing, dato che lo uso. Il motivo per il quale non ha fatto breccia al di fuori degli ambienti enterprise penso che sia una conseguenze della sua inesistente integrazione con le primitive grafiche native, che lo fanno apparire come brutto ed estraneo. Swing in sè non è lento (non più), è un pò più lento solo nell’interazione con l’utente (quando premo un bottone, per intenderci) e per questo appare pesante, anche se non lo è.
    Dopotutto Sun è stata solo coerente con quello che è Java: massima portabilità, che utilizzando librerie native si sarebbe resa più problematica. D
    etto questo, Swing non piace nemmeno a me, troppe righe di codice per fare qualsiasi cosa.

    In questi giorni per curiosità sto dando un’occhiata alle SWT (le librerie sulle quali è costruito Eclipse) e devo dire che mi piaciono davvero molto: sintassi pulita ed essenziale, API potenti e utilizzo delle librerie native. risultato? circa un terzo del codice per fare le stesse cose : D

    @homero
    non mischiare gusti personali con dati di fatto. moltissimi progetti grossi sono fatti con linguaggi non compilati e anzi spesso è la scelta migliore perchè per molte cose facilita la vita.
    senza contare che difficilmente qualcuno inizia a programmare con c o c++, dato che la curva di apprendimento non è proprio in discesa.

  • # 42
    Giulio85
     scrive: 

    @homero: visto che parli di complessità, volendo essere pignoli, ti faccio notare che se un linguaggio è Turing-completo posso fare tutto il computabile, quindi di fatto la POTENZA DI CALCOLO dei linguaggi di programmazione attualmente è la stessa.

    Non esiste un programma che posso fare in C e che non posso fare in Java.

    Un algoritmo che ha ad esempio una complessità lineare, continuerà ad avere una complessità lineare e questo in qualunque linguaggio.

    Possono cambiare le costanti, il punto è: quanto?

    Comunque focalizzarsi SOLO ed esclusivamente sulle prestazioni pure è sbagliato, bisogna tenere in conto i costi, come quelli di manutenzione e delle persone (i famosi MESI-UOMO), l’ingegneria è l’arte del compromesso.

    Della produttività, ovvero delle prestazioni, di un programmatore non ne teniamo conto?

    Comunque sono d’accordo con Cesare, il vero difetto di Java sono le librerie dell’interfaccia grafica, la differenza in questo caso si nota.

  • # 43
    Nessuno
     scrive: 

    Mi permetto di aggiungere la mia esperienza.
    Nella mia vita ho programmato in tantissimi linguaggi. Per professione, ho fatto programmi in assembly (variabili a seconda del micro in uso), C, C++, Java e anche C++.NET (dovendo usare il framework .NET ho deciso di usare il C++ al posto di C# non vedendo un vantaggio nell’uso di quest’ultimo). Per uso personale ho usato un po’ di tutto, persino un linguaggio come Rebol per fare scripting di conversione e piccoli automi on line.
    Non trovo in alcun modo possibile dare una valutazione assoluta sulla bontà o meno di un linguaggio. Ad ogni tipo di progetto, il suo. I driver per Linux non li scrivo in Java e il configuratore di ASIC con le sue decine e decine di pagine di configurazione e qualche migliaio di controlli nell’interfaccia utente non l’ho scritto in ASM.
    Ciò che è indubbio è che vi sono linguaggi che sono più potenti degli altri. Se come “potenza” intendiamo la capacità di fare cose che gli altri non possono fare (indipendentemente dai tempi richiesti per farlo). Inoltre non esiste la possibilità che un linguaggio qualsiasi vada più veloce di codice scritto in C. A meno di non usare un compilatore fatto da un incapace, ormai i compilatori C sono i più ottimizzati data l’età che il linguaggio ha e sopratutto la sua importanza nei progetti critici.
    Un JIT, se va bene, riesce e eguagliare la velocità del C. Non di più. Ma questo avviene solo per algoritmi particolari. Purtroppo, tutti i linguaggi che sono Java-like (per cui anche il framework .NET) soffrono di un impilamento di layer di astrazione pauroso che ne deprime le prestazioni già di suo, come visto sopratutto per la parte grafica, anche se compilati in forma nativa.

    Per quanto riguarda il fatto che linguaggi come il C o il C++ non siano i migliori per iniziare a programmare avrei qualche dubbio. E’ come dire che uno impara meglio a guidare se usa una macchina con il cambio automatico.
    Ovviamente gli aspetti legati alle parti che sono “automatizzate” nei linguaggi Java-like o addirittura con quelli interpretati non possono di certo considerarsi estranee alla buona capacità di saper programmare.
    Se uno non impara a gestire la memoria e si affida totalmente al garbage collector (personalmente una cosa orribile) difficilmente imparerà successivamente a fare in modo che i propri SW non abbiamo memory leak. Anzi, ti guarderà male e ti dirà di usarlo tu un linguaggio che non fa una cosa del genere. Quando uno non sa cosa sia un puntatore e quali potenzialità apra e quali problemi possa portare un uso sbagliato dello stesso, difficilmente comprende il “basso livello”.

    Ovviamente esistono categorie di programmatori a cui certe nozioni di programmazione non servono. Chi programma in Java o con dei linguaggi di alto livello, per definizione, non serve sapere nulla dell’HW che si trova sotto. Quindi rimane più produttivo poiché non deve risolvere problemi che non hanno nulla a che fare con il problema che stanno affrontando.
    Però per quanto riguarda la formazione di un programmatore, eliminare una parte delle difficoltà per appianargli la curva, secondo me equivale a creare un mezzo programmatore che avrà sempre e comunque difficoltà a fare buoni programmi perché gli manca parte della conoscenza che io, personalmente, ritengo di base.

  • # 44
    Nessuno
     scrive: 

    “Non esiste un programma che posso fare in C e che non posso fare in Java.”

    Oh, come no. Prova a fare un driver che accede all’HW in Java e dimmi come fai. Il C è un linguaggio estremamente più potente (in possibilità) di Java. Puoi dire senza ombra di dubbio che tutto quello che fai in Java lo puoi fare in C (con livelli di complessità diversi, ovviamente) ma non il viceversa.
    Se fosse come dici tu saresti in grado di costruire un compilatore per il linguaggio C in Java senza portare limitazioni allo stesso.

  • # 45
    Andrea Del Bene
     scrive: 

    @Nessuno
    Veramente un compilatore del C lo puoi fare con qualsiasi linguaggio turing-completo, quindi anche con Java. Basta avere la grammatica in formato BNF (http://www.vendian.org/mncharity/ccode/grammar/local/degener.txt) e puoi fare il tuo compilatore con il linguaggio che ti pare.

  • # 46
    homero
     scrive: 

    @andrea del bene
    se in teoria con un linguaggio turing-completo è possibile realizzare la quasi totalità degli algoritmi lineari e quindi anche un compilatore…d’altra parte la velocità e sopratutto la gestione della memoria costituiscono un vero limite a tutto.

    faccio un esempio TeX in java, TeX è il famoso software di Knuth per la redazione di documenti scientifici…
    scritto in web, un sorta di linguaggio pascal fu quasi subito compilato in C attraverso l’utiliti di traduzione web2c, quando usci java, si volle produrre una versione in java, per questo si programmo una utiliti web2java, risultato 50 volte piu’ lento, ma funzionava per piccoli documenti…nel 2000 era circa 10 volte piu’ lento e parliamo di un compilatore di documenti da console niente grafica o altro…
    allora si tentò di suddividere in classi le varie funzionalità di questo compilatore di documenti per adattarlo alle caratteristiche peculiari di java, siamo negli anni 2000 e da allora ancora nessuno è riuscito a fare un porting decente(che funzioni in java)

    il motto di SUN
    “compile once, run anywhere” is Sun’s justifiable claim for this language

    si è trasformato in
    “compile once, run nevertime”

  • # 47
    Andrea Del Bene
     scrive: 

    #homero
    Java come qualsiasi altro linguaggio/tecnologia non è un “silver bullet”, non è lo strumento ottimale per qualsiasi cosa. Come giustamente detto da qualcuno nei post precedenti Java, Python, Php o chi che sia possono essere adatti per certi ambiti applicativi e risultare deludenti per altri.
    Il caso che riporti non mi sembra troppo rappresentativo. Parli di un porting fatto in automatico da un convertitore di codice (web2java) che non mi sembra molto popolare e le informazioni a riguardo mi sembra scarseggino su internet. Inutile dire che i convertitori automatici di codice lasciano alquanto a desiderare.
    Ti assicuro però che quando si tratta di middleware e di integrazione di sistemi informativi Java si fa ancora apprezzare, compresa la possibilità di eseguire facilmente i suoi compilati su altre piattaforme.

  • # 48
    Gurzo2007
     scrive: 

    @homero
    forse perchè non serviva a nessuno? infatti javatex è fermo al 98?

    qui la storia è leggermente diversa http://www.monperrus.net/martin/running+tex+on+a+java+virtual+machine

    ps un conto è fare un porting con utilities che fanno la traduzione da un linguaggio a un altro….un conto è riscrivere da zero un progamma in java che implementi come si deve il sw di Knuth

  • # 49
    homero
     scrive: 

    web2java non funziona semplicemente per colpa di Java, web2c funziona benissimo…
    web è praticamente pascal il linguaggio che per decenni si è usato nei corsi universitari per la didattica pertanto il porting con un’altro linguaggio strutturato dovrebbe essere naturale…ricordo che stiamo parlando di algoritmi a sviluppo lineare che interaggiscono poco con l’OS su cui girano….
    “forse perchè non serviva a nessuno? infatti javatex è fermo al 98?” a parte che lo sviluppo è durato fino al 2001 quando anche loro come me si sono stancati di java…il meglio che si è riusciti a fare è stato 10 volte piu’ lento della controparte in C e limiti oggettivi nella compilazione di documenti di grandi dimensioni, (in termini grezzi si impallava quando doveva elaborare documenti di diverse centinaia di pagine forse per qualche bug sull’uso del file system delle virtual machine…)
    quello che intendo asserire in questa discussione che il marketing alle volte coinvolge anche il linguaggi di programmazione,

  • # 50
    Cesare Di Mauro (Autore del post)
     scrive: 

    @homero:

    cosa della frase “con java non è possibile programmare applicazioni complesse non ti è chiara?”

    Il semplice fatto che è del tutto priva di fondamento. Ma comunque se sei in grado di DIMOSTRARLO, anche non in maniera strettamente rigorosa, sono qui pronto a stenderti davanti un tappeto rosso.

    io nel lontano 1997 accolsi con grande favore JAVA salvo rassegnarmi dopo 3 anni del buco nell’acqua che rappresentava…
    non sono prevenuto la mia prevenzione viene essenzialmente dalla mia esperienza di programmatore….sapete cosa significa essere lasciati a piedi da un linguaggio di programmazione? chiedetelo a netscape e YAHOO…

    Stai parlando di UNA, e pure VECCHIA, implementazione di Java.

    Hai la minima idea di quali cambiamenti ed evoluzioni abbia subito la JVM?

    Ma soprattutto: sai cosa significa “linguaggio di programmazione” e qual è la differenza con UNA sua implementazione?

    all’inizio acquistai anche il borland JAVA compiler forse qualcuno se lo ricorda? io memore del fantastico borland C di cui ero entusiasta, mi fiondai su java programmi su windows e rulla su unix e viceversa, sintassi C like, praticamente un sogno…in piu’ le classi e quant’altro facevano sperare in un sistema che permettesse applicazioni di un certo rilievo…
    salvo scoprire che era tutto marketing…le mie non sono considerazioni da BAR ma derivano da una esperienza diretta….

    AI TEMPI avevi delle aspettative TROPPO elevate, che sono state deluse. Ma da lì a generalizzare, e per giunta DOPO TREDICI ANNI, mi sembra decisamente troppo.

    oggi l’unico linguaggio che non mi ha mai lasciato a terra è stato il C/C++
    anche quando il progetto ha richiesto un ampliamento o un adeguamento all’hardware siamo riusciti a tirarci fuori dai pasticci(le classi servono appunto a questo) essenzialmente perchè il C è un linguaggio perfettamente canonizzato, che non vuol dire solo nella sintassi, ma sopratutto nell’implementazione del compilatore, ossia io posso stimare quante risorse in ram, processore e quant’altro occuperà a grandi linee un’applicazione già in fase di progetto… in java ad un certo momento PUFF! nulla va come previsto…

    I miei colleghi che sviluppano applicazioni J2ME possono darti ampie lezioni su quanto occupa una classe, un’istanza, un vettore, ecc..

    Tutte informazioni indispensabili anche con Java (specialmente per la versione mobile, dove lo spazio è molto risicato), e che un professionista degno di questo nome è in grado di recuperare.

    il resto dei linguaggi interpretati si equivalgono piu’ o meno tutti…
    programmare in python piuttosto che in perl, piuttosto che ruby o il vecchio lisp o vattela a pesca si ottengono gli stessi risultati e nello stesso tempo

    Ancora una volta dimostri di non sapere quello che dici. Dipende sempre dal contesto, ovviamente.

    su microsoft e .net mi piace ricordare il celeberrimo runtime di visual basic qualcuno se lo ricorda? all’inizio degli anni 2000 tutti i non programmatori programmavano in visual basic c’era persino qualche seminario all’università…

    visual basic ado e access qualcuno se li ricorda?
    tutti i data base sviluppati da pseudo programmatori all’inizio del 2000 con questi linguaggio oggi sono defunti perchè semplicemente non erano scalabili e facevano letterlamente SCHIFO…..e dei listati sapete cosa ne hanno fatto? spazzatura allo stato puro….

    Fammi capire: per caso stai cercando di scaricare le colpe di programmatori improvvisati, che sono tali per tua stessa ammissione, sulle IMPLEMENTAZIONI dei linguaggi che hanno usato?

    la stessa cosa si ripete con C sharp simile al java che si basa sul framework (un tempo lo chiamavano runtime libraries) in somma marketing allo stato puro

    E quindi anche in questo vorresti scaricare la colpa delle stupidaggini di gente inesperta sul linguaggio / framework?

    Ma tu la logica sai per caso dove sta di casa?

    e qualche vecchio programmatore visual basic si permette anche di dire “il C++ è obsoleto, io programmo in C sharp quello è il futuro” sentendosi alla moda e pronto ad affrontare il futuro con le sue applicazioni spazzatura…

    E tu come ti permetti di spalare letame su Java? I tuoi gusti vanno bene, e quelli degli altri no?

    per quanto riguarda la didattica distinguete tra la forma sintattica e la sostanza, avere una sintassi simile al C come alcuni interpreti non significa avere per le mani un sistema di sviluppo potente come il C…
    ma alle volte mi sembra di parlare al vento…

    Più che altro è evidente che tu non sei certo diverso della gente di cui ti lamenti essersi improvvisata programmatrice.

    E’ chiaro come il sole ormai che non hai nemmeno le basi per poter parlare di “linguaggio di programmazione”, confondendoli con alcune loro implementazioni.

    Specialmente davanti a roba come “sintassi e sostanza”, che di tecnico non han proprio nulla, c’è da soltanto da calare un velo pietoso.

    I padri dell’informatica moderna si staranno ribaltando nella tomba.

    La ciliegina sulla torta, poi, è rappresentata dai linguaggi “con sintassi simile al C”, che classifichi come interpreti, e che ovviamente per te non sono potenti come il C. Come se al mondo non esistessero degli interpreti C… e allora il C come lo classifichi davanti a queste “aberrazioni”? Sarà sicuramente uno squallido linguaggio da buttare via.

    @Jacopo: non conosco le Swing, ma le SWT derivano dalle AWT di cui ti parlavo prima.

    Ricordo però che c’era il classico hello, world, realizzato con le AWT e le SWT, che per aprire una sola finestra con quella scritta e un bottone OK caricavano rispettivamente 600 e 800 classi.

    Ovviamente lavorando coi class loader se ne possono caricare molto meno, ma è roba più sofisticata e avanzata.

    L’esempio serve a rendere l’idea di quanto “pesante” sia lavorare con queste librerie.

    Ma parliamo sempre di librerie, comunque. Personalmente mi dà molto fastidio che un linguaggio venga “messo a morte” tirando in ballo qualche esempio che verte appunto su roba simile. Ecco perché prima parlavo di vedere Java messo alla prova con le Win32 tramite le JNI, proprio per cercare di testare il linguaggio e non l’ambiente.

    @Nessuno:

    Ciò che è indubbio è che vi sono linguaggi che sono più potenti degli altri. Se come “potenza” intendiamo la capacità di fare cose che gli altri non possono fare (indipendentemente dai tempi richiesti per farlo).

    Tutti i linguaggi Turing-completi sono equipotenti.

    Inoltre non esiste la possibilità che un linguaggio qualsiasi vada più veloce di codice scritto in C. A meno di non usare un compilatore fatto da un incapace, ormai i compilatori C sono i più ottimizzati data l’età che il linguaggio ha e sopratutto la sua importanza nei progetti critici.
    Un JIT, se va bene, riesce e eguagliare la velocità del C. Non di più. Ma questo avviene solo per algoritmi particolari.

    No, ci sono casi in cui Java supera il C a livello prestazionale. Se cerchi su internet trovi dei test.

    Non si tratta della miglior qualità dei compilatori C, perché i compilatori JIT funzionano in maniera diversa: fanno profiling a runtime e ottimizzano eventualmente il codice in base ai dati che raccolgono.

    I compilatori C hanno, invece, una visione statica del codice, e il codice tirato fuori è uno soltanto.

    Purtroppo, tutti i linguaggi che sono Java-like (per cui anche il framework .NET) soffrono di un impilamento di layer di astrazione pauroso che ne deprime le prestazioni già di suo, come visto sopratutto per la parte grafica, anche se compilati in forma nativa.

    Comunque anche su questo c’è della ricerca. Ti consiglio in particolare di cercare documentazione sul progetto Dynamo di HP (eventualmente su Ars Technica trovi un articolo che ne parla).

    Per quanto riguarda il fatto che linguaggi come il C o il C++ non siano i migliori per iniziare a programmare avrei qualche dubbio. E’ come dire che uno impara meglio a guidare se usa una macchina con il cambio automatico.

    L’esempio non calza, e comunque l’obiettivo primario rimane quello di imparare a guidare, e lo si fa meglio con una Panda con cambio automatico che con una F2010.

    Ovviamente gli aspetti legati alle parti che sono “automatizzate” nei linguaggi Java-like o addirittura con quelli interpretati non possono di certo considerarsi estranee alla buona capacità di saper programmare.
    Se uno non impara a gestire la memoria e si affida totalmente al garbage collector (personalmente una cosa orribile) difficilmente imparerà successivamente a fare in modo che i propri SW non abbiamo memory leak. Anzi, ti guarderà male e ti dirà di usarlo tu un linguaggio che non fa una cosa del genere. Quando uno non sa cosa sia un puntatore e quali potenzialità apra e quali problemi possa portare un uso sbagliato dello stesso, difficilmente comprende il “basso livello”.

    Del tutto in disaccordo. Il concetto di memory leak trascende quello di puntatore inteso come riferimento a basso livello di una zona di memoria.

    Ovviamente esistono categorie di programmatori a cui certe nozioni di programmazione non servono. Chi programma in Java o con dei linguaggi di alto livello, per definizione, non serve sapere nulla dell’HW che si trova sotto. Quindi rimane più produttivo poiché non deve risolvere problemi che non hanno nulla a che fare con il problema che stanno affrontando.

    Perfettamente d’accordo.

    Però per quanto riguarda la formazione di un programmatore, eliminare una parte delle difficoltà per appianargli la curva, secondo me equivale a creare un mezzo programmatore che avrà sempre e comunque difficoltà a fare buoni programmi perché gli manca parte della conoscenza che io, personalmente, ritengo di base.

    Secondo te, allora, perché di recente al MIT hanno scelto Python per il corso introduttivo di programmazione? Per parecchi anni hanno usato Scheme, che in ogni caso è ben lontano da C et similia.

    Come te lo spieghi?

    Oh, come no. Prova a fare un driver che accede all’HW in Java e dimmi come fai. Il C è un linguaggio estremamente più potente (in possibilità) di Java. Puoi dire senza ombra di dubbio che tutto quello che fai in Java lo puoi fare in C (con livelli di complessità diversi, ovviamente) ma non il viceversa.
    Se fosse come dici tu saresti in grado di costruire un compilatore per il linguaggio C in Java senza portare limitazioni allo stesso.

    E tu pensi che non sia possibile farlo? Esistono s.o. scritti in Java, e alcuni progetti con addirittura Python.

    D’altra parte anche usando il C, a volte non si può fare a meno di assembly o linguaggio macchina.

    Per il resto, Andrea Del Bene ti ha dimostrato che è possibilissimo farlo.

    @homero:

    web2java non funziona semplicemente per colpa di Java, web2c funziona benissimo…
    web è praticamente pascal il linguaggio che per decenni si è usato nei corsi universitari per la didattica pertanto il porting con un’altro linguaggio strutturato dovrebbe essere naturale…

    Punto primo in passato i s.o. si scrivevano anche in Pascal o suoi derivati / successori, e non avevano nulla da invidiare a quelli realizzati in C sul piano prestazionale.

    Punto secondo, affermare che Java sia un linguaggio per la programmazione strutturata come il Pascal, beh, si commenta da sé.

    quello che intendo asserire in questa discussione che il marketing alle volte coinvolge anche il linguaggi di programmazione,

    Per me dovresti intanto uscire dalla trappola temporale in cui sei rimasto rinchiuso.

    E poi, cosa ancora più importante, studiare seriamente un po’ di informatica, storia inclusa.

  • # 51
    Max
     scrive: 

    Al mit usano il python per l’introduzione alla programmazione, a Stanford usano il java, e ad Harvard usano lo Scracth per le prime lezioni e poi il c, e sicuramente i primi due corsi sono più semplici da seguire perchè il c pone fin dall’inizio molti problemi e sottigliezze che uno che deve imparare a programmare non ha bisogno di imparare subito. In verità molte cose uno potrebbe anche non impararle mai: ad esempio si possono fare tranquillamente delle applicazioni performanti usando il c#, e se uno fin dall’inizio studia solo quello può non sapere mai cos’è un puntatore o cosa sia la gestione manuale della distruzione degli oggetti, ma se riesce a fare tutto quello che vuole fare e i suoi programmi funzionano che problema c’è?
    Non è che per forza un programmatore debba essere in grado di scrivere praticamente in linguaggio macchina per potersi dire un vero programmatore, soprattutto se consideriamo il lato economico della cosa, nel senso che se hai una buona idea per un programma e la realizzi bene in c# o in java puoi fare soldi a palate senza bisogno di conoscere linguaggi di basso livello, se non hai delle buone idee ma conosci perfettamente il c/c++ farai dei programmi che fanno schifo e al massimo potrai fare il dipendente di qualche software house o il tecnico di qualche azienda, molto spesso con stipendi da fame.
    I linguaggi di programmazione sono come i linguaggi umani: non ce n’è uno superiore all’altro (almeno quando sono Touring complete, e tutti i linguaggi modermi lo sono), ma alcuni si adattano meglio di altri ad esprimere certe idee, quando si adattano meglio vuol dire che richiedono meno parole per esprimere un concetto particolare, e sono più chiari e quindi meno soggetti ad interpretazioni sbagliate. Per i linguaggi di programmazione è uguale, e come per i linguaggi umani uno di solito finisce per parlare nella lingua che conosce meglio, anche se magari non è la più adatta per esprimere quello che sta dicendo, così anche i programmatori finiscono per usare i linguaggi con cui si trovano meglio, ed è giusto che sia così, ma non è necessario per questo criticare chi lavora meglio con altri linguaggi, o addirittura criticare i linguaggi stessi perchè non sono come il linguaggio preferito.
    Quanto scritto nell’articolo su una possibile morte del java negli anni a venire è sicuramente condivisibile, perchè Oracle non si sa bene cosa ne voglia farne (come anche per mysql e per tutto quello che era la Sun), soprattutto in un momento in cui ci sono tantissimi nuovi e recenti linguaggi di programmazione che lottano per avere un posto al sole. Attualmente credo che il c# abbia le carte in regola per essere il futuro in ambito desktop, perchè visti i miglioramenti prestazionali introdotti nelle ultime versioni il fatto che sia un linguaggio per metà interpretato ormai non è quasi più un handicap, soprattutto visto l’hardware che abbiamo a disposizione oggi (se anche hello world è un eseguibile di 1 Mb che me ne frega quando ho un hard disk da 1-2 Tb?), e il linguaggio è molto più rapido da usare e molto meno soggetto a possibili errori, quindi il codice risulta più breve e semplice da debuggare, e il tempo in più che il programmatore in c/c++ perde per ottimizzare il codice il programmatore in c# lo può usare per trovare degli algoritmi migliori (il che rende sicuramente di più in termini di prestazioni che non la gestione a basso livello del c); in ambito server il python ha guadagnato una grossa fetta di mercato, e il perl rimane per il resto, soprattutto per quegli script che devono lavorare su stringhe di testo, e anche in questo caso è normale perchè un sysadmin non si può pretendere che sia un guru del c e che per ogni problema piccolo o grande si scriva un programma in c; in quanto ai dispositivi mobile è vero che il c consente di ottimizzare al massimo le risorse, ma è vero anche che è troppo complicato per rendere dal punto di vista economico: Google deve lottare per far trionfare Android contro l’Iphone, e come dice la Apple per ogni cosa c’è una app, se per rendere performanti al massimo le applicazioni su Android Google obbligasse ad usare solo il c/c++ quanti sarebbero in grado di farlo? I nuovi linguaggi di programmazione hanno portato tanta gente nuova nel mondo della programmazione, gente che magari ha imparato il php per gestire il suo sito ma non sa nulla di c, oppure gente che ha imparato a programmare in java, che magari ha già fatto qualche giochino per cellulari in java, certo non si tratterà di super programmatori in grado di scrivere un sistema operativo con una mano legata dietro alla schiena, ma fanno comunque un grande numero e possono tirare fuori diverse cose di qualità.
    Per questo credo che il c e c++ abbiano un futuro ormai assolutamente ristretto al campo dei sistemi operativi e delle applicazioni assolutamente critiche in cui è necessaria anche la più piccola ottimizzazione, ma quasi nessuno scrive sistemi operativi, programmi per supercomputer, motori di programmi di scacchi, o cose simili. Ed è un bene perchè ora programmare è molto più semplice, veloce e redditizio rispetto al passato, ed è così anche molto più aperto a persone non espertissime, e quindi a nuove idee, mentre un tempo gli informatici erano quasi tutti matematici. Pensate ai cambiamenti nel web di questi ultimi anni, se chi ha avuto l’idea di creare youtube o facebook avesse dovuto scrivere un lungo programma in fortran questi siti sarebbero mai nati?

  • # 52
    homero
     scrive: 

    @CDMAURO

    “cosa della frase “con java non è possibile programmare applicazioni complesse non ti è chiara?”
    Il semplice fatto che è del tutto priva di fondamento. Ma comunque se sei in grado di DIMOSTRARLO, anche non in maniera strettamente rigorosa, sono qui pronto a stenderti davanti un tappeto rosso.

    credo di aver mostrato come esempio javatex in cui un software sviluppato in web e compilato in pascal puo’ essere convertito ed utilizzato in C e non in Java….
    http://www.tug.org/tug99/program/node41.html
    java era 50 volte piu’ lento oggi è circa 10 volte piu’ lento, ossia gira sui nostri computer come girava su pc di 20 anni fa…

    se poi i widget dei telefonini le vogliamo chiamare applicazioni allora la storia cambia…quelle si possono scrivere in flash tranquillamente se acquistassero la licenza adobe…

    per quanto riguarda la mia ignoranza nel significato di linguaggio di programmazione, vorrei solo dire che un linguaggio di programmazione a mio modestissimo giudizio non puo’ prescindere dalla sua implementazione…
    ossia considerare java al difuori della virtual machine di SUN e dello scopo per il quale java è stato concepito e pubblicizzato è forviante…come quelli che utilizzano gjc per programmare in java e produrre direttamente codice oggetto grazie java2c che è implementato nel gnu compiler…lo stesso listato compilato per la virtual machine è tutta un’altra musica…

    per quanto riguarda java per cellulari sono implementazioni dove c’è piu’ assembly che java…ma questa è un’altra storia…

    il C/C++ nelle sue specifiche ansi non descrivono tanto la sintassi ma piuttosto come il compilatore deve gestire le funzioni messe a disposizione del linguaggio, ossia come devono essere compilate le funzioni, la gestione dello stack e della allocazione della memoria, quando parlo di linguaggio C/C++ io considero tutto il pacchetto ossia linguaggio e compilatore, perchè del linguaggio solamente che ci faccio? per il C/C++ io ho delle implementazioni ossia dei compilatori che sono eccellenti che permettono di fare la stragrande maggioranza dei programmi con la piena sicurezza che il compilatore ossia l’implementazione del linguaggio “nascosta” al programmatore non ti lascia a terra…

    quello che non riesco a comunicarvi è che un linguaggio di programmazione da solo per quanto bello ed elegante dal punto di vista teorico se non ha un’implementazione efficente non serve assolutamente a nulla…
    il C ha dimostrato sul campo dal 1972 in avanti che ha saputo sfidare i decenni e permettere di sviluppare software che ancora oggi viene utilizzato e compilato…
    adesso questo non significa essere chiuso nel passato significa apprezzare le cose che funzionano…
    il kickstart dell’amiga è stato programmato in B un antenato del C cosi’ come la maggioranza dei kernel unix e dagli anni 80 in cui i computer avevano 512kb di ram e non gbyte di ram, oggi il C si è adeguato ad essere implementato su macchine centinaia di volte piu’ potenti di quelle sulle quali è stato concepito, vi sembra poca cosa?

    vedere un linguaggio di programmazione come qualcosa di astratto ossia slegato dalla sua implementazione significa essere fuori dalla realtà…
    Java ha avuto una implementazione schifosa forse proprio a causa della sua struttura sintattica….

    per quanto riguarda microsoft:
    “cosa non hai capito della frase:” dopo 5 anni il codice scritto in visual basic lo hanno dovuto buttare dalla finestra?”
    ma sapete quante persone hanno buttato soldi in manuali, activex, microsoft professional support e dio solo sa cos’altro per illudersi di programmare qualcosa di decente per poi buttare tutto dalla finestra dopo pochi anni? questo è marketing e non c’entra niente con la programmazione e con l’opinione personale perchè è un dato di fatto e lo stesso sta succedendo con C sharp anche se in misura notevolmente inferiore proprio grazie ai linguaggi interpretati come python et similia…

    il marketing dei linguaggi di programmazione è un dato di fatto e sun ha cavalcato l’onda del marketing in questi 13 anni non so perchè e percome…il CEO di Sun ai tempi di java del 1997 era consulente per l’informatica di Clinton forse troppe donne gli hanno fatto fondere il cervello…

  • # 53
    Cesare Di Mauro (Autore del post)
     scrive: 

    @homero:

    credo di aver mostrato come esempio javatex in cui un software sviluppato in web e compilato in pascal puo’ essere convertito ed utilizzato in C e non in Java….
    http://www.tug.org/tug99/program/node41.html
    java era 50 volte piu’ lento oggi è circa 10 volte piu’ lento, ossia gira sui nostri computer come girava su pc di 20 anni fa…

    Non hai dimostrato niente, se non che la conversione da un linguaggio strutturato a uno a oggetti andava più lentamente AI TEMPI.

    E no, oggi Java ha prestazioni comparabili al C, come ho già detto e t’invito a documentarti, visto che continui a rimanere indietro nel tempo.

    se poi i widget dei telefonini le vogliamo chiamare applicazioni allora la storia cambia…quelle si possono scrivere in flash tranquillamente se acquistassero la licenza adobe…

    Non puoi continuare a offendere chi lavora in campi che è evidente tu sconosci del tutto.

    Scrivere un gioco per J2ME, tenendo conto del parco installato e delle limitazioni presenti, non è affatto banale. Tant’è che per le versioni con meno risorse i programmatori sono costretti a farsi i conti a manina per capire quanto spazio viene occupato anche semplicemente dalla definizione di una classe.

    E si tratta di applicazioni anche molto complesse, tra l’altro.

    per quanto riguarda la mia ignoranza nel significato di linguaggio di programmazione, vorrei solo dire che un linguaggio di programmazione a mio modestissimo giudizio non puo’ prescindere dalla sua implementazione…
    ossia considerare java al difuori della virtual machine di SUN e dello scopo per il quale java è stato concepito e pubblicizzato è forviante…come quelli che utilizzano gjc per programmare in java e produrre direttamente codice oggetto grazie java2c che è implementato nel gnu compiler…lo stesso listato compilato per la virtual machine è tutta un’altra musica…

    E’ una tua opinione che ovviamente non condivido, visto che un linguaggio definisce sintassi e semantica, e null’altro.

    Difatti le tue lamentele circa a Java sono relative alle tue esperienze di tredici anni fa, mentre l’implementazione della JVM è cambiata enormemente e, come dicevo, ormai ha prestaziona comparabili a quelle del C.

    Quindi l’implementazione conta nel lavoro di tutti i giorni (certamente non quello di 13 anni fa), ma non per mettere alla berlina un linguaggio di un programmazione.

    per quanto riguarda java per cellulari sono implementazioni dove c’è piu’ assembly che java…ma questa è un’altra storia…

    I miei colleghi non lavorano in assembly né vanno a ritoccarsi il bytecode a manina (al massimo usano un offuscatore di codice, che ottimizza anche un po’ il bytecode generato): i loro sorgenti sono puro Java. Ottimizzato anche pesantemente (del tipo che quando scorrono degli array non controllano la fine degli elementi, ma eseguono un try / catch intercettando l’eccezione di index out of bound), ma sempre Java rimane.

    il C/C++ nelle sue specifiche ansi non descrivono tanto la sintassi ma piuttosto come il compilatore deve gestire le funzioni messe a disposizione del linguaggio, ossia come devono essere compilate le funzioni, la gestione dello stack e della allocazione della memoria,

    Questo è del tutto falso. Viene definita la sintassi e la semantica dei linguaggi, e null’altro.

    Puoi farmi vedere in quale parte del draft degli standard è scritto quello che hai riportato tu?

    quando parlo di linguaggio C/C++ io considero tutto il pacchetto ossia linguaggio e compilatore, perchè del linguaggio solamente che ci faccio?

    Lo usi per lavorare. Non erano multipiattaforma C e C++? Mi aspetto che QUALUNQUE applicazione scritta con questi linguaggi giri indifferentemente su qualunque macchina (risorse permettendo), a prescindere dal compilatore (e dal sistema operativo) utilizzato.

    per il C/C++ io ho delle implementazioni ossia dei compilatori che sono eccellenti che permettono di fare la stragrande maggioranza dei programmi con la piena sicurezza che il compilatore ossia l’implementazione del linguaggio “nascosta” al programmatore non ti lascia a terra…

    A parte il fatto che anche i compilatori soffrono di bug, e quindi possono lasciarti per terra, supponendo che il loro lavoro sia “eccellente”, come dici tu, a lasciarti per terra generalmente è il codice che hai scritto e che contiene bug, anche molto subdoli, che in altri linguaggi non esistono o hanno effetti ridotti.

    quello che non riesco a comunicarvi è che un linguaggio di programmazione da solo per quanto bello ed elegante dal punto di vista teorico se non ha un’implementazione efficente non serve assolutamente a nulla…

    L’efficienza di per sé non serve a nulla, se non è un requisito dell’applicazione.

    Come programmatore ho un solo “comandamento” da rispettare: risolvere il problema che mi è stato sottoposto assolvendo ai suoi requisiti (fra i quali c’è quello lapalissiano che dev’essere utilizzabile dal cliente).

    il C ha dimostrato sul campo dal 1972 in avanti che ha saputo sfidare i decenni e permettere di sviluppare software che ancora oggi viene utilizzato e compilato…
    adesso questo non significa essere chiuso nel passato significa apprezzare le cose che funzionano…

    Quello che hai scritto vale per tanti linguaggi di programmazione, Java incluso.

    il kickstart dell’amiga è stato programmato in B un antenato del C cosi’ come la maggioranza dei kernel unix e dagli anni 80 in cui i computer avevano 512kb di ram e non gbyte di ram, oggi il C si è adeguato ad essere implementato su macchine centinaia di volte piu’ potenti di quelle sulle quali è stato concepito, vi sembra poca cosa?

    Il KickStart dell’Amiga è stato sviluppato in puro assembly Motorola 68000, come in assembly erano sviluppati tantissimi kernel dell’epoca, e gli interpreti LISP o BASIC per chi poteva permettersene uno a disposizione.

    Quindi secondo il tuo ragionamento avremmo dovuto continuare a usare l’assembly. Io l’ho fatto, per anni, e so cosa significhi perdere un mare di tempo a ottimizzare il codice cercando di risparmiare spazio e/o preziosi cicli di clock.

    Ma erano altri tempi, e oggi non lo rifarei di certo, se non piccolissime porzioni di codice critico se e solo se ne ravvisassi l’utilità.

    Giusto per chiarezza, tu parlavi di AmigaDOS, non del KickStart. AmigaDOS fu sviluppato in BCPL (predecessore del C, e successore del B), e purtroppo chi ha programmato seriamente con Amiga sta ancora a piangere per lo scempio che è stato fatto. Tra l’altro la cosa assurda è che all’epoca era già disponibile il C, per cui se proprio bisognava farsi del male, si poteva benissimo usare un linguaggio ben più diffuso dell’anonimo BCPL.

    E per chiudere il discorso, il C fu usato per riscrivere il Kickstart con la versione 2.0 di AmigaOS, lasciando comunque un buon 10% di assembly.

    Per cui la domanda sorge spontanea: se il C è così legato all’hardware, come mai ancora oggi, in pieno 2010, certe parti si continuano a scrivere in assembly?

    E a questo punto, considerato il “metro” che usi per definire la “potenza” di un linguaggio di programmazione, visto che il più potente è l’assembly (in realtà piazzerei il linguaggio macchina al primo posto in assoluto, ma vorrei vedere quanti sarebbero disposti a lavorarci), di cui sono disponibili “eccellenti” assemblatori, perché non torniamo tutti all’ovile e sviluppiamo applicazioni esclusivamente con questo linguaggio?

    Dovresti essere enormemene felice, no? :D

    vedere un linguaggio di programmazione come qualcosa di astratto ossia slegato dalla sua implementazione significa essere fuori dalla realtà…

    Fuori dalla realtà c’è soltanto chi non capisce cosa significa utilizzare un certo strumento per risolvere un determinato problema.

    Un linguaggio di per sé non è criticabile a causa di una sua implementazione. Non ha senso.

    Java ha avuto una implementazione schifosa forse proprio a causa della sua struttura sintattica….

    E qui potrei anche condividere la tua opinione, visto che la sintassi è fortemente ispirata al C. :D

    per quanto riguarda microsoft:
    “cosa non hai capito della frase:” dopo 5 anni il codice scritto in visual basic lo hanno dovuto buttare dalla finestra?”
    ma sapete quante persone hanno buttato soldi in manuali, activex, microsoft professional support e dio solo sa cos’altro per illudersi di programmare qualcosa di decente per poi buttare tutto dalla finestra dopo pochi anni? questo è marketing e non c’entra niente con la programmazione e con l’opinione personale perchè è un dato di fatto

    Ripeto nuovamente: è un problema dello strumento o dei programmatori improvvisati di cui ti lamentavi prima?

    e lo stesso sta succedendo con C sharp anche se in misura notevolmente inferiore proprio grazie ai linguaggi interpretati come python et similia…

    I programmatori scarsi e/o improvvisati li trovi anche su C / C++ (e non farmi fare qualche nome eccellente, altrimenti si scateneranno sì orde di fanatici a fustigarmi :D).

    Se poi volevi dire altro, sii più chiaro. In particolare, lavorando quasi esclusivamente con Python ormai, sarei interessato a capire cosa trovi di male in questo linguaggio. Sia chiaro che sono seriissimo: apprezzo le critiche, anche feroci (ma NON offensive o puramente denigratorie), purché costruttive, perché mi piace migliorarmi.

    il marketing dei linguaggi di programmazione è un dato di fatto e sun ha cavalcato l’onda del marketing in questi 13 anni non so perchè e percome…il CEO di Sun ai tempi di java del 1997 era consulente per l’informatica di Clinton forse troppe donne gli hanno fatto fondere il cervello…

    Come dicevo prima e hanno ribadito poi altri, a me del marketing non frega nulla perché giudico i linguaggi di programmazione come strumenti, che hanno pregi e difetti, e ambiti applicativi in cui sono “migliori” di altri.

    Per il resto, sono un professionista e ho già espresso qual è l’unico “comandamento” che seguo.

  • # 54
    Gurzo2007
     scrive: 

    @homero

    scusa ma ti sei accorto che ancora riprendi una pagina internet del 99? la cui ultima modifica è del 14/09/1999? forse come detto da altri dopo più di 10 anni qualcosa sia cambiato?

  • # 55
    Gurzo2007
     scrive: 

    @homero

    mi scuso avevo scritto di fretta l’altro commento e non avevo argomentato meglio, ma cmq il concetto è quello riproponi una pagina di un abstract sull’argomento TeX java risalente appunto alla data menzionata prima, risalente al 99…il 50 volte più lento si riferisce se non interpreto male dal contesto del discorso al 98, un anno dopo grazie al nuovo jit siamo a 10 volte più lento, e in conclusione si afferma che un anno dopo probabilmente si arriverà a 2-3 volte più lento…

    ora mi sembra che siamo leggermente oltre quell’anno ipotetico…e come detto da altri le cose sono notevolmente cambiate…e restare ancorati a vecchie esperienze è da “fanatici”..scusami il termine

  • # 56
    Nessuno
     scrive: 

    Non quoto perché non è comodo in questo blog, ma rispondo per ordine:
    non mi è stata mostrata nessuna prova che con Java (e relativa JVM) sia possibile accedere all’HW per scrivere un driver.
    E sebbene uno possa credere che tutti i linguaggi Turing-completi siano equi-potenti, purtroppo non è così, come infatti dimostra il fatto che ogni linguaggio si adatta meglio o peggio secondo il problema che deve risolvere e l’ambiente in cui deve operare.

    Il fatto più ovvio di questa cosa è che i vari compilatori/interpreti per i vari linguaggi moderno, non siano scritti con i linguaggi stessi o altri linguaggi moderni, ma in C/C++ se non in Assembly quando possibile. Nessuno farebbe un compilatore C in LISP. O in Python. O in Rebol.
    La VM Java non è scritta in Java. Perché? Perché semplicemente l’ambiente in cui opera il linguaggio Java non è adatto a fare certe cose (e anzi è di impedimento). Ovviamente si adatta perfettamente ad altre.
    Quello che intendo dire è che tutti i linguaggi interpretati sono limitati nella loro potenzialità dall’ambiente stesso (l’interprete) in cui devono operare, mentre i linguaggi di “basso livello” come il C/C++ (ovviamente non solo, ma sono i più diffusi) sono gli unici che permettono di superare qualsiasi problema e quindi di fare da base per tutti gli altri.

    Ritornando alla questione della gestione della memoria, nella mia esperienza ho visto che chi impara a programmare affidandosi al Garbage Collector poi ha serie difficoltà a gestire la memoria in maniera corretta quando lo deve fare a mano usando il proprio cervello per verificare il flusso teorico del codice. E non capisce che dalle funzioni non si può esportare un puntatore ad un array sullo stack. E via di queste cose.
    La questione dei puntatori riportata precedentemente era slegata a quella dell’allocazione di memoria, ma comunque come vedi è possibile congiungere le due cose, perché ovviamente per chi usa il C l’uso di puntatori e gestione della memoria sono la stessa cosa, o due facce della stessa medaglia.
    L’uso di linguaggi propedeutici al C/C++ non è vietato (io ho iniziato con il Basic del C64 come primissima cosa) ma è ovvio che subito dopo il salto lo si deve fare. Se dopo aver imparato ad andare in tricilo non si sale sulla bici, non si può dire di essere un ciclista. Certo, si può andare in giro lo stesso a piedi o con il triciclo. Ma la differenza è quella e resta.

    Per rispondere a Max, ovvio che se uno nella vita si occupa solo di fare certi tipi di applicazioni non gli serve e mai servirà sapere nulla di stack e puntatori. Ovviamente però è un “mezzo programmatore”, non meno di uno che sa guidare esclusivamente un’auto col cambio automatico. Addirittura chi guida un treno non deve neanche preoccuparsi di girare il volante. O chi va in bici di usare l’acceleratore.
    A ognuno il suo mezzo, ma qui si parla di creare la conoscenza a persone che domani devono entrare nel mondo del lavoro con competenze che devono sostenerle per il resto della vita. Altrimenti si può anche dire che uno non ha bisogno di andare in università ad imparare un bel niente, tanto basta imparare il PHP come autodidatta e farsi assumere da una azienda che fa siti Web per spacciarsi come programmatore. E secondo la tua logica, fare una palata di soldi, mentre il “pirla” che si è studiato per anni come ottimizzare il codice può giusto fare il tecnico in qualche ditta che fa manutenzione ad apparati ormai obsoleti.

    A parte che la questione economica qui non conta nulla, perché se uno guadagna più soldi non è detto che possa considerare tecnicamente migliore nel campo della programmazione (semplicemente può fare un lavoro che ci assomiglia, come lo fanno i manager che si occupano di gestire i programmatori ma che non sanno un’acca di codice sorgente). Quello che proprio mi sconvolge è la questione che hai detto: cosa mi interessa se il mio Hello Word occupa 1MB quando ho un HDD da 1 tera?
    Credo che qualsiasi programmatore che si possa definire davvero tale sia rimasto un po’ infastidito da una espressione del genere. Chiunque può mettersi davanti ad uno schermo e scrivere codice. Anche una scimmia. Ma il programmatore, quello vero, quello che si distingue dalle scimmie, è quello che sa cosa sta facendo. Come in ogni campo professionale. Chi spreca risorse “tanto ho 2GB di RAM e 1TB di HDD” ovviamente non ha certo la professionalità adatta per fare quel mestiere. Lo può fare, può guadagnarci soldi, ma è e rimane quello che in gergo si chiama “zappatore di codice”. Ovvero uno che si arrabatta a fare in qualsiasi modo, basta che funzioni (magari anche per un tempo limitato, poi tanto scade le garanzia).
    La valutazione dell’uso di risorse rispetto alla complessità del SW che si deve andare a scrivere è un requisito fondamentale del processo formativo del programmatore. Chi non ha la competenza, non è un programmatore. E su questo punto non c’è modo che mi si possa convincere del contrario.
    Ovvio che quindi oggi c’è più gente che programma. Abbassando il livello di accettabilità a sufficienza tutti quelli che si siedono davanti ad una tastiera possono essere considerati programmatori. Anche quelli che inseriscono le formule in Excel, perché no. Ma in verità coloro che sanno programmare davvero non sono di questo tipo.
    La definizione “lasca” di programmatore come colui che spara codice per farlo eseguire dal microprocessore in qualche modo è un ovvio danno, non al mercato del programmatore, ma tanto su quello della qualità dei prodotti in cui questi programmi usati. Se ci fosse stata meno gente in grado di programmare e quindi sito come Facebook non fossero esistiti non mi pare proprio che sarebbe stato un problema. Anzi. Ma il problema diventa quando si mette sullo stesso piano il “programmatore” del sito di Facebook con quello che gestisce la strumentazione dello Shuttle. O di qualsiasi altro apparato in cui l'”hello word” da 1MB non è ovviamente né ammissibile né tanto meno giustificabile.

    D’altronde oggi si è abituati ad usare SO da 50GB di installazione che usano 2GB di RAM solo per presentare un puntatore… ma che parlo a fare…

  • # 57
    homero
     scrive: 

    ************************************************************
    E’ una tua opinione che ovviamente non condivido, visto che un linguaggio definisce sintassi e semantica, e null’altro.
    ************************************************************

    questo non te lo concedo manco un po’, vatti a leggere lo standard ansi del C…quello vero non i libri che si trovano in libreria…
    poi capisco perchè molti hanno problemi con i puntatori o con la ricorsione delle funzioni…questo proprio non te lo concedo…
    perchè E’ ULTRAFALSO!
    nello standard C è scritto tutto x filo e per segno dove e come allocare le funzioni nello stack, come gestire i puntatori alla ram e al registro indirizzi della cpu….quando svuotare la memoria allocata…come gestire il preprocessing gli oggetti volatili, dove inserire le variabili globali e quelle esterne questa è l’implementazione….ma io che parlo a fare….tanto qui non avete neppure letto le prime 50 pagine dello standard C…questo è il dramma di chi frequenta le facolta di informatica di oggi che tutto è fatto alla carlona…

    **************************************************************
    in python non trovo nulla di male fa il suo sporco lavoro sicuramente meglio di java, va bene per lavori massimo di 10.000 righe di codice e che non richiedono l’utilizzo di un’intensa interazione con L’os ospite in quanto le prestazioni calano enormemente ogni volta che si interagisce con l’os ospite ossia si accede al file system, al socket, alla porta seriale a meno di non usare uno sviluppo dell’applicazione lineare…comunque sia è meglio di C sharp sicuramente…
    resta il grosso handicap incolmabile che è stato programmato da un OLANDESE che a mio giudizio non hanno mai prodotto niente di buono nella loro storia….questo mi basta per preferire il PERL
    ma è una opinione personale…solo quanti soldi si incassano dalla comunità europea sulle nostre spalle…

    un appunto su amiga, intuition e exec le librerie che gestivano la gui e il multitask erano programmati in B o BCPL che sia e non in assembler…e nella versione 1.2 fino alla 1.3 risiedevano nel kickstart se la memoria non mi inganna…ma in questo potrei sbagliarmi andando indietro di quesi 20 anni..

    il marketing è importante perchè influenza le nostre scelte come è stato fatto con java…e i prodotti microsoft, che visual C professional a parte ha prodotto sistemi di sviluppo penosi…
    e una masnada di utenti ci andavano dietro come lemmings pronti a buttarsi nel fiume…

  • # 58
    Dreadnought
     scrive: 

    Scrivere che C e C++ moriranno è come dire che le Porshe e le Ferrari non venderanno più perchè costano troppo.

    Ci sarà sempre qualcuno che comprerà le Ferrari o le Porshe, così come ci sarà sempre qualcuno che userà il C o il C++ per fare il motore grafico, la libreria particolare e tutto ciò che ha bisogno di prestazioni.

  • # 59
    goldorak
     scrive: 

    @ homero : continuo a rimanere basito difronte alle tue argomentazioni. Per te un linguaggio e’ qualcosa di statico, nasce con certi difetti e se li porta tutta la sua vita. La realta’ e’ talmente lontana dal tuo modo di vedere le cose che farti altri esempi sarebbe soltanto una perdita di tempo, ma ci provo lo stesso. Prendi il Fortran, pensi che il Fortran 77 sia lo stesso linguaggio del Fortran 95 ? Molte cose sono cambiate, tanto che la nuova versione e’ quasi irriconoscibile rispetto a quella del suo illustre progenitore. Idem per Java, un linguaggio che odi. Sono passati 13 anni piu’ o meno da quando e’ apparso Java. Molti dei difetti che erano presenti nelle prime versioni di Java oggi non ci sono piu’.
    Non cito poi il Cobol che ha subito moltissime variazioni negli anni, e le ultime versioni aggiungono caratteristiche object oriented. !!! Ma secondo te e’ lo stesso linguaggio che fu partorito all’inizio degli anni 60.
    La tua tesi e’ che il C/C++ siano la panacea di tutti i mali.
    Che mi dici di Ada allora ? E un linguaggio fortemente tipizzato, cosa che ne’ il C ne’ il C++ sono. Un linguaggio usato per programmare sistemi embedded (perlopiu’ militari) e sistemi di avionica. E un linguaggio molto piu’ rigido del C/C++ ma perche’ deve garantire certe cose che i due linguaggi sopracitato non possono garantire in alcun modo. Non va bene neanche questo eh ?
    Per te prestazioni e’ sinonimo di C/C++. Te lo ripeto e’ una visione errata e molto distorta.
    Tu critichi chi studia Java all’universita’, io critico te che invece mostri di avere una visione a forma di tunnel. Tutto quello che non e’ incentrato sul C/C++ e’ inutile e va sacrificato sull’altare delle pure prestazioni. E la cosa ironica come alcuni ti hanno fatto notare e’ che esitono linguaggi/framework che sono assolutamente competivi con il C/C++ pur aggiungendo tutta una serie di astrazioni linguistiche che non possono mancare in un linguaggio di programmazione del XXI secolo. Programmi che vivivono all’interno di sistemi aperti, non possono piu’ essere sviluppati come si sviluppavano programmi che andavano a girare su un singolo computer in isolamento.

  • # 60
    Giulio
     scrive: 

    @Nessuno: posso scrivere in Java un compilatore che traduce da Java ad Assembly? Posso scrivere un assemblatore in Java?

    Ovviamente si.

    @homero: ribadisco ancora una volta ->

    C#
    Inferenza dei tipi
    Delegati
    Partial Classes
    LINQ
    Extends

    Più tutta la libreria .NET che è immensa e ben documentata, senza contare il fatto che si hanno a disposizione ottime classi per l’accesso a funzioni di Windows di più basso livello.

    Sulla sintassi si può discutere, SONO GUSTI, ma a C# non è inferiore a nessun altro linguaggio su VM con compilatore JIT.

  • # 61
    Nessuno
     scrive: 

    In verità come detto in C e C++ sono scritti tutti i compilatori e le VM degli altri linguaggi. Questo perché i linguaggi interpretati, e quindi limitati all’interno di una VM/sandbox che li isola dall’HW circostante, non possono farlo. Per cui si può parlare di morte di questi linguaggi solo es esclusivamente nel momento in cui ne compare uno sul mercato che è altrettanto potente e non limitato.

    I linguaggi di alto livello sono usabili solo per scrivere programmi di alto livello appunto.

    @Homero
    Mi dispiace deluderti, ma tutto il kernel dell’Amiga OS è stato scritto in puro ASM 68000 da Carl Sassenrath (autore del linguaggio Rebol) tranne la parte che ti ha detto Cesare, cioè la parte DOS che era stata aggiunta come parte non sviluppata internamente.
    Il fatto che fosse stato scritto tutto in ASM ha portato a degli indubbi vantaggi di prestazione e ottimizzazione su un HW tanto piccolo ma purtroppo ha mostrato il fianco debole quando si è trattato di riconvertire il tutto per il PPC. Infatti non è stato portato. Se ci fosse stato un sorgente in un qualsiasi linguaggio compilabile, tutti i problemi che sono occorsi negli anni non sarebbero mai esistiti.

    La differenza tra la parte kernel scritta ad hoc per il 68000 e la parte DOS la vedi chiaramente nelle chiamate di questa ultima libreria dove i puntatori sono di tipo BCPL invece che i canonici puntatori che trovi nel kernel.

  • # 62
    Nessuno
     scrive: 

    “@Nessuno: posso scrivere in Java un compilatore che traduce da Java ad Assembly? Posso scrivere un assemblatore in Java?”
    Certo che puoi. Più o meno, perché per far andare il tuo codice Java in forma nativa ti devi portare dietro il framework (chi ti fa il GC per esempio?). Per elaborare dati, codice e testo anche Java è ok. Quello che intendo, e probabilmente mi sono espresso male in precedenza, è che non puoi fare il contrario, cioè, non posso portare un codice C/C+ in Java liberamente. Come risolveresti un accesso ad una locazione assoluta in memoria? Inoltre non puoi scrivere un interprete di un linguaggio “generico” in Java. L’interprete sarebbe eseguito all’interno della JVM e quindi erediterebbe le stesse identiche limitazioni. Per esempio, non puoi scrivere una Java VM in Java (tautologia) perchè Java non può auto compilare il proprio ambiente, diversamente da C/C++.
    L’equipotenza del linguaggio come vedi è finta, nel senso che sulla carta le funzionalità sono le medesime, ma in realtà non è così per via dell’ambiente in cui questi linguaggi operano.

  • # 63
    Max
     scrive: 

    Non vedo nulla di eclatante in quello che ho detto sull’hello world da 1 Mb, lo spreco di risorse non lo si deve considerare a livello assoluto rispetto a cosa si fa, ma anche rispetto alle risorse disponibili. Preoccuparsi oggi di un hello world da 1 Mb sarebbe come preoccuparsi del fatto che quando mangiamo qualche briciola ci cade per terra, perchè non lo facciamo? Perchè abbiamo cibo in abbondanza, se avessimo la fame più nera leccheremmo anche le briciole sul pavimento, ma perchè farlo se non ne abbiamo bisogno? E’ chiaro che si possono fare hello word che occupano uno spazio infinitamente minore, ma a beneficio di chi? E per quale ragione se uno conosce bene un linguaggio deve perdere tempo ad impararne un altro al solo scopo di ridurre un po’ le dimensioni dell’eseguibile e aumentarne l’efficienza del 10%, in modo che invece che in 10 millesimi di secondo venga eseguito in 9? E poi lo sai che in quel Mb c’è solo il framework, e che se scrivi un programma leggermente più complesso sarà sempre poco più di un Mb perchè praticamente è come se per quanto riguarda le dimensioni dell’eseguibile tu partissi con l’handicap, e quindi qualunque programma minimo ti tiene 1 Mb. Che cosa c’è di così sacrilego in qualche Mb in più, anche considerando tutte le ore in meno di programmazione che la presenza del framework ti fa risparmiare? Non è che tutti i programmi debbano essere per forza degli esercizi stilistici e di eleganza, a parte il fatto che l’esistenza e le dimensioni del framework non sono ineleganti in sé, ma solo agli occhi di chi li paragona con programmi ottimizzati in c che occupano meno spazio e risorse, ma come non si può criticare il java per come è stato implementato all’inizio e per quanto fosse lento su un pentium 90 non si può dire che il c oggi è migliore del c# perchè ti fa risparmiare 10 Mb di spazio sull’hard disk o di ram, se fossimo ancora a 20 anni fa avrebbe un senso ma oggi non più.
    Certo che sapere come si gestiscono i puntatori in c e gli oggetti in c++ aiuta a capire in generale come funziona un computer e come è meglio strutturare un programma, ma anche senza essere esperto di questo il programmatore in java o c# può studiarsi come funziona il garbage collector in modo da strutturare i suoi programmi al meglio.
    Io dico chiaramente ed esplicitamente che non è assolutamente necessario studiare all’università, e che chi lo fa (soprattutto in Italia), è spesso ignorante e illuso perchè finisce per imparare cose che all’atto pratico sono inutili perchè puramente teoriche, o che dopo i 3 o 4 anni di università saranno in gran parte già obsolete. L’importante nella programmazione è sapere fare le cose, il primo requisito di un programma è che risolva il problema per cui è stato creato senza fare mai errori, il secondo è che per farlo occupi un tempo e una quantità di risorse congrue alla complessità del problema e alla piattaforma su cui deve girare il programma. Chi esce dall’università in genere non ha mai risolto problemi, ha solo passato esami, e se anche ha passato esami di programmazione non significa che abbia continuato a programmare tutti i giorni per anni, solo che per alcuni mesi si è studiato la sintassi del c o del java, che cosa è un loop, che cosa sono gli oggetti, o argomenti un poco più complessi; ma poi come succede sempre se una volta dato l’esame non riapri più i libri, e nel caso della programmazione non programmi più niente, perchè devi dare altri esami che non c’entrano nulla, ti dimenticherai tutto o quasi tutto quello che hai imparato. A una azienda non gliene frega niente se hai una laurea, gli importa che tu sappia fare il tuo lavoro.
    Il programmatore vero, come lo scrittore vero, non lo è perchè conosce alla perfezione le minuzie del linguaggio più complicato che ci sia, basta pensare a D’Annunzio, che nel ventesimo secolo era quello che conosceva e sapeva usare meglio l’Italiano, oggi tutti i suoi libri sono illeggibili e a scuola si legge solo la pioggia nel pineto; Guareschi invece diceva di avere un vocabolario di solo 200 parole, eppure i suoi racconti su Don Camillo sono stati tradotti in tutto il mondo. Sono le idee che contano, non il linguaggio, ed avere un linguaggio più semplice permette a tutti quelli che hanno delle buone idee di esprimerle (certo in questo modo anche chi ha delle idee idiote le può esprimere, ma è il prezzo da pagare), se oggi per pubblicare un libro lo si dovesse scrivere solo in latino, come accadeva nel medioevo, quasi nessuno sarebbe in grado di farlo, certo chi lo facesse avrebbe di certo una buona cultura quindi la qualità media dei libri migliorerebbe rispetto a quella attuale, ma ci sarebbe solo qualche decina di libri tra cui scegliere ogni anno.
    I soldi si fanno con le idee, non con approfondite conoscenze tecniche e neanche con le lauree, basta vedere gli imprenditori, soprattutto quelli che c’erano fino a 20-30 anni fa, che erano tutti dei caproni semianalfabeti ma pieni di soldi. Le conoscenze tecniche o le lauree le puoi acquisire tranquillamente, ma devi farlo per il tuo piacere personale, perchè ti piace quello che stai imparando, non pensando che quando sarai esperto per il solo fatto di essere esperto sicuramente ti si apriranno chissà quali porte, e ancor meno pretendendo che queste porte si aprano a te e non a chi ha studiato da autodidatta.
    Certo che non si può paragonare un programma in php con uno per la gestione dello shuttle, ma allo stesso modo non puoi paragonare uno che guida la macchina con un pilota di formula 1, eppure tutti e due guidano una macchina e non si può dire che se non sai correre in formula 1 non sai guidare una macchina veramente. Si può al massimo dire che i più grandi esperti di programmazione devono essere in grado di andare oltre i linguaggi di alto livello, ma questo non significa che tutti quelli che non lo fanno non siano programmatori, sarebbe come dire che se vuoi dipingere o lo fai come Leonardo o Raffaello o non puoi neanche osare definirti un pittore. Con linguaggi come java, c# e python si possono fare tantissime cose, quasi tutto, e in maniera più semplice e veloce che col c (e quindi anche economicamente sono più vantaggiosi), quindi non è che chi li usa non sia un programmatore, non sappia lavorare o sia per forza un dilettante. Ormai oggi non esistono più linguaggi come il basic, tutti sono notevolmente complessi e completi e ti consentono di fare più o meno tutto, i limiti non sono più nei programmi né nell’hardware ma solo nella mente dei programmatori, e credo che il focalizzarsi sulla ottimizzazione assoluta sia un grosso difetto, ed il rifiutare in toto i nuovi linguaggi è sicuramente una scelta sbagliata dal punto di vista lavorativo ed economico perchè ti precludi strumenti di lavoro più efficienti in certi ambiti, ed opportunità di lavoro in varie nicchie che richiedono linguaggi specifici (come la programmazione web, dove non puoi usare il c).

  • # 64
    homero
     scrive: 

    @goldorak

    ho programmato anche in fortran77 mentre il fortran95 benchè conosca le specifiche e le evoluzioni a grandi linee, non ho mai programmato…
    con il fortran si potevano gestire tipi di oggetti che potevano non avere una diretta implementazione hardware..
    ossia interi e reali con elevato numero di cifre di precisione, questo perchè prima esistevano le cpu e i coprocessori matematici…questi potevano essere estremamente diversi come implementazione pertanto le tipologie di dati in particolare numerici erano implementatati in codice macchine e risolti dal compilatore. se ci pensate era un bella rivoluzione visto che tu potevi gestire interi a 32 bit su computer a 8 bit…inoltre questa caratteristica è stata estesa anche nel link a funzioni esterne….infatti il fortran poteva gestire funzioni esterne compilate in codice oggetto che magari permettevano di ricevere dati direttamente da strumenti di misura….questa era la peculiarità del fortran rispetto agli altri linguaggi…ovviamente avendo una gestione statica della memoria e non avendo alcuna funzione per lo sviluppo di algoritmi parallelli è stato progressivamente sostituito da altri linguaggi, anche se le moderne librerie vendute con gli attuali compilatori ne tengono viva l’efficenza in ambito scientifico…anche in questo caso l’implementazione ansi ne garantisce una sicura affidabilità..
    per quanto riguarda ADA è una evoluzione del PASCAL esiste un buon ADA2C ma non so nulla di piu’ ad ogni modo l’ADA2C ansi funziona che è una meraviglia e basta utilizzatere i gnu compiler per accorgerse…
    Io non dico che il C è la panacea di tutti i mali, io dico che il C è il miglior linguaggio inventato e canonizzato ad oggi perchè permette ed ha permesso di realizzare la maggior parte dei software che utilizziamo compreso il browser su cui sto scrivendo… java invece è frutto di un marketing industriale che ha tradito tutte le promesse fatte prima di ogni altra il motto SUN “compile once, run everywhere” tra l’altro messo anche sotto copyright…
    “Per te prestazioni e’ sinonimo di C/C++” questo è falso dico che è dimostrato dai fatti che il C è stato un linguaggio scalabile da sistemi di poche gentinaia di kb a sistemi con diversi Gbyte…ossia non ti ha lasciato a piedi se decidi di gestire software da 100.000 righe di codice…

    @giulio

    mi sembra di parlare al vento…
    allora una cosa è avere una semantica che permette di facilitare la programmazione un’altra è avere un’implementazione che ti garantisca una efficenza nella compilazione…
    allora la programmazione ad oggetti è stata concepita per riutilizzare il codice scritto anche in futuro e per suddividere le parti di codice di un programma in elementi che potevano interaggire tra loro mediante una interfaccia canonizzata dal compilatore….
    tutto questo perchè alcune funzioni in C spesso necessitavano per essere riutilizzate in implementazioni successive di conoscerne bene la struttura o spesso i programmatori si creavano delle interfaccie software per conto loro… con le classi questo veniva risolto da una interfaccia canonizzata dal compilatore…
    in questo modo tu potevi riutilizzare il codice in software successivi anche a distanza di 20 anni ed inoltre gestire dati e funzioni in una quantità di gran lunga superiore. Volgarmente si diceva che il C++ era fatto per lo sviluppo di software estremamente ampi mentre il C andava bene per software piu’ piccoli…
    allora C sharp ha la semantica gli manca tutto il resto…perchè microsoft è maestra nel sbatterti in faccia l’apperenza e celare la magra sostanza…è un po’ come quelle automobili americane che hanno una carrozzeria enorme e poi sotto hanno un motore con pochi cv e che consuma uno sproposito, questo è C sharp sembra C ma non è C, sembra java ma non è java, è puro marketing…ho portato l’esempio del visual basic 6.0 in cui il codice scritto negli anni passati è stato buttato nel cesso…
    io ad oggi ho buttato nel cesso soltanto listati di cui ho dovuto cambiare l’algoritmo perchè il codice che ho scritto in C l’ho sempre potuto riutilizzare e scusate se è poco…

    io ricordavo che intuition e exec erano scitte in B ma forse mi sbaglio non ho voglia di riaccendere l’amiga 2000 che ho su in soffitta e controllare..

    con gjc puoi compilare java direttamente in codice oggetto…peccato che la maggior parte dei listati che trovi in giro non vengono compilati e necessitano di manutenzione

  • # 65
    Cesare Di Mauro (Autore del post)
     scrive: 

    Fornisco qualche risposta a precisi punti, mentre per gli altri mi allineo alle risposte già fornite.

    @Nessuno:

    Non quoto perché non è comodo in questo blog

    Questo mi spiace. Al mio rientro dalle ferie lo farò presente agli amministratori.

    non mi è stata mostrata nessuna prova che con Java (e relativa JVM) sia possibile accedere all’HW per scrivere un driver.

    L’errore che commetti sta nell’identificare Java con la sua implementazione mainstream attuale, che fa uso della JVM, appunto.

    Ciò detto, anche con la stessa JVM si potrebbe benissimo realizzare un driver. Basterebbe scrivere una libreria per gestire la parte di basso livello, e usare le JNI per interfacciarvisi.

    che ogni linguaggio si adatta meglio o peggio secondo il problema che deve risolvere e l’ambiente in cui deve operare.

    Il fatto più ovvio di questa cosa è che i vari compilatori/interpreti per i vari linguaggi moderno, non siano scritti con i linguaggi stessi o altri linguaggi moderni, ma in C/C++ se non in Assembly quando possibile. Nessuno farebbe un compilatore C in LISP. O in Python. O in Rebol.
    La VM Java non è scritta in Java. Perché? Perché semplicemente l’ambiente in cui opera il linguaggio Java non è adatto a fare certe cose (e anzi è di impedimento). Ovviamente si adatta perfettamente ad altre.
    Quello che intendo dire è che tutti i linguaggi interpretati sono limitati nella loro potenzialità dall’ambiente stesso (l’interprete) in cui devono operare, mentre i linguaggi di “basso livello” come il C/C++ (ovviamente non solo, ma sono i più diffusi) sono gli unici che permettono di superare qualsiasi problema e quindi di fare da base per tutti gli altri.

    Ti faccio notare che per molti linguaggi di programmazione il classico esercizio di stile consiste nello scrivere il compilatore del linguaggio nel linguaggio stesso.

    Andando oltre il puro esercizio, ti segnalo il progetto PyPy che fa uso di RPython, un sottoinsieme ristretto di Python, per generare virtual machine per qualunque linguaggio (ovviamente al momento è stata scritta soltanto la grammatica per Python), ed è dotato di compilatore JIT (attualmente è stabile la versione x86, mentre stanno lavorando per quella AMD64).

    Faccio presente che PyPy è il candidato numero uno a rimpiazzare CPython (che ovviamente è scritto in C), proprio per il fatto che il generatore di VM è scritto interamente in Python (anche se è un sottoinsieme stretto, il linguaggio è quello) e perché finalmente ha prestazioni notevoli (alla scorsa PyCon ha polverizzato CPython sui campi in cui attualmente Python langue: interi e virgola mobile).

    Ritornando alla questione della gestione della memoria, nella mia esperienza ho visto che chi impara a programmare affidandosi al Garbage Collector poi ha serie difficoltà a gestire la memoria in maniera corretta quando lo deve fare a mano usando il proprio cervello per verificare il flusso teorico del codice. E non capisce che dalle funzioni non si può esportare un puntatore ad un array sullo stack. E via di queste cose.
    La questione dei puntatori riportata precedentemente era slegata a quella dell’allocazione di memoria, ma comunque come vedi è possibile congiungere le due cose, perché ovviamente per chi usa il C l’uso di puntatori e gestione della memoria sono la stessa cosa, o due facce della stessa medaglia.

    Potrei dirti che l’uso dei puntatori in C e C++ è un vero inferno, tanto che molti programmatori fanno uso di garbage collector proprio per semplificarsi la vita.

    Tanto per dirtene una, già soltanto stabilire chi è, fra “produttore” e “consumatore”, che deve disallocare la memoria, è un problema non di poco conto (e che influenza anche il design di API e progetto).

    @homero:

    ************************************************************
    E’ una tua opinione che ovviamente non condivido, visto che un linguaggio definisce sintassi e semantica, e null’altro.
    ************************************************************

    questo non te lo concedo manco un po’, vatti a leggere lo standard ansi del C…quello vero non i libri che si trovano in libreria…

    Conosco già da anni il K&R e il draft dell’ISO, grazie.

    poi capisco perchè molti hanno problemi con i puntatori o con la ricorsione delle funzioni…questo proprio non te lo concedo…
    perchè E’ ULTRAFALSO!
    nello standard C è scritto tutto x filo e per segno dove e come allocare le funzioni nello stack,

    Immagino che ti riferisca ai parametri, e non alle funzioni.

    Per caso c’è scritto anche in che ordine vengono valutati i parametri, visto che hai già detto in precedenza che è indispensabile sapere proprio tutti i dettagli, anche di più basso livello?

    come gestire i puntatori alla ram

    Se ti riferisci all’aritmetica dei puntatori, mi sembra ovvio perché fa parte del linguaggio, appunto. Altrimenti non è chiaro di cosa parli.

    Riguardo ai puntatori ti faccio presente che puntatori e interi NON sono la stessa cosa. E già da questa battuta dovresti aver capito molte cose, soprattutto riguardo al rapporto del C con l’hardware che ci sta sotto.

    e al registro indirizzi della cpu….

    Non tutte le CPU hanno registri indirizzi.

    quando svuotare la memoria allocata…

    Questo lo decide il programmatore.

    come gestire il preprocessing gli oggetti volatili,

    Cioé? Non è affatto chiaro.

    dove inserire le variabili globali e quelle esterne questa è l’implementazione….

    No, queste due cose fanno parte del linguaggio e ti faccio presente che altri linguaggi permettono di fare lo stesso. Anzi, si tratta di roba abbastanza comune.

    ma io che parlo a fare….tanto qui non avete neppure letto le prime 50 pagine dello standard C…questo è il dramma di chi frequenta le facolta di informatica di oggi che tutto è fatto alla carlona…

    Premesso che non puoi giudicare le giovani leve senza vederle all’opera, io faccio parte della vecchia guardia, e ho cominciato a programmare ben 28 anni fa. Fatti i conti e puoi immaginare cos’ho passato.

    in python non trovo nulla di male fa il suo sporco lavoro sicuramente meglio di java, va bene per lavori massimo di 10.000 righe di codice

    Al contrario: Python si presta a scalare meglio in termini di manutenibilità del codice.

    Inoltre chiedi a Google, YouTube, Yahoo, quante righe di codice Python hanno scritto per i loro progetti, e vedrai che vanno UN TANTINO oltre le 10mila che hai scritto.

    e che non richiedono l’utilizzo di un’intensa interazione con L’os ospite in quanto le prestazioni calano enormemente ogni volta che si interagisce con l’os ospite ossia si accede al file system, al socket, alla porta seriale a meno di non usare uno sviluppo dell’applicazione lineare…

    Veramente proprio quando si tratta di interagire col s.o., specialmente per operazioni I/O bound, si sente decisamente meno la lentezza di una virtual machine.

    comunque sia è meglio di C sharp sicuramente…

    Hanno ambiti applicativi diversi (anche se in parte sovrapponibili).

    resta il grosso handicap incolmabile che è stato programmato da un OLANDESE che a mio giudizio non hanno mai prodotto niente di buono nella loro storia….

    Questo di tecnico non ha proprio nulla, per cui è un giudizio che lascia il tempo che trova.

    questo mi basta per preferire il PERL
    ma è una opinione personale…

    Perl è rumore bianco eseguibile. Python è pseudocodice eseguibile. Tanto basta per discriminare fra i due, e difatti Perl continua a perdere quote di mercato.

    solo quanti soldi si incassano dalla comunità europea sulle nostre spalle…

    Cioé?

    un appunto su amiga, intuition e exec le librerie che gestivano la gui e il multitask erano programmati in B o BCPL che sia e non in assembler…

    Erano tutti in assembly. Fattelo dire da uno che sull’Amiga non ha passato la maggior parte del tempo incollato al joystick.

    e nella versione 1.2 fino alla 1.3 risiedevano nel kickstart se la memoria non mi inganna…

    Sono rimaste in ROM anche dopo.

    ma in questo potrei sbagliarmi andando indietro di quesi 20 anni..

    Io continuo a serbare un ottimo ricordo. Non ti chiedo di fidarti, ma se fai una rapida ricerca vedrai che troverai ampii riscontro a quanto ho detto finora sull’argomento.

    il marketing è importante perchè influenza le nostre scelte come è stato fatto con java…e i prodotti microsoft, che visual C professional a parte ha prodotto sistemi di sviluppo penosi…

    Opinabilissimo.

    e una masnada di utenti ci andavano dietro come lemmings pronti a buttarsi nel fiume…

    Questo, come già detto, succede anche con altri linguaggi, C e C++ inclusi.

    @Nessuno:

    In verità come detto in C e C++ sono scritti tutti i compilatori e le VM degli altri linguaggi. Questo perché i linguaggi interpretati, e quindi limitati all’interno di una VM/sandbox che li isola dall’HW circostante, non possono farlo. Per cui si può parlare di morte di questi linguaggi solo es esclusivamente nel momento in cui ne compare uno sul mercato che è altrettanto potente e non limitato.

    I linguaggi di alto livello sono usabili solo per scrivere programmi di alto livello appunto.

    Veramente ho scritto compilatori (per linguaggi semplici, a uso aziendale) interamente in Python, e non vedo alcuna difficoltà nel realizzare qualcosa di più complesso, come potrebbe benissimo essere un compilatore C che emette o assembly (come fanno tanti compilatori C moderni) o direttamente codice macchina.

    Per me si tratta di puro esercizio di stile.

    “@Nessuno: posso scrivere in Java un compilatore che traduce da Java ad Assembly? Posso scrivere un assemblatore in Java?”
    Certo che puoi. Più o meno, perché per far andare il tuo codice Java in forma nativa ti devi portare dietro il framework (chi ti fa il GC per esempio?).

    Il GC non è vincolante allo scopo. E nessuno t’impedisce di realizzare una JVM che ti permette di controllare il GC, come ad esempio si fa in Python (posso decidere di sospendere, ripristinare, o forzarne l’esecuzione in maniera programmatica).

    Poi non ti devi portare dietro l’intero framework, come non ti è necessario in C includere e/o usare tutta la libreria standard.

    Quello che intendo, e probabilmente mi sono espresso male in precedenza, è che non puoi fare il contrario, cioè, non posso portare un codice C/C+ in Java liberamente. Come risolveresti un accesso ad una locazione assoluta in memoria?

    Non puoi accedere arbitrariamente a qualunque locazione di memoria in C/C++.

    Se ciò ti viene concesso, è grazie alle IMPLEMENTAZIONI dei compilatori, per facilitare la vita ai programmatori di sistema.

    Tanto per essere chiari, potrei benissimo realizzare un compilatore che castando da intero a puntatore ritorni il valore NULL, e viceversa da puntatore a intero ritorni 0 (o un qualunque valore arbitrario). E il linguaggio continuerebbe a fregiarsi d’essere perfettamente compliant con lo standard.

    Inoltre non puoi scrivere un interprete di un linguaggio “generico” in Java. L’interprete sarebbe eseguito all’interno della JVM e quindi erediterebbe le stesse identiche limitazioni.
    Per esempio, non puoi scrivere una Java VM in Java (tautologia) perchè Java non può auto compilare il proprio ambiente, diversamente da C/C++.

    Non vedo il perché. L’importante è che venga rispettata sintassi e semantica del linguaggio eseguito dentro della JVM.

    Anche qui, per essere chiari, esistono INTERPRETI C / C++. Con tutti i loro limiti. Eppure il linguaggio è quello…

    L’equipotenza del linguaggio come vedi è finta, nel senso che sulla carta le funzionalità sono le medesime, ma in realtà non è così per via dell’ambiente in cui questi linguaggi operano.

    D’accordo, ma vale per tutti i linguaggi. Anche Java, nell’ambiente giusto, può essere usato per scrivere codice di basso livello. Tant’è che esistono s.o. scritti in Java.

    @homero:

    per quanto riguarda ADA è una evoluzione del PASCAL

    No, è di ispirazione Pascal.

    “Per te prestazioni e’ sinonimo di C/C++” questo è falso dico che è dimostrato dai fatti che il C è stato un linguaggio scalabile da sistemi di poche gentinaia di kb a sistemi con diversi Gbyte…ossia non ti ha lasciato a piedi se decidi di gestire software da 100.000 righe di codice…

    Non auguro a nessuno di dover gestire progetti di 100mila righe di codice in C…

    allora la programmazione ad oggetti è stata concepita per riutilizzare il codice scritto anche in futuro e per suddividere le parti di codice di un programma in elementi che potevano interaggire tra loro mediante una interfaccia canonizzata dal compilatore….
    tutto questo perchè alcune funzioni in C spesso necessitavano per essere riutilizzate in implementazioni successive di conoscerne bene la struttura o spesso i programmatori si creavano delle interfaccie software per conto loro… con le classi questo veniva risolto da una interfaccia canonizzata dal compilatore…
    in questo modo tu potevi riutilizzare il codice in software successivi anche a distanza di 20 anni ed inoltre gestire dati e funzioni in una quantità di gran lunga superiore. Volgarmente si diceva che il C++ era fatto per lo sviluppo di software estremamente ampi mentre il C andava bene per software piu’ piccoli…

    Ma non ci siamo proprio. La programmazione a oggetti è nata per ben altro. Vedi linguaggio Simula, appunto, ma se prendi anche il più noto SmallTalk vedrai che la motivazione non è l’incapsulamento di codice e dati, e la riusabilità.

    La modellazione di un progetto sfruttando la prospettiva a oggetti è qualcosa di molto diverso.

    Ti consiglio di leggere qualche scritto di Alan Key, che in materia è illuminante.

    allora C sharp ha la semantica gli manca tutto il resto…perchè microsoft è maestra nel sbatterti in faccia l’apperenza e celare la magra sostanza…è un po’ come quelle automobili americane che hanno una carrozzeria enorme e poi sotto hanno un motore con pochi cv e che consuma uno sproposito, questo è C sharp sembra C ma non è C, sembra java ma non è java, è puro marketing…

    Se fosse solo questo non si realizzerebbero progetti, e non si farebbero soldi a palate.

    C# è immensamente più robusto di C e C++. Di gran lunga preferibile, a parità di requisiti da rispettare.

    ho portato l’esempio del visual basic 6.0 in cui il codice scritto negli anni passati è stato buttato nel cesso…
    io ad oggi ho buttato nel cesso soltanto listati di cui ho dovuto cambiare l’algoritmo perchè il codice che ho scritto in C l’ho sempre potuto riutilizzare e scusate se è poco…

    Bella storia: VB 6 è sostanzialmente morta come piattaforma.

    Ma questo nulla dice sulla qualità del codice scritto con quest’ambiente.

    o ricordavo che intuition e exec erano scitte in B ma forse mi sbaglio non ho voglia di riaccendere l’amiga 2000 che ho su in soffitta e controllare..

    In B non è stato mai scritto nulla su Amiga. Al più è stato il BCPL, ma esclusivamente per AmigaDOS.

    Tolto ciò, una persona sana di mente non avrebbe mai usato quell’obbrobrio.

    con gjc puoi compilare java direttamente in codice oggetto…peccato che la maggior parte dei listati che trovi in giro non vengono compilati e necessitano di manutenzione

    Non è ancora perfetto, e ci stanno lavorando.

    Ma quel che conta sono le potenzialità. Quello che è in grado di fare. E non mi pare abbia nulla da far rimpiangere a C e C++, da questo punto di vista.

  • # 66
    goldorak
     scrive: 

    Per ritornare in tema, vorrei farvi leggere questo documento : http://www.oracle.com/technetwork/database/berkeleydb/bdb-je-android-160932.pdf scritto da Oracle a inizio 2010 e di cui cito un estratto alquanto interessante :

    “Recently, Oracle certified JE on the Android platform for devices like the Motorola Droid and HTC Eris smartphones. Android breaks new ground in the device category because it is a Java 2 Standard Edition (J2SE) platform, whereas the previous generations of Java-based devices are predominantly Java Micro Edition (Java ME) based. There are significant differences between J2SE and Java ME in terms richness of libraries and APIs and this creates a big opportunity for improved application capabilities. Most notable are the full-featured
    Java 5 language support, libraries like java.util.* and
    collections, and full multi-threaded support built on the Android Linux kernel. ”

    E poi dicono che le aziende agiscono razionalmente. Se Android andava contro le idee di Oracle perche’ a inizio 2010 non fecero causa, invece certificarano senza alcun problema uno dei loro prodotti per essere usato su Android. Riconoscendo tra l’altra la piena superiorita’ di Android sulla JavaME.

  • # 67
    homero
     scrive: 

    ultima cosa è poi chiudo questa discussione almeno per quanto mi riguarda poi ognuno puo’ investire il suo tempo nel linguaggio che crede migliore per le sue esigenze…
    “come gestire il preprocessing gli oggetti volatili,

    Cioé? Non è affatto chiaro.”

    è scritto nell’ ansi iso iec 9899-1999..
    credo che sono sulle 500 pagine ma c’è scritto tutto anche se in maniera stringata e senza esempi in quanto essendo uno standard internazionale deve essere imparziale nella forma ossia non favorire un’industria piuttosto che un altra…ma le direttive basilari ci sono tutte…ma sono stati pubblicati diversi documenti collaterali che chiariscono il resto…

    visual basic è morto come lo sarà C sharp perchè è cosi’ che funziona per microsoft..
    ma non voglio aspettare 10 anni per avere ragione quindi chi butta il suo tempo in C sharp faccia pure…

    il fatto che perl sia rumore bianco credo che sia alquanto sottomistato
    ad ogni modo i linguaggi interpretati come perl, python e ruby sono equivalenti…poi ovviamente dipende dalle implentazioni dei vari interpreti dare un piccolo vantaggio all’uno o all’altro….ma non ci vedo proprio un software in python da 100.000 righe di codice…
    in C++ ce ne sono moltissimi e nessuno si lamenta anzi….

    se intuition ed exec sono scritti in assembler e funzionavano bene…meglio riprendere a programmare in assembler…codice stringato ed efficente…altro che windows con le sue dll del piffero…o android…

    avete mai pensato di inserire queste librerie nei telefonini?
    e qui un bel consiglio a cdmauro…
    fossi lui invece di perdere tempo con python mi impegnerei a clonare le librerie dell’amiga per sistemi soc o embedded…ma questa è una mia opinione spassionata….in fondo se bastano 512kb di ram per un os come quello dell’amiga altro che android o IOS, e non cominciare a propormi aros che sono andato a vedere e non ha nulla che vedere con l’amiga…
    intendo qualcosa di piu’ snello e diretto…

    alla prossima!

  • # 68
    skynet
     scrive: 

    Salve, non capisco come possiate dire che java fa schifo, sicuramente no è il massimo ma permette di scrivere un software che poi può essere eseguito su qualsiasi macchina.
    Sono un ingegnere informatico e lavoro per la neonata BETAtechnologies, sviluppiamo software per professionisti (medici, dentisti, oculisti, avvocati, rappresentanti ecc ecc) che si appoggiano a dei database mysql, siccome non tutti usano windows, ma molti ci chiedono software per mac e linux (e non se ne trovano molti) l’unico modo per non dover riscrivere da zero lo stesso software è usare java. Una volta scritto il codice, si compila e si crea un jar che potrà essere eseguito su windows, linux, mac os-x, sia a 32 che a 64 biti senza alcuna ulteriore modifica.
    Non dimentichiamoci inoltre che java E’ il linguaggio a programmazione ad oggetti per eccellenza, si può programmare SOLO ad oggetti, una volta che si apprende il java (se te lo spiega uno che veramente ci sa programmare è molto facile) poi saprai programmare con qualsiasi linguaggio di alto livello.

  • # 69
    Cesare Di Mauro (Autore del post)
     scrive: 

    @goldorak: appunto. E la scelta del titolo per quest’articolo non è certo casuale. ;)

    @homero:

    “come gestire il preprocessing gli oggetti volatili,

    Cioé? Non è affatto chiaro.”

    è scritto nell’ ansi iso iec 9899-1999..
    credo che sono sulle 500 pagine ma c’è scritto tutto anche se in maniera stringata e senza esempi in quanto essendo uno standard internazionale deve essere imparziale nella forma ossia non favorire un’industria piuttosto che un altra…ma le direttive basilari ci sono tutte…ma sono stati pubblicati diversi documenti collaterali che chiariscono il resto…

    Il concetto di dato volatile (e della relativa keyword) mi è chiaro. Quel che continua a non essermi chiaro è ciò che tu indevi con quella frase che hai scritto prima.

    Per il resto noto che continui a glissare su tutti i punti che ti ho contestato.

    visual basic è morto come lo sarà C sharp perchè è cosi’ che funziona per microsoft..
    ma non voglio aspettare 10 anni per avere ragione quindi chi butta il suo tempo in C sharp faccia pure…

    C# durerà molto più a lungo. Anche perché continua a innovarsi a ritmi insostenibili per gli altri linguaggi che, come dicevo prima, lo rincorrono.

    il fatto che perl sia rumore bianco credo che sia alquanto sottomistato

    Non credo proprio. Il codice Perl tende all’illegibilità, tanto che un motto che circola nell’ambiente è che dopo 6 mesi nemmeno lo stesso programmatore è in grado di capire quello che ha scritto.

    ad ogni modo i linguaggi interpretati come perl, python e ruby sono equivalenti…poi ovviamente dipende dalle implentazioni dei vari interpreti dare un piccolo vantaggio all’uno o all’altro….

    Python non è interpretato: è compilato in bytecode ed esistono soluzioni JIT-ed. Anche per Ruby la situazione è simile.

    L’unico che langue, e di cui aspetta da anni la famigerata versione 6, è Perl, che attualmente viene principalmente relegato allo scripting di sistema alternativo alla bash, oppure a script per la massiccia manipolazione di espressioni regolari.

    ma non ci vedo proprio un software in python da 100.000 righe di codice…

    Penso che le multinazionali che ho citato prima superino agevolmente questa cifra.

    Python è un linguaggio che estremamente manutenibile e, come dicevo prima, consente di scalare meglio all’aumentare della complessità di un progetto. Al contrario di linguaggi come C e C++.

    Altro fattore importante, è un linguaggio che oltre alla chiarezza ha il dono della sintesi, per cui una riga di codice Python spesso permette di fare molto più lavoro rispetto ad altri linguaggi, che richiedono più righe.

    in C++ ce ne sono moltissimi e nessuno si lamenta anzi….

    Prova a cercare “FireFox memory leaks”.

    se intuition ed exec sono scritti in assembler e funzionavano bene…meglio riprendere a programmare in assembler…codice stringato ed efficente…altro che windows con le sue dll del piffero…o android…

    Non puoi più farlo perché il codice è notevolmente più complesso.

    avete mai pensato di inserire queste librerie nei telefonini?
    e qui un bel consiglio a cdmauro…
    fossi lui invece di perdere tempo con python mi impegnerei a clonare le librerie dell’amiga per sistemi soc o embedded…ma questa è una mia opinione spassionata….in fondo se bastano 512kb di ram per un os come quello dell’amiga altro che android o IOS, e non cominciare a propormi aros che sono andato a vedere e non ha nulla che vedere con l’amiga…
    intendo qualcosa di piu’ snello e diretto…

    AROS lo trovo un ottimo sostituto / erede di AmigaOS. Tra l’altro l’obiettivo è quello di rimpiazzarlo anche negli originali Amiga, e già questo dovrebbe farti riflettere.

    Comunque prima o poi (spero più prima che poi) ne parlerò su queste pagine. Stay tuned. ;)

    @skynet:

    Salve, non capisco come possiate dire che java fa schifo

    Spero che almeno sui gusti non si discuta. :)

    Non dimentichiamoci inoltre che java E’ il linguaggio a programmazione ad oggetti per eccellenza

    E SmallTalk dove lo mettiamo? :P

    si può programmare SOLO ad oggetti,

    Oddio, nessun m’impedisce di realizzare un programma col solo main static dell’unica classe. O robe simili.

    una volta che si apprende il java (se te lo spiega uno che veramente ci sa programmare è molto facile) poi saprai programmare con qualsiasi linguaggio di alto livello.

    Questo vale anche per altri linguaggi, ma comunque ne esistono di molto più semplici (e produttivi).

    Java ha dato molto alla didattica, ma ormai è tempo di dare spazio a linguaggi migliori (da questo punto di vista).

  • # 70
    shodan
     scrive: 

    @ Cesare di Mauro:
    Innanzitutto ti faccio i complimenti per l’articolo, molto informativo (anche se non la vedo così nera per Java…)

    Riguardo alla segmentazione della memoria, nell’architettura AMD64 è generalmente disabilitata:
    “64-bit mode — Segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address space. Specifically, the processor treats the segment base of CS, DS, ES, and SS as zero in 64-bit mode (this makes a linear
    address equal an effective address). Segmented and real address modes are not available in 64-bit mode.” – FONTE: Intel(R) 64 and IA-32 Architectures Optimization Reference Manual – Vol.1 3-11

    Riguardo alla domanda che ponevi nel commento #39 (reattività di Java + JNI) posso confermati che il sistema è molto veloce: tempo fa ho scritto un semplice benchmark OGL, dapprima in C e poi portato in Java. Le prestazioni (tempo di avvio e consumo di memoria a parte) erano estremamente simili (e non poteva essere altro che così, dato che le JNI richiamavano direttamente le funzioni OGL sottostanti). Se a qualcuno interessa, qui trovate il benchmak: http://www.assyoma.it/index.php/repository?func=fileinfo&id=4

    Ciao. :)

  • # 71
    Cesare Di Mauro (Autore del post)
     scrive: 

    E io ti ringrazio per la conferma che hai fornito alla mia intuizione. :-P

    Riguardo ad AMD64, era a quello che mi riferivo, aggiungendo però il fatto che i segmenti FS e GS continuano, invece, a rimanere operativi per accedere, ad esempio, alle strutture del kernel.

  • # 72
    homero
     scrive: 

    avevo scritto che era l’ultimo intervento ma forse è necessario un piccolo chiarimento

    forse mancava una virgola \il preprocessing, gli oggetti volatili…\ per oggetti volatili intendo ad esempio la ricorsione delle funzioni in C in cui il compilatore deve clonare il pezzo di codice che è interessato dalla ricorsione tante volte quanti sono i cicli, e alla chiusura del ciclo piu’ interno liberare la memoria dello stack di quella funzione…questo è un semplice esempio di quello che intendo quando dico che il compilatore in C è ben canonizzato…oppure che tutti le variabili e le strutture devono essere ricondotte a modelli fondamentali ossia char, int, float, header, l’uso di void che è importantissimo, una funzione che ritorna void è trattata in modo diverso a livello di compilazione…
    la tabella dei puntatori alle funzioni…etc etc etc…insomma, la potenza del C è che hai tutto sotto controllo, almeno chi vuole impegnarsi a controllare tutto…
    questo in C sharp non solo non è presente ma è addirittura disincetivato grazie alla mancanza dei puntatori…
    l’evoluzione cavalcante che tu dici di C sharp è identica a quella della tecnologia activeX di visual basic…c’erano activeX per fare tutto si diceva…era una tecnologia integrata persino in iexplorer….adesso tutti quegli activex sono tutti finiti nel cesso e sono stati buoni solamente per fare software di quart’ordine finito nel dimenticatoio…
    per quanto riguarda il python come linguaggio compilato…il bytecode serve essenzialmente per proteggere i sorgenti e creare software close
    source…le ottimizzazioni sono limitate ed i vantaggi rispetto ad una soluzione interpretata è minimale. per quanto riguarda google e python…quelli di google sono furbi…loro sviluppano sia l’interprete che il linguaggio pertanto quando i programmi scritti in python hanno problemi con l’interprete adattano l’interprete! ed essendo adattamenti interni spesso non vengono divulgati in open source…
    …è inutile dire che il \compilatore\ di python è scritto in C++….ma questo era ovvio….

    ma allora perchè tanti linguaggi di programmazione?
    per dividere i programmatori in fasce…

    abbiamo la fascia che cura l’interprete python e programma in C che è la fascia piu’ ristretta e poi a seguire ci sono quelli che sviluppano le classi tipo la classe socket di python ed in ultimo quelli che scrivono il software in python…
    va da se che se una multinazionale come google abbandona python o crea un interprete che funziona male gli ultimi della serie sono fregati…
    …questo in C standard ansi non puo’ accadere per diverse ragione la prima che lo standard impone le regole con le quali il compilatore deve essere sviluppato…la seconda è che esistono compilatori come gcc e intel C e tanti altri che hanno una base di sviluppo conosciuta dai programmatori e dai consorzi che proteggono il linguaggio..
    avete capito bene i linguaggi di programmazione vanno protetti….

    gli studenti che imparano il C hanno un legame con le strutture di calcolo piu’ \vero\ rispetto a quelli che imparano linguaggi \compilati\ in opcode come java e adesso ho appreso che anche python e ruby hanno seguito la stessa strada….bene sono sempre e comunque linguaggi interpretati e non compilati e come tali bisogna considerarli….
    quei furboni di google gerarchizzano in questo modo i programmatori quindi il linguaggio è utilizzato anche come elemento di suddivisione dei compiti…
    …questa è la vecchia tecnica anglosassone di gerarchizzare il lavoro…
    faccio un esempio:

    se io so fare solo la testa dello spillo e l’operaio nell’altra stanza sa fare solo la punta della spillo, siamo due persone monche…ossia siamo costretti a dipendere dalla fabbrica perchè da soli non sappiamo fare uno spillo completo….

    in italia invece nel medioevo c’erano le cosidette corporazioni di arte e mestieri, nelle quali i bottegai che facevano spilli, conoscevano l’intero processo produttivo e pertanto i garzoni una volta imparato il mestiere erano autonomi e sapevano produrre uno spillo completo…

    in google e in tutti le aziende anglo-style si parcellizzano le competenze in modo da rendere dipendenti dall’azienda gli operai…nel caso specifico i programmatori in python dipendono dai produttori dell’interprete che in questo caso è la stessa aziende che impone di programmare in python…

    alcuni mi diranno ma anche i programmatori in C dipendono dal compilatore in C
    e qui casca l’asino!
    perchè i compilatori in C che ci sono oggi sono stabili efficenti e sopratutto c’e’ un’offerta ampia garantita da 30 anni di sviluppo…
    nel periodo in cui il C è nato la condizione aziendale del software era ancora agli inizi e pertanto il C si è sviluppato al di fuori di queste logiche di mercato…
    pertanto quando scegliete un linguaggio assicuratevi che i vostri strumenti di programmazione siano solidi e chi ve li fornisce non pensi solamente al profitto.. e qui rientra in campo microsoft…
    microsoft ma anche apple non ci ha pensato due volte a buttare a mare quei poverini che hanno spesso milioni di lire in visual basic, activeX, programmi DEVprofessional tipo technet di microsoft e quant’altro…
    analogamente per altri linguaggi fantasma come VJ++ un fantomatico visual java….o per vscript…o per access…i vari ADO e la lista è lunga….
    adesso CDMAURO mi dice che devo fidarmi di microsoft con C sharp!
    ma manco morto! microsoft è capace che tra 3 anni decide di lasciar morire C sharp….cosi’ come oracle decide di far morire JAVA…e tutti quelli che hanno migliaia di righe di codice in java? dovranno adattarle a gjc che pero’ non è uguale alla virtual machine di SUN che si è vista bene negli anni precedenti di dare una mano nella canonizzazione di un compilatore java…
    insomma questo articolo è a favore delle multinazionali da qualunque punto di vista lo si guardi……

    e qui chiudo veramente….

  • # 73
    Cesare Di Mauro (Autore del post)
     scrive: 

    @homero:

    avevo scritto che era l’ultimo intervento ma forse è necessario un piccolo chiarimento

    forse mancava una virgola \il preprocessing, gli oggetti volatili…\ per oggetti volatili intendo ad esempio la ricorsione delle funzioni in C in cui il compilatore deve clonare il pezzo di codice che è interessato dalla ricorsione tante volte quanti sono i cicli, e alla chiusura del ciclo piu’ interno liberare la memoria dello stack di quella funzione…questo è un semplice esempio di quello che intendo quando dico che il compilatore in C è ben canonizzato…

    Ma scusami, è così che funzionano praticamente tutti i linguaggi che consentono la ricorsione. Dov’è la novità col C?

    oppure che tutti le variabili e le strutture devono essere ricondotte a modelli fondamentali ossia char, int, float,

    Di cui però non conosci la reale dimensione e/o range / precisione numerica. Cosa fondamentale per la portabilità che hai sempre vantato prima.

    header, l’uso di void che è importantissimo, una funzione che ritorna void è trattata in modo diverso a livello di compilazione…
    la tabella dei puntatori alle funzioni…etc etc etc…insomma, la potenza del C è che hai tutto sotto controllo, almeno chi vuole impegnarsi a controllare tutto…

    E’ una cosa che succede anche in altri linguaggi.

    Difatti il C non ha portato propria nulla di nuovo nella letteratura informatica, tant’è che veniva deriso come “Pascal mascherato” nei primi anni ’70.

    questo in C sharp non solo non è presente ma è addirittura disincetivato grazie alla mancanza dei puntatori…

    Ma ancora ci torni? NON è così!!! Hai mai preso il draft di questo linguaggio e te lo sei studiato seriamente? Vedrai che, in mezzo a montagna di roba interessante, ci troverai anche… (rullo di tamburi)… i puntatori!

    l’evoluzione cavalcante che tu dici di C sharp è identica a quella della tecnologia activeX di visual basic…c’erano activeX per fare tutto si diceva…era una tecnologia integrata persino in iexplorer….adesso tutti quegli activex sono tutti finiti nel cesso e sono stati buoni solamente per fare software di quart’ordine finito nel dimenticatoio…

    Gli ActiveX sono vivi e vegeti.

    per quanto riguarda il python come linguaggio compilato…il bytecode serve essenzialmente per proteggere i sorgenti e creare software close
    source…

    Assolutamente no. Al contrario, proprio il bytecode utilizzato in Python consente di risalire quasi al codice originale, con un buon decompilatore (ma anche disassemblando il bytecode, risulta evidente; dai un’occhiata alle mie slide su WPython).

    le ottimizzazioni sono limitate

    No, guarda, ti stai muovendo in un terreno minato. Non hai idea di quante ottimizzazioni sia possibile realizzare, senza ricorrere a un compilatore JIT; ho giusto davanti il codice (ovviamente in C) di Python 3.2 alpha1, e già mi frullano per la testa idea su come ottimizzarlo.

    Idee che sono le ultime di una lunga serie, te l’assicuro.

    ed i vantaggi rispetto ad una soluzione interpretata è minimale.

    Proprio l’introduzione del bytecode è la dimostrazione dell’esatto contrario.

    E’ una strada che ha intrapreso Ruby con l’ultima versione, la 1.9, che è basata su bytecode compilato e non sull’interpretazione dell’AST delle precedenti versioni, e i benefici sono netti e tangibilissimi. Se fai una rapida ricerca lo vedrai subito.

    per quanto riguarda google e python…quelli di google sono furbi…loro sviluppano sia l’interprete che il linguaggio pertanto quando i programmi scritti in python hanno problemi con l’interprete adattano l’interprete! ed essendo adattamenti interni spesso non vengono divulgati in open source…

    Sei totalmente fuori strada. Python è nato parecchi anni prima che Google fosse fondata, e pur essendo usatissimo da questa multinazionale, il numero di programmatori Google che vi contribuisce è una piccola frazione: il grosso rimane gente appassionata.

    …è inutile dire che il \compilatore\ di python è scritto in C++….ma questo era ovvio….

    Assolutamente no. Di Python esistono numerose implementazioni ormai (questo per rimarcare il fatto che il linguaggio NON può e non dev’essere identificato da quella più diffusa), fra cui CPython che è quella “mainstream” e realizzato in C e non in C++.

    Ma è un’implementazione, appunto. A farle seria concorrenza è PyPy che… è scritto in RPython, come dicevo prima.

    ma allora perchè tanti linguaggi di programmazione?
    per dividere i programmatori in fasce…

    abbiamo la fascia che cura l’interprete python e programma in C che è la fascia piu’ ristretta e poi a seguire ci sono quelli che sviluppano le classi tipo la classe socket di python ed in ultimo quelli che scrivono il software in python…
    va da se che se una multinazionale come google abbandona python o crea un interprete che funziona male gli ultimi della serie sono fregati…
    …questo in C standard ansi non puo’ accadere per diverse ragione la prima che lo standard impone le regole con le quali il compilatore deve essere sviluppato…la seconda è che esistono compilatori come gcc e intel C e tanti altri che hanno una base di sviluppo conosciuta dai programmatori e dai consorzi che proteggono il linguaggio..
    avete capito bene i linguaggi di programmazione vanno protetti….

    Non conosci la situazione, come ho già detto prima.

    Aggiungo che, pur non essendo standardizzato, Python è andato avanti lo stesso, e pure molto bene.

    Il fatto di essere uno standard ISO di per sé non vuol dire proprio niente. Tant’è che un bel linguaggio come il Pascal è ormai relegato a una piccola percentuale di utilizzo, nonostante abbia dei draft ISO…

    gli studenti che imparano il C hanno un legame con le strutture di calcolo piu’ \vero\ rispetto a quelli che imparano linguaggi \compilati\ in opcode come java e adesso ho appreso che anche python e ruby hanno seguito la stessa strada…

    Direi proprio di no, per quanto avevo scritto già prima. Il presunto legame con l’hardware del C è, per l’appunto, presunto.

    Tant’è che quando t’ho posto delle domande mirate, hai preferito glissare non fornendo risposta. Perché risposta non c’era, ovviamente. Come nel caso più eclatante, della conversione fra interi e puntatori (e viceversa), che è la dimostrazione lampante della situazione del C nei confronti dei dettagli di più basso livello dell’hardware.

    bene sono sempre e comunque linguaggi interpretati e non compilati e come tali bisogna considerarli….

    Sono compilati, non interpretati.

    pertanto quando scegliete un linguaggio assicuratevi che i vostri strumenti di programmazione siano solidi e chi ve li fornisce non pensi solamente al profitto.. e qui rientra in campo microsoft…
    microsoft ma anche apple non ci ha pensato due volte a buttare a mare quei poverini che hanno spesso milioni di lire in visual basic, activeX, programmi DEVprofessional tipo technet di microsoft e quant’altro…
    analogamente per altri linguaggi fantasma come VJ++ un fantomatico visual java….o per vscript…o per access…i vari ADO e la lista è lunga….

    Le tecnologie nascono e muoiono, come i linguaggi di programmazione. Anche standardizzati ISO.

    adesso CDMAURO mi dice che devo fidarmi di microsoft con C sharp!
    ma manco morto! microsoft è capace che tra 3 anni decide di lasciar morire C sharp…

    Sei fuori strada. C# avrà una vita MOLTO lunga (per quanto non me ne possa interessare, visto che non mi piace). Fattene una ragione.

    A proposito: sai chi ci sta dietro alla realizzazione di C# e .NET? :P

    cosi’ come oracle decide di far morire JAVA…e tutti quelli che hanno migliaia di righe di codice in java?

    Come ho già detto nell’articolo, Java non morirà, come non muore il C. Rimarrà in vita e legato al segmento di mercato che s’è creato.

    dovranno adattarle a gjc che pero’ non è uguale alla virtual machine di SUN che si è vista bene negli anni precedenti di dare una mano nella canonizzazione di un compilatore java…

    Questo è colpa di Sun, in effetti. Microsoft, invece, ha pensato bene di accelerare proprio sulla standardizzazione sia di C# che di .NET, ed è una cosa che a te dovrebbe far piacere.

    Comunnque gcj è un progetto giovane e ha bisogno di tempo (e forza lavoro) per migliorare. Giudicarlo adesso è, appunto, prematuro.

    insomma questo articolo è a favore delle multinazionali da qualunque punto di vista lo si guardi……

    Per lo meno tu lo ammetti chiaro e tondo che sei prevenuto nei miei confronti. Che non toglie il fatto che si tratti di un’affermazione deprecabile…

  • # 74
    goldorak
     scrive: 

    @ Homero : io sono un tantino d’accordo con quanto hai scritto nel tuo ultimo intervento (#72). Sopratutto nella seconda parte quando dici che molti dei nuovi linguaggi siano piu’ fragili del C/C++.
    Ormai da qualche anno si e’ fatto strada l’idea che un linguaggio non possa esistere piu’ indipendentemente da un suo framework. E vero che il C ha qualche decine di libreria standard, ma mettete questo a confronto di Java o C#.
    Questo in larga parte porta a due conseguenze : la prima e’ che generalmente chi detiene il controllo sul framework detiene il controllo totale sul linguaggio e la sua evoluzione o morte. E secondo e questo per me e’ quanto di piu’ pericoloso, i linguaggi (e relativi framework) oggi vengono visti come isole.
    Finche’ sviluppi all’interno di un isola va tutto bene, ma poco poco che cerchi in maniera del tutto legittima (perche’ questo sta alla base dell’informatica) di passare da un linguaggio all’altro e da una infrastruttura all’altra apriti cielo, i gatekeepers dell’infrastruttura di turno che perde programmatori diventa come direbbero gli anglosassoni “litigation-friendly”.
    Lo fa Apple con quelle sue condizioni totalmente dementi quando specifica che linguaggi e framework si debba usare per sviluppare sul iphone (per motivi anticoncorrenziali). Lo sta mostrando Oracle in questi giorni facendo causa a Google.
    E credo che anche Microsoft se vedesse perdere interesse dei programmatori windows al suo .net farebbe o una nuova versione incompatibile con la vecchia, oppure farebbe causa a chi sta “rubando” sviluppatori da .Net . Non crediate che sia una ipotesi cosi’ astrusa.

  • # 75
    homero
     scrive: 

    concordo con goldrack sul fatto che i linguaggi di programmazione sono diventati strutture commerciali…

    io divido i linguaggi in interpretati e compilati questi linguaggi bytecode a mio giudizio non hanno ragione di esistere…
    il problema è quando queste cose vengono insegnate nei corsi universitari…

    definendo i framework come una cosa positiva…

    java è stato il primo sistema ad implementare “malissimo tra l’altro” una cosa del genere..

    se vogliamo nasconderci dietro la foglia di fico va bene….ma python è stato sviluppato in C…

    si poteva scegliere il pascal, delphi, turbo basic, visual basic, java, ada, fortran, e chissà per quale ragione ha preferito il C…e google continua a sviluppare python in C…ed a dividere i programmatori in fasce….

    per quanto riguarda C sharp la microsoft non mi incanta….ne ora ne mai…. i puntatori in C sharp?!!?! ma vuoi farmi ridere?!?!!? viene definito unsafe (non sicuro) dalla stessa microsoft e poi guardiamoci in faccia il puntatore in C è un indirizzo reale nella memoria del computer
    ossia quando vado a richimare l’indirizzo c’e’ nel listato in assembler un bel jmp!!!!in C sharp solo microsoft e forse manco lei sa cosa accade e dove va a pescare i dati…

    andando a cercare la documentazione on line vedo che C sharp ha già 10 anni!
    introdotto da microsoft nell’ottobre del 2000 per tappare il buco lasciato da Visual J++…
    ossia C sharp ha 10 anni?!?!?! no dico 10 anni?!?!?!
    quali programmi di rilievo sono stati scritti con C sharp?!?!?!
    ma daiii 10 anni di sviluppo e siamo a questo punto?!?!?! e io che pensavo fosse qualcosa nato con windowsXP sp2 nel 2005….
    e ci stiamo ancora ragionando sopra…
    quando il C è nato la prima cosa che ci hanno fatto è programmare un sistema operativo…giusto per provarlo…
    quando C sharp è nato la cosa che microsoft sta provando a fare è elemosinare programmatori che vogliano programmare in questo linguaggio, vendere libri a programmatori sprovveduti, elemosinare docenti che introducano C sharp nei corsi universitari, insomma lo schifo piu’ completo…roba da vomito!!!
    e io che spreco pure le parole a star dietro a queste cose…
    no dico 10 anni di C sharp ed avere il nulla piu’ completo intorno…ormai le guide C sharp te le tirano dietro a 30 euro…

    C sharp non ha nulla a che vedere con il C a parte l’utilizzo delle parentesi graffe…
    e vedere un professionista che difende un obbrobrio del genere….ma che parlo a fare qua…

  • # 76
    homero
     scrive: 

    dimenticavo per cdmauro

    “Intuition is implemented as a library of C-language functions. ”

    citazione tratta direttamente amiga intuition reference manual ufficiale della commodore inc.

    infatti mi ricordavo che la struttura delle funzioni era tipica del C…
    adesso che questa cosa l’abbiano fatta in assembler è tutta da verificare…ma la struttura delle funzioni di amiga è quella del C è su questo non ci piove….

    inoltre “EXEC was written in C by Carl Sassenrath”.

    quindi niente B ne BCPL, le librerie dell’amiga sono state scritte in C + ASSEMBLER ma la loro struttura finale è senza fuor di dubbio quella di una funzione C…
    amigados come scritto da voi è stato scritto in BCPL
    e qui chiudiamo la faccenda amiga….

  • # 77
    Cesare Di Mauro (Autore del post)
     scrive: 

    @goldorak: i framework e/o librerie standard oggi sono molto importanti per la produttività.

    Giusto per non andare troppo lontani, basti vedere al C++, a cui il buon Stroustrup ha appioppato la famigerata STL. E alle BOOST, che è un autentico mostro (nel senso che di libreria enorme e che fa anche il caffé) strausatissimo per chi lavora con questo linguaggio, e che molti vorrebbero prendesse il posto delle STL nel prossimo C++0x (anzi, da tempo circolano voci sulla sua possibile adozione in qualità di libreria standard).

    Infine, C# e .NET sono standard ECMA, e non c’è pericolo di azioni legali (nemmeno per la parte non standardizzata di .NET), ma di questo ne abbiamo già abbondantemente parlato.

    @homero:

    o divido i linguaggi in interpretati e compilati questi linguaggi bytecode a mio giudizio non hanno ragione di esistere…

    Se esistono è proprio perché hanno mostrato un netto vantaggio. Quindi perché non dovrebbero essere usati?

    il problema è quando queste cose vengono insegnate nei corsi universitari…

    definendo i framework come una cosa positiva…

    Lo sono senza dubbio, perché la produttività ne beneficia. E perché inventarsi nuovamente la ruota ogni volta non ha senso.

    se vogliamo nasconderci dietro la foglia di fico va bene….ma python è stato sviluppato in C…

    si poteva scegliere il pascal, delphi, turbo basic, visual basic, java, ada, fortran, e chissà per quale ragione ha preferito il C…

    Semplice: perché s’è imposto come linguaggio per questo tipo di applicazioni. Un po’ come il tuo Perl per chi aveva bisogno di lavorare massicciamente con le espressioni regolari, per intenderci.

    e google continua a sviluppare python in C…

    Allora non vuoi proprio capire: NON è Google che sviluppa Python. E non deciderà lei se la comunità di sviluppatori che ci sta dietro sceglierà di passare da CPython a PyPy (che, ti ricordo nuovamente, è scritto in RPython, un sottoinsieme di Python).

    ed a dividere i programmatori in fasce….

    Giusto per essere chiari: non penso proprio che chi lavora per Google conosca soltanto un linguaggio di programmazione. Anzi, da quel che ho visto finora, è gente estremamente poliedrica.

    per quanto riguarda C sharp la microsoft non mi incanta….ne ora ne mai…. i puntatori in C sharp?!!?! ma vuoi farmi ridere?!?!!? viene definito unsafe (non sicuro) dalla stessa microsoft

    Prima avevi detto che non esistevano. Il fatto che il loro uso venga definito unsafe è un altro paio di maniche, che non c’entra proprio nulla con l’oggetto del contendere.

    e poi guardiamoci in faccia il puntatore in C è un indirizzo reale nella memoria del computer
    ossia quando vado a richimare l’indirizzo c’e’ nel listato in assembler un bel jmp!!!!in C sharp solo microsoft e forse manco lei sa cosa accade e dove va a pescare i dati…

    Questa è una tua opinione personale, che tra l’altro deriva da una cattiva conoscenza del linguaggio C (e pure C#).

    Ho qui davanti il draft ISO del C99 (552 pagine): mi faresti cortesemente vedere in quale punto della sezione relativa ai puntatori sta scritto che un puntatore è un indirizzo reale della memoria?

    andando a cercare la documentazione on line vedo che C sharp ha già 10 anni!
    introdotto da microsoft nell’ottobre del 2000 per tappare il buco lasciato da Visual J++…
    ossia C sharp ha 10 anni?!?!?! no dico 10 anni?!?!?!
    quali programmi di rilievo sono stati scritti con C sharp?!?!?!

    Stai chiedendo alla persona sbagliata, ma considerata la sua vasta adozione, credo che gli esempi non mancheranno.

    Tra l’altro il framework .NET è scritto quasi interamente in C#, e ovviamente viene utilizzato da qualunque progetto che faccia uso e giri su questa piattaforma.

    ma daiii 10 anni di sviluppo e siamo a questo punto?!?!?! e io che pensavo fosse qualcosa nato con windowsXP sp2 nel 2005….
    e ci stiamo ancora ragionando sopra…

    Beh, se consideri come s’è evoluto in questi 10 anni, dalla versione 1.0 alla 4.0, e la carne al fuoco che è sta messa, mi sembra che il suo sviluppo non abbia precedenti nella storia dei linguaggi di programmazione.

    quando il C è nato la prima cosa che ci hanno fatto è programmare un sistema operativo…giusto per provarlo…

    Veramente è nato proprio per quello, non per provarlo.

    Serviva un linguaggio sintetico (anzi, succinto) e di basso livello per quel lavoro. Basti leggere le memorie dei suoi inventori, e di come, ad esempio, abbiano scelto il simbolo ‘=’ per l’assegnamento e ‘==’ per il confronto su base meramente statistica (l’assegnazione è più frequente, per cui serviva un simbolo più corto e quindi più veloce da digitare). Il che è tutto dire…

    quando C sharp è nato la cosa che microsoft sta provando a fare è elemosinare programmatori che vogliano programmare in questo linguaggio, vendere libri a programmatori sprovveduti, elemosinare docenti che introducano C sharp nei corsi universitari, insomma lo schifo piu’ completo…roba da vomito!!!
    e io che spreco pure le parole a star dietro a queste cose…
    no dico 10 anni di C sharp ed avere il nulla piu’ completo intorno…ormai le guide C sharp te le tirano dietro a 30 euro…

    T’ho già detto che c’è gente che ci fa soldi a palate. Tanto basta.

    C sharp non ha nulla a che vedere con il C a parte l’utilizzo delle parentesi graffe…

    Purtroppo. Avrei preferito che il suo inventore rimanesse sulla scia di quanto aveva già fatto anni prima.

    Ma la gente è troppo abituata a quella sintassi.

    e vedere un professionista che difende un obbrobrio del genere….ma che parlo a fare qua…

    Questo è un attacco ad hominem, dopo una requisitoria che di tecnico non ha nulla.

    dimenticavo per cdmauro

    “Intuition is implemented as a library of C-language functions. ”

    citazione tratta direttamente amiga intuition reference manual ufficiale della commodore inc.

    infatti mi ricordavo che la struttura delle funzioni era tipica del C…
    adesso che questa cosa l’abbiano fatta in assembler è tutta da verificare…ma la struttura delle funzioni di amiga è quella del C è su questo non ci piove….

    Mi pare ovvio: è la convezione utilizzata per la chiamate. E siccome Intuition, come tutte le librerie, espone delle API che devono essere accessibili da chiunque con qualunque linguaggio, una convenzione la si deve scegliere per forza, e si opta quasi sempre per quella del C (sic).

    inoltre “EXEC was written in C by Carl Sassenrath”.

    Questo non mi risulta proprio, a meno che non parliamo di AmigaOS 2.0 e successivi. Se recupero qualche informazione te la riporto.

    quindi niente B ne BCPL, le librerie dell’amiga sono state scritte in C + ASSEMBLER

    Dipende dalla versione, come dicevo prima.

    ma la loro struttura finale è senza fuor di dubbio quella di una funzione C…

    In realtà se vai a vedere come sono fatte tutte le API esposte da una libreria Amiga, la struttura è… assembly. Tutti i parametri vengono passati nei registri, con l’accortezza di usare i registri dati per i dati, e quelli indirizzi per gli indirizzi.

    I compilatori C dell’epoca permettevano agevolmente di mappare i parametri delle funzioni negli appositi registri. Ma questo lo faceva anche il Microsoft AmigaBASIC (che era interpretato), per citare un linguaggio che non c’entra niente col C.

    amigados come scritto da voi è stato scritto in BCPL
    e qui chiudiamo la faccenda amiga….

    OK

  • # 78
    goldorak
     scrive: 

    @ Cesare di Mauro : si sono d’accordo, e guarda che non ho mai detto il contrario. Stavo solo mostrando come oggi i linguaggi vengono sviluppati insieme ad un framework (il quale ha sempre centinaia se non migliaia di classi). E questo da certi punti di vista ha dei svantaggi. I programmatori daltra parte sono avantaggiati, ma ce’ sempre un rovescio della medaglia. E come citi giustamente il C++ non ne e’ esente. Basta vedere appunto la libreria Boost o per non andare molto lontano le QT. Ma sia Boost che QT sono molto lontane dalla completezza di un framework come quello di Java o di C#, quindi ce’ anche una differenza di scala se proprio vuoi fare un confronto tra questi linguaggi (e relativi framework/librerie).

  • # 79
    Giulio85
     scrive: 

    @homero: C# usa la keyword unsafe proprio perché manipolare i puntatori è una tecnica che di per se presenta dei rischi (a prescindere dalla capacità del programmatore).

    In generale i puntatori non rientrano nelle specifiche di un software, e meno che meno sono strettamente necessari per risolvere un problema, se questo è di alto livello.

    Sai quanti errori e quanti problemi hanno dato i programmi scritti in C/C++ per colpa di una gestione errata dei puntatori, e del fatto che la tipizzazione non è forte?

    Cioè cose come 1+true = 2, mi fanno venire i brividi.

    Come si può scrivere software robusto se il linguaggio non lo è?

    Non è un caso la proliferazione di linguaggi funzionali, anche perché possono facilitare il testing e la dimostrazione formale che un dato pezzo di codice sia corretto.

  • # 80
    homero
     scrive: 

    o santa appollonia!
    c’e’ scritto oltre a gli haeder e quant’altro anche le variabili possono essere usate come indirizzi di memoria e questo è cosi’ vero che possono essere passate facendo riferimento al nome della variabile ad una funzione integrata in un listato C con il comando asm{} come puntatori ad un valore in un listato in assembly incluso nel sorgente C, naturalmente quello che è nelle parentesi alla funzione asm non è traslato dal compilatore…capitolo 5 del IEC 9899 1990 ….e ovvio che non possono scriverti nelle specifiche che c’e’ un’istruzione jmp perchè potrebbero esistere microprocessori che non siano dotati di instruzioni di salto strutturate in questo modo…ma è scritto a chiare lettere che gli header alle funzioni, vengono risolti prima che parta il programma ed anche se quelle funzioni non verranno utilizzate….ecco perchè in C sono necessari i prototipi di funzioni…perchè ad agni funzione viene associato un puntatore di default…ossia un indirizzo di memoria…a cui si puo’ accedere semplicemente attraverso il nome della funzione senza parametri o altro…
    quanto scritto sopra è quello che ha permesso di scrivere routine in misto C-ASSEMBLER come quelle fatte nel 1985 su amiga…in cui si sfruttava la struttura di richiamo della funzione standard del C che richiamava com function extern alcune routine assembler…
    pertanto la struttura dei puntatori è l’ossatura del C ed è quella che lo distingue dagli altri linguaggi e senza le quali exec ed intuition non sarebbero come li conosciamo…
    x giulio
    i puntatori permettono di velocizzare la gestione dei dati in maniera straordinaria…e di risparmiare moltissima memoria…
    una volta che impari ad utilizzarli non solo non ne fai piu’ a meno, ma ti chiedi come facevi senza…
    i problemi dei bug dei puntatori risiedono in
    1. nella scarsa conoscenza che un programmatore improvvisato ha del compilatore che usa e dell’ambiente host su cui girerà il programma….
    2. nel non conoscere le decine di casi particolari che coinvologono questo strumento di programmazione…infatti ci sono puntatori a void o a oggetti non definiti che richiedo attenzione ma questa è un’altra storia…

    termino dicendo che non conosco nessuno che abbia fatto soldi a palate con il C sharp a parte quelli che hanno scritto i libri per divulgare questo linguaggio….

    inoltre sul mio PC con windows non ho neppure un’applicazione .net installata…sintomo che senza .net si puo’ lavorare e anche bene…al contrario ho qualche applicazione java ma la colpa di questo è che java si è radicato all’interno di alcuni corsi universitari producendo una serie di piccoli software in cui purtroppo si è costretti ad imbattersi e che spesso ci si chiede perchè non li abbiano scritto in un’altro linguaggio…

    perchè microsoft non programma iexplore 9 in formato .net cosi’ almeno tutti noi avremo almeno una applicazione .net utile installata nei nostri sistemi…
    prima avevo i driver di ati che utilizzavano questo framework solo per l’interfaccia di configurazione e pesava un casino ma ora che uso nvidia non ho piu’ neppure questo…
    se penso che sono 10 anni che gira sta solfa di .net c’e’ da chiedersi che sono stati a fare gli sviluppatori di microsoft in questi 10 anni a parte sforzarsi di convincere i programmatori della bontà dei loro sistemi?

    x giulio parli di linguaggi funzionali…ma il C che cos’e’? afunzionale?
    ad ogni modo chi investe il suo tempo in C sharp farà la fine di coloro che hanno investito il loro tempo in visual basic…

  • # 81
    Nicola
     scrive: 

    ottimo articolo e ottime fonti di informazioni i molti commenti in calce(tralasciando le solite guerre tra linguaggi XDD).

    Volevo chiederti una cosina “tecnica” Cesare: in un tuo commento hai detto che alcuni tuoi colleghi, per ottimizzare il codice JME, invece di usare i canonici controlli sugli indici di strutture dati hanno deciso di gestire direttamente le “eccezioni” lanciate. Ma per loro natura le “eccezioni” non sono computazionalmente più “pesanti”? O mi sono perso qualcosa in questi anni?

    E’ un mio dubbio eh, spero che mi aiuti a capire meglio(se possibile).

    per chi dice che nessuno ha fatto soldi a palate con C#, chiedere ad Autodesk(una a caso) con cosa sono scritte le sue ultime versioni di software(non tutto, ma una parte molto rilevante) :-)

  • # 82
    Giulio
     scrive: 

    @homero:

    Nessuno mette in dubbio che in alcuni casi i puntatori possono essere comodi, ma questo dipende dai casi se il linguaggio è molto ricco non è detto che se ne senta la mancanza.

    Il punto è che anche programmatori esperti possono commettere errori nella loro gestione, e questo causa problemi spesso subdoli, non solo a livello di gestione di memoria ma anche di sicurezza.

    Il C non ha un paradigma funzionale come altri linguaggi nati per lo scopo (Lisp, Haskell).

    D’altronde ripeto, un linguaggio che consente cose come 1+true, non è certamente robusto.

    Ti assicuro che in alcuni ambiti è decisamente meglio girare più lenti ma essere sicuri che il codice sia corretto.

    E sicuramente C non aiuta di certo a scrivere codice corretto, anzi, i dettagli di basso livello in generale non aiutano a concentrarsi sul problema vero e proprio.

    Ripeto le prestazioni dell’eseguibile non sono tutto.

  • # 83
    Gibbus
     scrive: 

    @Giulio
    Guarda, a proposito di Autodesk, parlo di AutoCAD, il suo programma “storico”.
    Le ultime versioni di AutoCAD, sono molto belle per quanto riguarda le funzionalità aggiuntive che col tempo, ovviamente, si sono aggiunte. Ma diamine, l’utilizzo normale soffre di una pesantezza francamente inconcepibile se pensiamo alla potenza di calcolo che abbiamo oggi a disposizione sia per quanto riguarda la CPU che la GPU. Muovere solo il cursore sullo schermo, è un’operazione che ti fa lavorare un Penryn (un Penryn, mica un 486…) dal 20 al 40%. Solo per muovere il cursore… Se hai un i7, allora l’anzidetta percentuale scende tra il 5 ed il 10%…
    E le finestre di dialogo? Spostarle non è pesante per la cpu, però il movimento non è fluido come DOVREBBE ESSERE, è scattoso (anche con schede video professionali da migliaia di euro), e questo aumenta la percezione di lentezza da parte dell’utilizzatore… Io, onestamente, trovo incomprensibile cambiare gli strumenti di sviluppo che ti portino ad avere codice MOLTO più lento o che richiedono RISORSE computazionali MOLTO PIU’ SPINTE a parità di risultato finale. Il fatto che oggi la RAM non sia un problema ed i GHz abbondino, IMHO non giustifica.
    Da questo punto di vista mi trovo pienamente d’accordo con chi ritiene che certi software di sviluppo abbiano più uno scopo di marketing che di vera utilità reale.

    PS
    Ma davvero il java, OGGI, produce codice eseguibile più veloce di quello prodotto da C e Fortran? Dico sul serio, chiedo per sapere… questa cosa mi intriga e affascina allo stesso tempo, perché le mie ultime esperienze di java risalgono al 2002, e le performances erano quello che erano, tanto che lo mollai il java…

    Un saluti a tutti e non arrabbiamoci troppo… :D

  • # 84
    Gibbus
     scrive: 

    Edit
    il mio post era rivolto a Nicola e non a Giulio.

    Scusate.

  • # 85
    Nicola
     scrive: 

    @Gibbus

    La domanda era “qualcuno fa soldi a palate con c#?” ed io ho risposto. La domanda non era se chi fa soldi a palate fa anche ottimi software. Io posso garantirti che con C# si possono fare cose molto belle e anche performanti. Poi, come molte volte ripetuto da Cesare, quando parliamo di performance come requisito di un progetto si deve contestualizzare il tutto. Se le performance sono il requisito fondamentale di un progetto, può darsi(in molti casi lo è) che neanche il C/C++ sia in grado di garantirne le specifiche, se queste sono troppo stringenti. Ergo, ad esempio, se la differenza prestazionale tra C# e C/C++ è quantificabile in un tot %, magari per il target di utilizzo del software la differenza è ininfluente.

    Poi il mio era solamente un esempio a caso, ci sono molte grosse realtà che fanno soldi con programmi scritti in C# e scritti anche bene.

    PS
    Si, oggi in java si possono raggiungere performance paragonabili(e in alcuni casi migliori) al C.

  • # 86
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Giulio85:

    Sai quanti errori e quanti problemi hanno dato i programmi scritti in C/C++ per colpa di una gestione errata dei puntatori, e del fatto che la tipizzazione non è forte?

    Cioè cose come 1+true = 2, mi fanno venire i brividi.

    Attenzione a cosa intendiamo per tipi. In Python quell’espressione è corretta e dà 2 come risultato, pur essendo un linguaggio fortemente tipizzato.

    Il motivo è semplice: la classe bool deriva da int, per cui False e True sono valori numerici (interi) a tutti gli effetti e l’operazione di somma, essendo definita, è applicabile (e ritorna sempre un intero).

    Provenendo dal Pascal è una cosa che mi dà fastidio, e avrei preferito che bool fosse a una classe a sé stante e, quindi, che l’operazione di somma con interi fosse vietata.

    Il problema è che il tipo bool è stato introdotto in Python dopo parecchio tempo (non ce n’è stato, e non ce ne sarebbe mai stato bisogno, visto come questo linguaggio gestisce le espressioni “booleane”), perché i programmatori erano abituati a definirsi da soli i simboli False e True, assegnandogli logicamente i valori 0 e 1. Per non rompere la compatibilità con tutto il codice scritto in quel modo, Guido var Rossum (il creatore di Python) ha preferito far discendere bool da int.

    @homero:

    o santa appollonia!
    c’e’ scritto oltre a gli haeder e quant’altro anche le variabili possono essere usate come indirizzi di memoria e questo è cosi’ vero che possono essere passate facendo riferimento al nome della variabile ad una funzione integrata in un listato C con il comando asm{} come puntatori ad un valore in un listato in assembly incluso nel sorgente C, naturalmente quello che è nelle parentesi alla funzione asm non è traslato dal compilatore…capitolo 5 del IEC 9899 1990 …

    Santa Cleopatra, nel capitolo 5 (a pag. 21) c’è scritto “Environment”, e non mi risulta nulla di quello che ha scritto.

    Tutto ciò premesso che:
    – il comando asm non fa parte dello standard; è definita soltanto la keyword asm, e null’altro;
    – la definizione di puntatore (pag. 48) è “A pointer type describes an object whose value provides a reference to an entity of the referenced type.”

    Per cui, come vedi, non c’è nulla che parli di indirizzi di memoria e quant’altro.

    E’ tutto dipendente dall’implementazione, come viene ripetuto innumerevoli volte nel draft dello standard.

    Per cui è bene che ti metta l’anima in pace: l’accesso all’hardware di cui hai parlato, e di cui purtroppo sono convinti zilioni di programmatori C/C++, è soltanto una gentile concessione degli specifici compilatori. Se questi compilatori non mettessero a disposizione delle “deroghe” al linguaggio, l’unico modo per scrivere s.o. sarebbe quello tradizionale: via assembly.

    e ovvio che non possono scriverti nelle specifiche che c’e’ un’istruzione jmp perchè potrebbero esistere microprocessori che non siano dotati di instruzioni di salto strutturate in questo modo…ma è scritto a chiare lettere che gli header alle funzioni, vengono risolti prima che parta il programma ed anche se quelle funzioni non verranno utilizzate….ecco perchè in C sono necessari i prototipi di funzioni…perchè ad agni funzione viene associato un puntatore di default…ossia un indirizzo di memoria…a cui si puo’ accedere semplicemente attraverso il nome della funzione senza parametri o altro…

    Questo vale per qualunque linguaggio permetta di definire delle funzioni.

    Comunque in C le intestazioni delle funzioni sono necessarie per conoscerne la “firma” permettere al compilatore di controllare che il passaggio dei caratteri e il valore di ritorno sia corretto. Certamente non per quello che hai scritto tu, visto che sono state rese obbligatorie soltanto nell’ANSI, mentre fino al K & R potevi benissimo non specificarli (e il compilatore aveva quindi bisogno di una passata in più dei sorgenti per recuperarli, e poi procedere a genere il codice).

    quanto scritto sopra è quello che ha permesso di scrivere routine in misto C-ASSEMBLER come quelle fatte nel 1985 su amiga…in cui si sfruttava la struttura di richiamo della funzione standard del C che richiamava com function extern alcune routine assembler…
    pertanto la struttura dei puntatori è l’ossatura del C ed è quella che lo distingue dagli altri linguaggi e senza le quali exec ed intuition non sarebbero come li conosciamo…

    Assolutamente no, visto che era roba che si trovava tranquillamente anche negli altri linguaggi, e t’avevo citato anche AmigaBASIC per questo.

    i puntatori permettono di velocizzare la gestione dei dati in maniera straordinaria…e di risparmiare moltissima memoria…
    una volta che impari ad utilizzarli non solo non ne fai piu’ a meno, ma ti chiedi come facevi senza…

    Per me è l’esatto contrario, visto che mi sono “disintossicato” con Python, che non ne richiede l’uso.

    Piuttosto dovresti dire che in C è INDISPENSABILE utilizzarli perché, essendo un linguaggio sintatticamente povero, non ha altri mezzi.

    i problemi dei bug dei puntatori risiedono in
    1. nella scarsa conoscenza che un programmatore improvvisato ha del compilatore che usa e dell’ambiente host su cui girerà il programma….
    2. nel non conoscere le decine di casi particolari che coinvologono questo strumento di programmazione…infatti ci sono puntatori a void o a oggetti non definiti che richiedo attenzione ma questa è un’altra storia…

    I bug coi puntatori li producono anche programmatori stratitolati. E questo perché è oggettivamente difficile non produrre codice senza bug, ma soprattutto grazie ai puntatori è molto più facile produrne (e di rognosi pure).

    perchè microsoft non programma iexplore 9 in formato .net cosi’ almeno tutti noi avremo almeno una applicazione .net utile installata nei nostri sistemi…

    E’ presto, ma in futuro mi aspetto che quasi tutto il codice di Windows sia in .NET.

    x giulio parli di linguaggi funzionali…ma il C che cos’e’? afunzionale?

    Il C è un linguaggio strutturato. Nudo e crudo. Non ha neppure le inner function…

    @Nicola:

    Volevo chiederti una cosina “tecnica” Cesare: in un tuo commento hai detto che alcuni tuoi colleghi, per ottimizzare il codice JME, invece di usare i canonici controlli sugli indici di strutture dati hanno deciso di gestire direttamente le “eccezioni” lanciate. Ma per loro natura le “eccezioni” non sono computazionalmente più “pesanti”? O mi sono perso qualcosa in questi anni?

    E’ un mio dubbio eh, spero che mi aiuti a capire meglio(se possibile).

    Molto semplicemente, la JVM esegue SEMPRE dei controlli sugli indici quando tenti di accedere a un array, per cui al minimo “sgarro” verrà sollevata un’opportuna eccezione (di index out of bound).

    Questo si può sfruttare per ottimizzare il codice, eliminando controlli ridondanti, come dicevo prima. Lo si fa eseguendo una scansione dell’array senza controllare che l’indice abbia superato l’ultimo elemento disponibile. Quindi inizializzi l’indice a 0, e poi lo incrementi e basta, mentre nel corpo del programma lo usi direttamente per accedere all’array.

    Poiché sicuramente verrà sollevata l’eccezione, è sufficiente intrappolare l’intero ciclo for in un try / catch che intercetti l’eccezione di index out of bound, e non faccia niente.

    Le eccezioni sono pesanti da gestire, come giustamente dicevi, perché bisogna creare uno stack frame ed eseguire l’unwind dello stack alla fine del try / catch, però bisogna in che modo si usano.

    Nello specifico, il try / catch non sta dentro il ciclo for, ma fuori. Quindi lo stack frame viene creato una sola volta, prima che inizi il ciclo, ed eliminato subito dopo aver intercettato l’eccezione, che viene eseguita una sola volta.

    Il vantaggio è notevole, perché lo stack frame viene creato una sola volta, mentre il controllo del superamento dell’ultimo elemento (che si traduce penso in almeno quattro bytecode da eseguire: il load dell’indice, il load della dimensione dell’array, il confronto fra i due valori, e il salto condizionato) viene effettuato per ogni iterazione del ciclo.

    Spero sia chiaro. Eventualmente chiedi pure.

  • # 87
    homero
     scrive: 

    una sola nota su autocad…
    autodesk da autocad 2000 ha cominciato ad affincare visual basic per gli script ai tradizionali programmi autolisp….adesso ha sostituito visual basic con C sharp..nulla di nuovo sotto il sole…

    autodesk ha sempre seguito microsoft e questa è stata la sua fortuna, infatti non ha mai voluto produrre salvo un’unica versione su mac negli anni 90 per altri OS….a differenza di altre società produttrici cad che producevano anche per unix/mac…mantenendo un rapporto privilegiato con Microsoft

  • # 88
    shodan
     scrive: 

    @ Giulio
    Discorso prestazioni: è un argomento delicato e con molte sfaccettature, quindi quella che riporto è la _mia_ impressione. Se parliamo di codice che fa calcolo numerico, le prestazioni di C e Java risultano più o meno paragonabili; tuttavia, il primo generalmente è più veloce. Ovvio che poi ci saranno casi particolari dove la tecnica JIT permette al codice di girare più velocemente, ma genericamente il C rimane più veloce.
    Le cose, per il Java, si mettono peggio quando si considera la velocità di un programma che fa pesantemente uso di I/O e di grafica: in questo caso, l’overhead della virtual machine è più significativo. C’è infine da dire che spesso l’apparente lentezza di un’applicazione Java è data dal tempo necessario ad avviarla: il sistema deve infatti caricare la JVM, compilare (se non lo ha già fatto prima) parte del codice, e quindi avviarne l’esecuzione. Questo spiega anche perchè un programma Java tende a usare parecchia memoria in più rispetto al corrispettivo scritto in C (o con altro linguaggio compilato).

    A titolo di esempio, ti riporto alcuni link di un sito che mette a confronto le performance di molti linguaggi (o per meglio dire della coppia implementazione/compilatore) in 12 benchmark più o meno sintetici.
    – Ubuntu x64 one core: http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php
    – Ubuntu x64 multi core: http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

    Un paio di commenti in ordine sparso:
    – il C resta in genere più veloce del Java
    – le prestazioni della Java 6 sono comunque di tutto rispetto
    – puoi osservare l’abissale differenza che passa tra il Java 6 in modalità JIT e lo stesso Java 6 in modalità interpretato (Java 6 -Xint)

    Ricorda che però i benchmark non sono tutto, come anche indicato su quello stesso sito: http://shootout.alioth.debian.org/flawed-benchmarks.php. Riporto una frase significativa: “Your application is the ultimate benchmark”

    @ Homero
    Guarda, credo che tu stia dimenticando che “programmare” non è una cosa fine a se stessa, ma deve portare a raggiungere un obiettivo nel minor tempo possibile e col livello qualitativo/prestazionale adeguato. In parte capisco cosa vuoi dire: anche a me piace l’approccio “duro e puro”, dove hai tutto sotto controllo, puntatori compresi. E’ più appagante sentire di aver “dominato la macchina”. Tuttavia, non si può negare che questo approccio porti a un mare di tempo perso dietro a runtime bug molto insidiosi, che capitano una volta si e cento no ma che possono pregiudicare il funzionamento del programma. Java, Python, PHP, Perl e via discorrendo rendono genericamente _molto_ più produttivo il programmatore di turno, che non deve perdere tempo dietro a un puntatore nullo deferenziato chissà dove. E, in fin dei conti, anche i nostri amati/odiati puntatori non sono poi così trasparenti verso l’hardware, dato che tutti i processori dal 386 in poi hanno una MMU integrata che nasconde il vero indirizzo di memoria dell’oggetto. Come vedi, anche a bassissimo livello (hardware) si è preferito astrarre, perchè altrimenti la vita del programmatore sarebbe stata davvero troppo complicata.
    Per avere davvero il controllo della macchina in ogni suo aspetto e bypassando ogni tipo di astrazione, o scrivi linguaggio per la modalità reale o passi in modalità SMM. In entrambi i casi torniamo all’epoca del DOS…

  • # 89
    shodan
     scrive: 

    C’è per caso qualcosa che non va con il sistema di commenti? Ho fatto diverse volte un submit, ma non vedo il commento… :p

  • # 90
    shodan
     scrive: 

    Mmm… si: ho impasticciato in commenti… scusate. Magari i doppioni si possono cancellare.
    Domanda: ci sono caratteri non accettati in fase di commento? C’è un limite ai link esterni che si possono inserire?

    Grazie!

  • # 91
    goldorak
     scrive: 

    Bene visto che ormai siano in pieno oceano, perche’ Cesare di Mauro non apre un’altra discussione sull’evoluzione dei linguaggi (marketing compreso ?) ^_^.
    Vi cito un articolo ormai vecchio di qualche anno, scritto da Joel Spolsky (ex programmatore Microsoft del team Excel), intitolato “Come Microsoft perse la guerra delle API”. E spiega perche’ Microsoft abbandono’ l’architettura COM/COM+ per inseguire Java.

    Eccoli qui : http://www.joelonsoftware.com/articles/APIWar.html

    E molto illuminante.

  • # 92
    Cesare Di Mauro (Autore del post)
     scrive: 

    @shodan: il problema deriva dai link. L’antispammer è molto suscettibile. Comunque ho eliminato tutti i doppioni e lasciato il primo commento.

    @goldorak: grazie per il link. Domani me lo smazzo (sono a pezzi e sto per tuffarmi a letto), ma a naso credo che solo questo non basti per poter scrivere un articolo sull’evoluzione dei linguaggi, specialmente riguardo alla variabile marketing.

  • # 93
    shodan
     scrive: 

    Grazie mille, Cesare :)

  • # 94
    pleg
     scrive: 

    @ Max (post 51)

    “Al mit usano il python per l’introduzione alla programmazione, a Stanford usano il java”

    Curiosamente qualche anno fa sono “regrediti”, e adesso a Stanford per i corsi introduttivi usano C e C++ :)

  • # 95
    Cesare Di Mauro (Autore del post)
     scrive: 

    Mi sarei aspettato l’assembly o direttamente il linguaggio macchina. O:-)

  • # 96
    pleg
     scrive: 

    E perche’ mai??

    Beh in uno dei primi corsi si da’ una sbirciata anche ad un pochino di assembly (x86, ovviamente), ma non e’ qualcosa che serva sapere da subito… anzi direi che per molti non serve sapere quasi mai :)

  • # 97
    goldorak
     scrive: 

    Cesare di Mauro ha scritto : “@goldorak: grazie per il link. Domani me lo smazzo (sono a pezzi e sto per tuffarmi a letto), ma a naso credo che solo questo non basti per poter scrivere un articolo sull’evoluzione dei linguaggi, specialmente riguardo alla variabile marketing.”

    Certamente, l’articolo che ti ho linkato e’ molto specifico, cerca di fare un analisi soltanto della situazione in Microsoft. E un punto di partenza, o almeno uno dei punti di cui potresti parlare.
    Poi non dimentichiamoci che anche linguaggi istituzionali come il Cobol e il Fortran hanno avuto sponsors dietro con alterne fortune.
    Il marketing e’ sempre stato una componente non indifferente dell’adozione “mass market” dei vari linguaggi. In questo senso Java, C# non sono differenti dal C o dal Lisp. Anche il Lisp ha avuto il suo piccolo periodo di gloria, chi si ricorda delle aziende che producevano le Lisp machines ?
    Ce’ una analogia alquanto rimarchevole tra quello che succede nel mondo moderno dell’economia e quello nei linguaggi di programmazione. Cosi’ come si fa sempre piu’ strada il consolidamento aziendale con una diminuzione della concorrenza effettiva nel mondo reale, anche nei linguaggi di programmazione piuttosto che promuovere la diversita’ si va sempre dippiu’ verso quello che io chiamo linguaggi mostri.
    Linguaggi cioe’ che inglobano o tentano di inglobare novita’ e nuovi paradigmi complicando a dismisura il linguaggio stesso, distruggendo l’influenza dei nuovi competitors.
    Finisco con una provocazione, il futuro ricepimento dello standard C++0x sarebbe una magnifica occasione per ELIMINARE del tutto la retrocompatibilita’ con il C. Storicamente ci fu il bisogno di questa scelta deleteria per incoraggiare l’uso del linguaggio, oggi questo non e’ piu’ necessario e renderebbe il C++ un linguaggio con una sua precisa identita’ e per quanto possibile piu’ coerente.

  • # 98
    homero
     scrive: 

    \E, in fin dei conti, anche i nostri amati/odiati puntatori non sono poi così trasparenti verso l’hardware, dato che tutti i processori dal 386 in poi hanno una MMU integrata che nasconde il vero indirizzo di memoria dell’oggetto. Come vedi, anche a bassissimo livello (hardware) si è preferito astrarre, perchè altrimenti la vita del programmatore sarebbe stata davvero troppo complicata.\

    concordo in pieno che l’astrazione è necessaria, infatti quando acquistai la scheda la A2620 per il mio amiga2000 mi chiesi a lungo a cosa servisse il 68851 della motorola….poi quando studia unix compresi la necessità di avere una mmu ma quando gli strati di astrazione si sovrappongono gli uni sugli altri allora arriva un momento in cui dare un freno a tutto…
    oggi se permettete abbiamo uno strato di astrazione dell’hardware x86 in cui abbiamo istruzioni vecchie di 30 anni tradotto su architetture che nulla hanno a che vedere con queste…
    abbiamo HAL del sistema operativo, abbiamo le librerie di ogni natura per gestire qualunque cosa ci venga in mente e su questo abbiamo un framework che è un’altra astrazione che comincia di nuovo questo giro vizioso, abbiamo un sistema che dialoga con l’hal del sistema operativo e con le librerie, abbiamo un interprete di bytecode e altre librerie che fanno riferimento al framework che interpretano i nostri programmi metacompilati…

    io reputo che un HAL+librerie sia il massimo di astrazione che debba essere consentito…perchè ad astrarre troppo si arriva in cielo….

  • # 99
    Nicola
     scrive: 

    @cesare

    Grazie della risposta. Il dubbio mi era venuto essendo a conoscenza della tecnica di generazione e gestione delle eccezioni. Anche se la “pesantezza” dipende pure da quante “gerarchie” deve risalire l’eccezione prima di essere catturata e gestita.

    Per quanto riguarda la questione della didattica, bisogna anche fare dei distinguo. Nell’uni che ho frequentato io, il primo corso di “programmazione” era inserito come modulo comune. Quindi anche un futuro ingegnere meccanico si doveva sorbire il suddetto corso. Non credo che in questi casi sia utile cominciare con linguaggi troppo “vicini all’hardware”(termine usato per accontentare molti dei presenti XDD). Nel mio caso hanno usato Java, ma col senno del poi io avrei usato qualcosa di più “generale”.

  • # 100
    shodan
     scrive: 

    @ Homero
    E’ chiaro che anche all’astrazione deve esserci un limite, altrimenti si perde tutto nell’overhead necessario per la gestione del sistema.
    Tuttavia, il solo HAL + librerie non ti permettono di scrivere del codice, compilarlo, e farlo girare dovunque. Questo sarebbe possibile se le librerie (e le syscall) utilizzassero una sintassi/firma identica, cosa che purtroppo non fatto.
    In passato ci sono stati standard che hanno raccolto un certo successo (POSIX su tutti) ma, in definitiva, le aspettative sono state disattese.

    Un codice che gira all’interno di una propria “virtual machine” ti permette di bypassare tutto questo, a patto che il framework che l’accompagna sia sufficientemente ricco da non farti rimpiangare le API del sistema operativo dove gira il programma. Ecco perchè la Java classpath è veramente grossa (leggi: completa), così come immagino lo sia anche la libreria del .NET
    E, tuttavia, restano ancora delle limitazioni… è per questo che in Java puoi ricorrere alle JNI o, meglio, alle JNA, ma rischi di buttare alle ortiche la portabilità del codice.

    Tutto questo ha un costo: le prestazioni; è inutile girarci sopra.Però ha l’enorme vantaggio di semplificare moltissimo la vita al programmatore di turno. E’ chiaro che poi bisogna trovare un compromesso. Tanto per fare un esempio di una cosa che non piace nemmeno a me, tempo fa Google fece un porting di Quake2 in Javascript: i requisiti minimi parlavano di un processore a 2 Ghz! Se penso che girava sul mio K6 @ 200Mhz mi sento male :p

  • # 101
    Nessuno
     scrive: 

    @Max

    Chiariamoci. Non ho detto che i linguaggi di alto livello siano schifezze o da non usare. Io stesso ho detto che ho usato il framework .NET per sviluppare una applicazione abbastanza complessa. Ovviamente ciò mi ha permesso di risparmiare molto tempo, sebbene alla fine l’applicativo risultante fosse sicuramente peggiore, sotto il punto di vosta prestazionale, rispetto ad averlo scritto in C++ puro (invece che in C++.NET). Quello che contestavo è il fatto che si dica “beh, un Hhello word da un mega non è un problema”. Per me lo è. Se mi dici che su una applicazione di 50.000 linee di codice il mega (e magari qualcosa in più) del framework controbilancia con la facilità di gestione e tutto il resto, allora posso essere d’accordo. E’, come detto, questione di valutare l’uso di risorse rispetto al lavoro da compiere.

    @Cesare
    Riguardo a Java, indipendentemente dalla presenza o meno del framework Java, in Java non esiste la possibilità di accedere ad una locazione di memoria assoluta. Se vuoi farlo devi crearti una libreria che non è scritta in Java e poi chiamarla da lì. Uguale per tutti i linguaggi interpretati che quindi girano in una sandbox. Non è impossibile per questi fare le “normali” cose che fanno i linguaggi di più basso livello, ma è necessario creare dei “buchi” verso il basso tramite proprio tali linguaggi. Altrimenti non si può. Tutte le VM che crei tramite linguaggi ad alto livello rimangono limitate dal linguaggio stesso, come detto. Se vuoi fare una VM in Java che fa girare applicazioni in C sei pienamente libero di farlo, ma purtroppo le applicazioni che vi gireranno non saranno in grado di fare di più di quello che già fai in Java. Ovvero, stai “castrando” il linguaggio che emuli sui limiti del linguaggio con cui implementi la VM.

    Ma indipendentemente da cosa si è in grado di fare con un linguaggio piuttosto che con un altro, il mio appunto originale era sul fatto che si possa diventare dei programmatori senza conoscere i linguaggi come il C/C++. Secondo la mia esperienza, e sono anni che programmo e vedo diverse realtà e capacità di programmazione di molta gente, se uno, non dico usare, ma nemmeno sentito per nome quelle che sono le possibilità che aprono questi linguaggi, allora è un mezzo programmatore. E non lo dico per pavoneggiarmi o altro solo perchè io dopo anni di studio (e sì anche quello serve) e di esperienza sono riuscito nel mio piccolo ad adoperarli. E’ essere a livello di triciclo e non aver mai imparato a restare in equilibrio sulla bicicletta. Ovviamente ci si sposta anche in triciclo o mezzi analoghi, ma non potrà definirsi ciclista.
    Qui non si dice che uno deve sapere guidare la moto di Valentino Rossi a 300 all’ora per dire di saper andare in moto. Si dice che almeno in equilibrio su di essa ci sappia stare, indipendentemente da quanto bravo è a fare le pieghe (che definisce la capacità professionale e si matura con l’esperienza). Ma se non sai nemmeno stare in equilibrio, non puoi neanche partire per fare esperienza. Semplicemente è limitato ad un “livello inferiore” di conoscenza. Che poi possa fare soldi a palate, potrà anche essere. Ma non è questo il discorso. Anche il carrozziere sotto casa fa più soldi di me, però non può definirsi un programmatore. Spero che la distinzione sia chiara ora.

    D’altronde, la cosa è visibile in questi termini: con i linguaggi ad alto livello è possibile fare moltissime cose in maniera semplificata. E’ vero però che tali cose, dato più tempo o maggiore esperienza, sono possibili con i linguaggi di basso livello. Viceversa, problemi di basso livello non sono risolvibili tramite linguaggi ad alto livello, da cui i primi sono più completi dei secondi. E se non servono nella vita professionale (può benissimo essere, dipende dal campo in cui si lavora) rimangono indispensabili per essere completi professionalmente. E quindi indispensabili come strumenti di apprendimento. Se vuoi è lo stesso di un artigiano che comprende a fondo la tecnica che gli permette di create un prodotto e un operaio che lavora in catena di montaggio e tutti i giorni fa solo il minimo indispensabile attribuitogli per finire il lavoro nella sua isola nel tempo previsto. Entrambi creano qualcosa, ma su due livelli completamente differenti.

  • # 102
    Cesare Di Mauro (Autore del post)
     scrive: 

    @goldorak: finalmente sono riuscito a leggermi quel lunghissimo articolo. Sono per buona parte d’accordo con l’autore, tranne per alcuni punti (.NET infilato nelle DLL standard; il fatto che abbia creato maggior caos proponendo un’altra scelta).

    Al momento non è abbastanza per scrivere un articolo sull’evoluzione dei linguaggi & marketing.

    Penso di parlare, invece, di linguaggi di programmazione e astrazione, visti anche i commenti che si sono generati qui.

    Riguardo a C++0x non penso proprio che verrà meno la retrocompatibilità, che tra l’altro è stato il pallino di Stroustrup.

    Verranno aggiunte altre funzionalità al linguaggio, rendendolo sempre più “mostro” (secondo la tua definizione); quindi più complicato e difficile da digerire.

    Per cui da sviluppatore non amo il C++ per questo motivo, e tanto apprezzerò la sua evoluzione.

    @Nicola: nello specifico, l’eccezione deve risalire una sola gerarchia.

    @Nessuno: su linguaggi di programmazione & astrazione & “potenzialità” preferisco parlarne in un prossimo articolo. :P

  • # 103
    floriano
     scrive: 

    in effetti il linguaggio java è parecchio strampalato, per esempio:

    * manca l’eredità multipla che ha addirittura python, addirittura hanno inventato le interfacce che non servono a nulla (le classi astratte bastano e avanzano)

    * non ha l’overloading degli operatori, basta utilizzare il tipo BigDecimal per rendersi conto della sciocchezza che hanno fatto

    * per comparare le stringhe non si può usare == ma bisogna usare .equal()

    * c’è una gestione paranoica dei null, bisogna sempre controllare lo stato di una variabile perchè è sempre in agguato il crash del programma

    e così via..

  • # 104
    Cesare Di Mauro (Autore del post)
     scrive: 

    In parte condivido, ma non sull’ereditarietà multipla: quella con le interfacce lo è sicuramente. Certo, non è espressiva come quella che può offrire C++ o Python, ma è una forma di ereditarietà multipla che permette di risolvere parecchi problemi.

    Sui null, invece, non capisco: perché non si dovrebbero controllare?

  • # 105
    floriano
     scrive: 

    le interfacce non creano l’eredità multipla, visto che i metodi che non si trovano nell’unica classe che si può ereditare bisogna comunque riscriverli ex-novo.

    per i null intendo dire che di default le stringhe valgono null e gli interi altrettanto; ogni volta che si crea un oggetto oppure arriva da qualche form bisogna controllare che sia diverso da null sennò quasi tutte le operazioni con esso creano delle eccezioni (in giro per la rete ho trovato questo
    http://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java)

  • # 106
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, gli interi in Java non valgono null, ma 0. Forse ti riferisci agli interi “boxed”, perché il tipo int (come pure byte, short e long, single e double) è “primitivo”.

    Le stringhe sono puntatori a oggetti (come gli array), per cui è logico che possano essere inizializzate a null (se semplicemente dichiarate).

    I controlli sono indispensabili se vogliamo codice “robusto” e, soprattutto, un comportamento “desiderato” per l’applicazione.
    Ma questo lo si fa con qualunque linguaggio quando si utilizza l’allocazione dinamica: non è un problema esclusivo di Java.

    Riguardo all’ereditarietà multipla, anche quella a “classe singola ma con interfacce” è considerata tale in letteratura.
    Poi è chiaro che, come ho già detto prima, non ha la stessa potenza espressiva, ma è uno strumento abbastanza flessibile.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.