Java tornerà in Windows. Aggiornato

Sun raccoglie un primo successo nella causa antitrust contro Microsoft e ottiene dal tribunale l'obbligo, per Microsoft, di reintegrare il supporto in Windows alla più recente versione di Java. Appello in vista

Baltimora (USA) - Sun vince il primo round della battaglia legale intrapresa all'inizio del 2002 contro Microsoft e ottiene dal tribunale un'ingiunzione preliminare che, a partire dal 2003, obbligherà la propria rivale ad includere la tecnologia Java in tutte le versioni di Windows, incluso XP.

Come si ricorderà, fu proprio con l'introduzione di Windows XP che Microsoft decise di cessare il supporto alla tecnologia Java omettendo d'integrare, nella nuova versione del proprio sistema operativo, la macchina virtuale necessaria per eseguire le applet e i programmi scritti nel linguaggio di Sun, lo stesso alla base della più temibile e diretta piattaforma avversaria di MS.NET.

Di recente Microsoft ha tentato di dirimere la questione includendo, nel Service Pack 1 per Windows XP, la propria Java virtual machine. Sun sostiene però da tempo che la macchina virtuale di Microsoft sia ormai del tutto obsoleta e che la sua reintroduzione nel service pack per Windows XP non abbia avuto altro fine se non quello di manipolare il processo antitrust.
"Questa decisione è una grande vittoria per i consumatori, che avranno sui loro PC la migliore e più recente tecnologia Java", ha dichiarato Mike Morris, vice presidente di Sun, facendo dunque intendere che Microsoft sarà obbligata ad integrare in Windows una virtual machine aggiornata. "Questa è una vittoria per tutti quegli sviluppatori che scrivono applicazioni in grado di girare su tutti questi PC".

"La decisione - ha commentato ancora Morris - contribuirà a garantire che l'attuale e compatibile tecnologia Java venga inclusa sul desktop di ogni consumatore e metta fine alla pratica con cui Microsoft sta cercando di frammentare la piattaforma Java".

Da parte sua Microsoft difende le proprie strategie sostenendo che Java non è un pulcino bisognoso di protezione ma una tecnologia rivale utilizzata da almeno la metà degli sviluppatori di tutto il mondo.

"Sarebbe come obbligare la Coca Cola - ha commentato Bill Gates, chief software architect di Microsoft, riferendosi alla sentenza - ad includere in ogni sua confezione una lattina di Pepsi".

Durante il recente processo antitrust federale, conclusosi fra l'altro con una sostanziale vittoria di Microsoft, i giudici imputarono al big di Redmond l'aver voluto allontanare il controllo di Java da Sun attraverso la creazione di una versione "corrotta" del linguaggio in grado di funzionare solo con Windows. Fu sulla base di queste accuse che nel 1998 Sun intentò a Microsoft una causa che si sarebbe conclusa solo tre anni più tardi con il risarcimento di 20 milioni di dollari a favore di Sun.

Sulla scorta della sentenza che ha condannato Microsoft per abuso di posizione dominante, e andando oltre quanto discusso nel procedimento antitrust contro l'azienda di Bill Gates, il giudice Motz ha scritto nelle 42 pagine della sentenza che "Microsoft ha abbracciato Java con il solo scopo di distruggerlo e di privare i consumatori dei pieni benefici dell'invenzione di Sun".

Microsoft ha già annunciato il ricorso in appello, ma le possibilità di ribaltare la sentenza, secondo alcuni analisti, non sono molte.
TAG: mercato
300 Commenti alla Notizia Java tornerà in Windows. Aggiornato
Ordina
  • E faccio le stesse cose di java
    senza contare l'enorme disponibilita' del c che ti rende
    i programmi veramente veloci.
    provate a scrivere un sistema embedded con le macro
    e poi postatemi un benchmarkA bocca aperta
    Java lo uso solo su degli application server per qualche ditta
    a cui devo pompare il contratto haha
    non+autenticato
  • > E faccio le stesse cose di java
    Questa è una affermazione talmente impossibile che non ci soffermeremo neppure...

    > senza contare l'enorme disponibilita' del c
    > che ti rende i programmi veramente veloci.
    L'"enorme disponibilità"? Nel senso che è molto gentile? I programmi "veramente veloci" in C non sono poi così più veloci di quelli in java, se guardi il link seguente. E, come insegnano l'80% delle aziende del mondo, non è poi così indispensabile, quella velocità: se per ottenerla ci metti 10 anni in più a scrivere il programma, il mercato ti rende obsoleto prima che tu abbia finito...

    > provate a scrivere un sistema embedded con
    > le macro e poi postatemi un benchmarkA bocca aperta
    Ma che minchia stai dicendo?? Comunque ti dispiacerà sapere che un sacco di aziende si stanno orientando su java, per sviluppare applicazioni per telefonini, pda, ecc.

    > Java lo uso solo su degli application server
    > per qualche ditta a cui devo pompare il contratto haha
    Acc, peccato che non puoi realizzare delle belle intranet aziendali o dei sistemi informativi generici in C: i tuoi clienti sarebbero così contenti! haha
  • - Scritto da: baroncelli
    > > E faccio le stesse cose di java
    > Questa è una affermazione talmente
    > impossibile che non ci soffermeremo
    > neppure..

    Be si forse ho detto una michiataA bocca aperta
    intendevo programmi con interfacce grafice.


    > > senza contare l'enorme disponibilita' del
    > c
    > > che ti rende i programmi veramente veloci.
    > L'"enorme disponibilità"? Nel senso che è
    > molto gentile?
    >I programmi "veramente
    > veloci" in C non sono poi così più veloci di
    > quelli in java, se guardi il link seguente.

    Be per le interfacce grafiche non c'e che dire
    (uso sia gtk che qt ) e non mi sembrano per niente lenti
    al contrario dei pachidermi java.

    > E, come insegnano l'80% delle aziende del
    > mondo, non è poi così indispensabile, quella
    > velocità: se per ottenerla ci metti 10 anni

    Concordo con questa affermazione,ad ogni modo
    mi trovo molto bene col c per via di altri fattori (oltre
    la velocita di esecuzione ) quali una vasta gamma di librerie,
    framework completi (autoconf automake libtool ) crosscompiling,
    e per finire ci metterei pure riutilizzo di codice.


    > in più a scrivere il programma, il mercato
    > ti rende obsoleto prima che tu abbia
    > finito...

    Con l'esperienza i programmatori imparano a riutilizzare
    di tutto, difficilmente mi metto a scrivere un render per gestire
    il bilinear-filtering o l'antialiasing prendo le librerie che mi servono
    e le integro sul progetto.
    Senza contare che progetti medio grandi 51.000 70.000 linee
    di codice di solito li faccio assieme un team.

    java lo uso anchio ma mi limito a sfruttarlo per farci qualche
    cazzatina frontend.

    > > provate a scrivere un sistema embedded con
    > > le macro e poi postatemi un benchmarkA bocca aperta
    > Ma che minchia stai dicendo?? Comunque ti
    > dispiacerà sapere che un sacco di aziende si
    > stanno orientando su java, per sviluppare
    > applicazioni per telefonini, pda, ecc.

    Non mi parlare degli EPOC e sopratutto dei Symbian.
    a qyesto punto preferisco gli smartphone .D
    tutto questo software sui telefonini di adesso e' soltanto
    fumo negli occhi.
    per embedded intendevo chioschi per videoteche casse
    touchscreen router.



    > Acc, peccato che non puoi realizzare delle
    > belle intranet aziendali o dei sistemi
    > informativi generici in C: i tuoi clienti
    > sarebbero così contenti! haha

    Tutto questo infoware e' in crisi a causa della natura stessa
    di java che costringe gli sviluppatori a scrivere 800 EJB pattern
    per fare delle semplici query (manco transazionali i piu usano mysql ) manco si dovesse scrivere un ATM per qualche banca.
    Ciao
    non+autenticato

  • - Scritto da: baroncelli
    > > E faccio le stesse cose di java
    > Questa è una affermazione talmente
    > impossibile che non ci soffermeremo
    > neppure...
    >
    Forse perche' non hai argomrntazioni per controbattere.
    Pensi che la VM sia scritta in Java?

    > > senza contare l'enorme disponibilita' del
    > c
    > > che ti rende i programmi veramente veloci.
    > L'"enorme disponibilità"? Nel senso che è
    > molto gentile? I programmi "veramente
    > veloci" in C non sono poi così più veloci di
    > quelli in java, se guardi il link seguente.
    > E, come insegnano l'80% delle aziende del
    > mondo, non è poi così indispensabile, quella
    > velocità: se per ottenerla ci metti 10 anni
    > in più a scrivere il programma, il mercato
    > ti rende obsoleto prima che tu abbia
    > finito...
    >
    Su questo posso anche concordare con te; anche con il Basic si fa' prima che con il C.
    Per quanto riguarda il tempo impiegato, beh, dipende anche da quanto sei bravo a programmare.

    > > provate a scrivere un sistema embedded con
    > > le macro e poi postatemi un benchmarkA bocca aperta
    > Ma che minchia stai dicendo?? Comunque ti
    > dispiacerà sapere che un sacco di aziende si
    > stanno orientando su java, per sviluppare
    > applicazioni per telefonini, pda, ecc.
    >
    Uhm... Telefonini... PDA... WOW, quelle si che sono vere applicazioni Embedded. Mai sentito parlare di automazione industriale? Prova a scrivere in JAVA un software in grado di riconoscere e scartare dei pezzi all'interno di una catena di montaggio, dove scorrono a parecchi metri al secondo, poi ne riparliamo.

    > > Java lo uso solo su degli application
    > server
    > > per qualche ditta a cui devo pompare il
    > contratto haha
    > Acc, peccato che non puoi realizzare delle
    > belle intranet aziendali o dei sistemi
    > informativi generici in C: i tuoi clienti
    > sarebbero così contenti! haha
    >
    E cosa lo impedisce?
  • Ora, io non vorrei risultare sempre pedante, però leggo ancora troppo spesso che "java sarà sempre più lento di applicazioni C o C++". Questo tipo di affermazioni sono decisamente fuorvianti, e tendono solo a propagandare pregiudizi decisamente scorretti.

    Ora, è chiaro che quello che è importante, in un linguaggio - piattaforma, non è esclusivamente la performance pura: aspetti come i tool a disposizione, la robustezza delle applicazioni che vengono generate, ecc. sono importanti. Indubbiamente, però, un linguaggio che offra performance che sono di un ordine di grandezza rispetto ad altri, è come minimo sicuramente inadatto per particolari campi.

    La domanda, allora, è: java come LINGUAGGIO è lento o no? La risposta è NO, e chiunque programmi in java lo sa da anni: sono lente alcune applicazioni con interfaccia grafica programmata in Swing e programmata MALE. Chiunque abbia visto applicazioni recenti non-swing (come eclipse) o Swing come IDEA lo sa. Eppure si continuano a sentire persone dichiarare che "un'applicazione in c++ sarà sempre più veloce".

    Ora: fermo restando che l'importante è che un'applicazione sia VELOCE ABBASTANZA da fare quello che deve fare (sia questo fornire pagine dinamiche al richiesto numero di utenti web o gestire l'email di un individuo tramite un mail client), esistono sempre più risultati che mostrano che java non è veloce solo in maniera "confrontabile" con i linguaggi compilati, ma che in alcuni casi è PIU' veloce. E in altri è più lento, ok.

    Ma veniamo al dunque: com'è possibile, dirà chi è completamente digiuno di queste cose? La risposta sta nel tipo di ottimizzazioni che possono applicare le moderne virtual machine: queste implementano delle forme di ottimizzazione DINAMICA e ADATTATIVA che tende a compilare, ri-compilare, e ottimizzare il codice man mano che l'applicazione si esegue, in modo tale da migliorare progressivamente le performance, sulla base di analisi sul funzionamento del programma.

    Ora, questo tende a dare ottimi risultati nel campo delle applicazioni server, buoni risultati in quello delle applicazioni client, ma in particolari settori si è sempre diffusa l'idea che java "non sia adatto". Ad esempio, nel calcolo numerico puro, ciò che importa è avere algoritmi super-ottimizzati e software che performa ai massimi livelli. Ora, ha fatto scalpore, recentemente, un benchmark corredato di articolo scientifico che mostrava come "java è inadatto per il calcolo numerico". L'autore lo ha postato su varie fonti online, e la voce si è sparsa presto.

    La comunità dei javisti ha innanzitutto indicato come alcuni aspetti del benchmark fossero programmati male, e ha proposto delle correzioni, che però non hanno modificato di molto la sostanza dell'articolo: java performava da 4 a 8 volte peggio dell'equivalente applicazione scritta in C++. Poi qualcuno ha suggerito all'autore di passare al JDK IBM: questo è in generale più veloce di quello Sun, ma soprattutto tende ad essere particolarmente performante sul calcolo numerico. Il risultato è stato un post dell'autore dell'articolo su javalobby.org, che diceva: "Switching to the IBM JDK improved matters considerably. I'm so impressed by the IBM JDK that I've switched to it as my default. Java now performs as well as gcc on many tests. The remaining perfromance problem appears to lie in the use of trigonometric functions; apparently, JDK 1.4 defaults the Math.* ****ions to StrictMath.*. This is fine when cross-platform results must agree... but it isn't necessary for most applications. Does anyone know how I can "switch" the default library back to native code?"

    Ora, per chi non ama leggere l'inglese, traduco la parte clou: "java ora mostra le stesse performance di gcc sulla maggior parte dei test", e i rimanenti problemi di performance dipendono dal fatto che il jdk 1.4 ha come default l'applicazione di algoritmi di calcolo "portabili" che sono più lenti di come potrebbero essere, ma possono essere sostituiti da algoritmi più veloci...

    Quindi, se persino su un benchmark di CALCOLO NUMERICO, che misura performance pure della virtual machine si mostra che java può essere "veloce come" un linguaggio compilato (C++), se i report di Osvaldo Doederlein su javalobby mostrano da ANNI come le performance di java siano confrontabili a quelle di applicazioni scritte in C++, la mia domanda è PERCHE' DEVO ANCORA LEGGERE GENTE CHE SCRIVE CHE JAVA E' 'LENTO'?????
  • Aggiungo alcuni link:

    http://www.javalobby.org/members/jpr/index.jsp (il java performance report su javalobby)

    http://www.javalobby.org/threadMode3.jsp?message=3...
    (il thread su javalobby in cui il tizio comincia riportando i risultati della sua ricerca, e conclude dicendo che con il jdk ibm è tutto diverso, e ha scoperto che java performa come GCC).

    http://www.javaperformancetuning.com (un sito pieno zeppo di risorse sul performance tuning in java)
    non+autenticato
  • - Scritto da: baroncelli
    > Ora, io non vorrei risultare sempre pedante,
    > però leggo ancora troppo spesso che "java
    > sarà sempre più lento di applicazioni C o

    Nel caso di applicazioni server Java e` ottimo. La velocita` in quel contesto e` soprattutto i/o oppure network bounded..
    non+autenticato

  • - Scritto da: baroncelli
    > Ora, io non vorrei risultare sempre pedante,
    > però leggo ancora troppo spesso che "java
    > sarà sempre più lento di applicazioni C o
    > C++". Questo tipo di affermazioni sono
    > decisamente fuorvianti, e tendono solo a
    > propagandare pregiudizi decisamente
    > scorretti.
    >
    > Ora, è chiaro che quello che è importante,
    > in un linguaggio - piattaforma, non è
    > esclusivamente la performance pura: aspetti
    > come i tool a disposizione, la robustezza
    > delle applicazioni che vengono generate,
    > ecc. sono importanti. Indubbiamente, però,
    > un linguaggio che offra performance che sono
    > di un ordine di grandezza rispetto ad altri,
    > è come minimo sicuramente inadatto per
    > particolari campi.
    >
    > La domanda, allora, è: java come LINGUAGGIO
    > è lento o no? La risposta è NO, e chiunque
    > programmi in java lo sa da anni: sono lente
    > alcune applicazioni con interfaccia grafica
    > programmata in Swing e programmata MALE.
    > Chiunque abbia visto applicazioni recenti
    > non-swing (come eclipse) o Swing come IDEA
    > lo sa. Eppure si continuano a sentire
    > persone dichiarare che "un'applicazione in
    > c++ sarà sempre più veloce".
    >
    > Ora: fermo restando che l'importante è che
    > un'applicazione sia VELOCE ABBASTANZA da
    > fare quello che deve fare (sia questo
    > fornire pagine dinamiche al richiesto numero
    > di utenti web o gestire l'email di un
    > individuo tramite un mail client), esistono
    > sempre più risultati che mostrano che java
    > non è veloce solo in maniera "confrontabile"
    > con i linguaggi compilati, ma che in alcuni
    > casi è PIU' veloce. E in altri è più lento,
    > ok.
    >
    Vedi qual'e' il problema, tu hai ristretto il campo d'azione a tutto cio' che riguarda il Web ed Internet, dove e' abbastanza chiaro che dovendo in qualche modo interagire con le persone, la velocita' di esecuzione non ha particolare importanza, e comunque ci pensano spesso le infrastrutture stesse a creare dei colli di bottiglia.
    Prova per una volta a sostenere le tue tesi, ampliano un po' il campo d'azione. Ti accorgerai che il Software non e' limitato ad Applicazioni Web o Interfaccia Utente.

    > Ma veniamo al dunque: com'è possibile, dirà
    > chi è completamente digiuno di queste cose?
    > La risposta sta nel tipo di ottimizzazioni
    > che possono applicare le moderne virtual
    > machine: queste implementano delle forme di
    > ottimizzazione DINAMICA e ADATTATIVA che
    > tende a compilare, ri-compilare, e
    > ottimizzare il codice man mano che
    > l'applicazione si esegue, in modo tale da
    > migliorare progressivamente le performance,
    > sulla base di analisi sul funzionamento del
    > programma.
    >
    Con quale linguaggio e' stato ottenuto tutto questo, con JAVA? oppure le VM sono scritte utilizzando altri linguaggi, non so', il C?

    > Ora, questo tende a dare ottimi risultati
    > nel campo delle applicazioni server, buoni
    > risultati in quello delle applicazioni
    > client, ma in particolari settori si è
    > sempre diffusa l'idea che java "non sia
    > adatto". Ad esempio, nel calcolo numerico
    > puro, ciò che importa è avere algoritmi
    > super-ottimizzati e software che performa ai
    > massimi livelli. Ora, ha fatto scalpore,
    > recentemente, un benchmark corredato di
    > articolo scientifico che mostrava come "java
    > è inadatto per il calcolo numerico".
    > L'autore lo ha postato su varie fonti
    > online, e la voce si è sparsa presto.
    >
    Dai, il calcolo numerico non mi sembra poi un buon elemento di paragone, ed anche i benchmark in fondo non sono un mezzo "particolarmente attendibile", dato che spesso sono calibrati in funzione della conoscenza del modello di ottimizzazione del Software che vogliamo testare.

    > La comunità dei javisti ha innanzitutto
    > indicato come alcuni aspetti del benchmark
    > fossero programmati male, e ha proposto
    > delle correzioni, che però non hanno
    > modificato di molto la sostanza
    > dell'articolo: java performava da 4 a 8
    > volte peggio dell'equivalente applicazione
    > scritta in C++. Poi qualcuno ha suggerito
    > all'autore di passare al JDK IBM: questo è
    > in generale più veloce di quello Sun, ma
    > soprattutto tende ad essere particolarmente
    > performante sul calcolo numerico. Il
    > risultato è stato un post dell'autore
    > dell'articolo su javalobby.org, che diceva:
    > "Switching to the IBM JDK improved matters
    > considerably. I'm so impressed by the IBM
    > JDK that I've switched to it as my default.
    > Java now performs as well as gcc on many
    > tests. The remaining perfromance problem
    > appears to lie in the use of trigonometric
    > functions; apparently, JDK 1.4 defaults the
    > Math.* ****ions to StrictMath.*. This is
    > fine when cross-platform results must
    > agree... but it isn't necessary for most
    > applications. Does anyone know how I can
    > "switch" the default library back to native
    > code?"
    >
    > Ora, per chi non ama leggere l'inglese,
    > traduco la parte clou: "java ora mostra le
    > stesse performance di gcc sulla maggior
    > parte dei test", e i rimanenti problemi di
    > performance dipendono dal fatto che il jdk
    > 1.4 ha come default l'applicazione di
    > algoritmi di calcolo "portabili" che sono
    > più lenti di come potrebbero essere, ma
    > possono essere sostituiti da algoritmi più
    > veloci...
    >
    > Quindi, se persino su un benchmark di
    > CALCOLO NUMERICO, che misura performance
    > pure della virtual machine si mostra che
    > java può essere "veloce come" un linguaggio
    > compilato (C++), se i report di Osvaldo
    > Doederlein su javalobby mostrano da ANNI
    > come le performance di java siano
    > confrontabili a quelle di applicazioni
    > scritte in C++, la mia domanda è PERCHE'
    > DEVO ANCORA LEGGERE GENTE CHE SCRIVE CHE
    > JAVA E' 'LENTO'?????
    >
    Per lo stesso motivo per cui si continua a dire la stessa cose del Visual Basic.
    E' solo frutto di un preconcetto nei confronti di quei linguaggi, dichiaratamente pseudo-interpretati, o che comunque necessitano di un VM per poter essere eseguiti.
    Il mio personale parere, e' che il tentativo sia quello di confrontare due linguaggi che non possono essere confrontati, perche' hanno ruoli diversi, come e' diverso il Target delle applicazioni.
    non+autenticato

  • - Scritto da: baroncelli
    > Ora, io non vorrei risultare sempre pedante,
    > Quindi, se persino su un benchmark di
    > CALCOLO NUMERICO, che misura performance
    > pure della virtual machine si mostra che
    > java può essere "veloce come" un linguaggio
    > compilato (C++), se i report di Osvaldo
    > Doederlein su javalobby mostrano da ANNI
    > come le performance di java siano
    > confrontabili a quelle di applicazioni
    > scritte in C++, la mia domanda è PERCHE'
    > DEVO ANCORA LEGGERE GENTE CHE SCRIVE CHE
    > JAVA E' 'LENTO'?????

    Java non è lento per come è fatto il linguaggio.
    Java è "lento" quando è interpretato, ma la stessa cosa succede anche con gli altri linguaggi, po tutti dipende dall'ottimizzazione del'interprete.
    Perche' il C è molto veloce, semplice, perche' il codice generato deve solo eseguire i comandi,senza pensare a generare errori di run-time come ad esempio fa il basic.

    Se prendi un programma scritto in C, lo fai intepretato, ci aggiungi al codice il controllo degli errori di run-time, ottieni un programma sicuramente piu' lento di uno compilato in codice nativo.

    Poi tutto dipende anche dall'ottimizzazione del compilatore.

    Non a caso per il java si parla voler fare la compilazione in tempo reale.

    Il fatto che i report dicono che il java è piu' o meno veloce, non miinteressa, prendete dieci compilatori di pascal e otterrete dieci risultati differenti e questo non vuole dire che il pascal è scarso, ma che dipende anche da chi genera il codice, fino a prova contraria in java si genera un p-code.


    ciao

    .

  • - Scritto da: baroncelli

    > scritte in C++, la mia domanda è PERCHE'
    > DEVO ANCORA LEGGERE GENTE CHE
    > SCRIVE CHE JAVA E' 'LENTO'?????

    Perché questo corrisponde a verità assoluta su scala macroscopica.
    Java è assai più lento del C++, in generale, e quest'ultimo a sua volta è più lento del C "puro" per via delle enormi sovrastrutture passive che si porta dietro, dalla gestione delle eccezioni al RTTI, alla shallowed copy, alla garbage collection e via citando.
    Lo stesso vale per VB, peraltro.

    Vogliamo confrontare in tempo di esecuzione e spazio occupato un qualsiasi programma java con lo stesso programma scritto in C con sezioni critiche in assembly accuratamente ottimizzato a mano ? Sì, se vogliamo ridere un pò, possiamo farlo, ma il risultato è già ovvio e noto a priori. Dunque, java è più lento di quasi tutti gli altri linguaggi noti (ivi inclusi Eiffel, Ada e qualsiasi altro linguaggio abbia un compilatore decente e zero pretese di "portabilità").

    I benchmark o i tweaks per applicazioni particolari non hanno alcuna rilevanza: un linguaggio interpretato, con o senza JIT, sarà SEMPRE più lento dell'output di un compilatore ottimizzante (meglio ancora, ottimizzato a mano nelle sezioni critiche) che genera codice assembly nativo, per la stessa presenza della VM. La misura statistica delle performance si può adattare ai propri bisogni, ma l'approccio alla Tanenbaum/Sebesta è il più corretto per stimare le deficienze di linguaggi ed ambienti inutilmente complessi (il primo dei quali era Oberon di Klaus Wirth, per la cronaca: non contento di aver creato uno dei peggiori linguaggi di programmazione al mondo[*], ha cercato anche di peggiorarsi ulteriormente).

    L'unico vero motivo dell'esistenza e della sopravvivenza di questi linguaggini alla moda, ultraportabili, ad altissimo livello di astrazione (a parte i little languages come AWK, che hanno una storia a sè) è che oggi si usano con noncuranza processori con velocità di clock adatte ad un forno a microonde e quantitativi di RAM che avrebbero mandato al fallimento, a costo dell'epoca, la NASA o la stessa AT&T ai tempi di Multics. Ed il 95% delle applicazioni consumer, quelle correlate al "webbe" e roba simile, non ha alcuna particolare esigenza di ottimizzazione o soft realtime.

    [*]Pascal: pseudo linguaggio di programmazione così denominato in onore di un grandissimo scienziato. Il quale, se lo sapesse, si rivolterebbe nella tomba.
    non+autenticato
  • Allora, premetto che sto lavorando da tempo ad un'applicazione scientifica interamente scritta in java e sono sinceramente interessato a capire se esistano delle differenze _reali_ (non parlo di roba come 5-10%) rispetto a del codice c++/Fortran. Da quello che ho visto finora, le differenze esistono.

    Personalmente ho fatto parecchi test utilizzando diverse routine mirate (essenzialmente funzioni trigonometriche su valori a doppia precisione) testandole su varie vm, e la velocità del codice java fluttua in genere tra un 15% e un 40% di quella del codice c++, quindi un gap abbastanza consistente, ma nel nostro caso non determinante perchè l'analisi dei dati richiede comunque un tempo nell'ordine dei secondi. Ovvio che in altri casi una differenza di questo tipo sia sufficiente per orientare la scelta verso altri linguaggi.

    Vedendo i risultati del tizio dunque non sono rimasto troppo sorpreso; tutto sommato sono rimasto più sorpreso dalla differenza tra il idk 1.3 e 1.4, sun o ibm che sia: praticamente la versione 1.4 è circa il 100% più lenta.

    "The problem with Java's performance is not my code or my lack of Java skills -- the real problem is that Java 1.4 is slow. Both the Sun and IBM JVMs lost significant performance in the move from 1.3.1 to 1.4, whether due to a new language requirement or other factors. My faith in Java is severely shaken when applications lose significant performance by "upgrading" to the current release of Java.

    Java 1.4 added many new features to the language and packages; however, changing from version 1.3 to 1.4 should not double run-times! Nor am I comforted by the problems of Sun's 1.3.1 "server" JVM."

    ora, dire che "java può essere "veloce come" un linguaggio compilato (C++)" coglie solo un aspetto molto particolare dell'articolo, che invito a leggere per intero:

    http://www.coyotegulch.com/reviews/almabench.html

    Difatti è vero che in un caso particolare (JVM 1.3.1 di ibm vs gcc) il codice java è risultato allineato con il codice c++, ma ovviamente se si va a guardare la media o i risultati migliori di entrambe le soluzioni i risultati sono ben diversi.
    Se poi consideriamo che il jdk 1.3 è stato definito dalla stessa sun "obsoleto", facendo un confronto tra il risultato migliore prodotto dal compilatore c++ della intel e il risultato migliore ottenuto con la vm 1.4 della ibm otteniamo che il codice c++ risulta da 6 a 6,5 volte più performante del codice java, a dir poco scoraggiante.
    Anche usando la vm 1.3 ibm (quella che usa ancora la libreria Math.*) abbiamo in ogni caso una differenza di 3,5 volte, e direi che non sono noccioline.

    Quindi, il tuo modo volutamente parziale di presentare le cose non si discosta molto da quello di chi dice "java fa schifo, punto e basta". La realtà è molto più complessa. Ovvio che per il target a cui è rivolto java la velocità pura risulta secondaria: il denaro risparmiato nello sviluppo e soprattutto nel debug è di gran lunga superiore a quello investito in hardware più performante, e quindi negli ambienti enterprise java è un'ottima soluzione.

    >la mia domanda è PERCHE' DEVO ANCORA LEGGERE GENTE CHE SCRIVE CHE JAVA E' 'LENTO'?????

    Perchè per moltissimi aspetti (tra cui il calcolo in virgola mobile) è vero. E' inutile che ti strappi i capelli e dai dell'imbecille a chiunque dica il contrario, affermando che le cosiddette "ottimizzazioni dinamiche e adattative" della vm sarebbero in grado di far ottenere delle performance superiori al codice compilato. In alcune rare situazioni questo può essere vero, come si affanna a sostenere la sun presentando benchmark fatti ad hoc, ma in altri casi no.

    In ogni caso java è un ottimo linguaggio con caratteristiche molto interessanti, così come lo sono il c, il c++, o il fortran, il pascal o A bocca aperta

    Il bello è che ognuno è libero di scegliere lo strumento che più risponde alle sue esigenze, senza per questo dover continuamente cercare consenso presso altri o insultare chi non ha le stesse sue esigenze/gusti.

    non+autenticato

  • - Scritto da: Anonimo



    hai provato a compilare direttamente in codice nativo utilizzando gcj ?
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    >
    > hai provato a compilare direttamente in
    > codice nativo utilizzando gcj ?

    Dunque, usando gcj le prestazioni sono in genere allineate a quelle del g++, buono quindi, il problema è che usando codice nativo perdiamo in flessibilità e portabilità (che poi è il motivo principale per cui stiamo usando java nel nostro progetto) e aumentano notevolmente il tempo e le problematiche per distribuire l'applicazione sulle tre piattaforme su cui attualmente gira.
    Sinceramente non so fino a che punto venga utilizzata, attualmente, la possibilità di eseguire codice nativo in java; magari qualcuno ci può illuminare a riguardo?


    non+autenticato
  • > Personalmente ho fatto parecchi test
    > utilizzando diverse routine mirate
    > (essenzialmente funzioni trigonometriche su
    > valori a doppia precisione) testandole su
    > varie vm, e la velocità del codice java
    > fluttua in genere tra un 15% e un 40% di
    > quella del codice c++, quindi un gap

    Queste differenze possono autmentare nel caso in cui usi una moltitudine di oggetti (grossi numeri) in quanto la gestione della memoria in Java è diretta dall GC e quando questa scatta, tutti si fermano.

    > abbastanza consistente, ma nel nostro caso
    > non determinante perchè l'analisi dei dati
    > richiede comunque un tempo nell'ordine dei
    > secondi. Ovvio che in altri casi una
    > differenza di questo tipo sia sufficiente
    > per orientare la scelta verso altri
    > linguaggi.

    Metti ambienti di sumilazione stocastica...

    > Vedendo i risultati del tizio dunque non
    > sono rimasto troppo sorpreso; tutto sommato
    > sono rimasto più sorpreso dalla differenza
    > tra il idk 1.3 e 1.4, sun o ibm che sia:
    > praticamente la versione 1.4 è circa il 100%
    > più lenta.

    Questo è un fatto negativo in quanto un aggiornamento dovrebbe portare miglioramenti prestazionali e bug fix del preesistente, e nuove features.

    > Ovvio che per il target a cui è rivolto java
    > la velocità pura risulta secondaria: il
    > denaro risparmiato nello sviluppo e
    > soprattutto nel debug è di gran lunga
    > superiore a quello investito in hardware più
    > performante, e quindi negli ambienti
    > enterprise java è un'ottima soluzione.

    Certamente. Il punto è che bisogna fare chiarezza di architetture. SUN ci ha rotto le scatole spingendo all'inverosimile gli EJB. Ed ora fa un dietrofront perchè si è accorta che agli sviluppatori ed architetti non piace...troppo laborioso, lento, non scalabile, ecc.
    Questo è un'ambiente che se sei conservatore ti ritrovi obsoleto prima di finire l'applicativo, se se non lo sei, ti bruci su tecnologie che non sono state sufficientemente testate ...
    non+autenticato
  • > differenze _reali_ (non parlo di roba come
    > 5-10%) rispetto a del codice c++/Fortran. Da
    > quello che ho visto finora, le differenze
    > esistono.
    E questo in effetti mi pare ragionevole.

    > Personalmente ho fatto parecchi test
    > utilizzando diverse routine mirate
    > (essenzialmente funzioni trigonometriche su
    > valori a doppia precisione) testandole su
    > varie vm, e la velocità del codice java
    > fluttua in genere tra un 15% e un 40% di
    > quella del codice c++, quindi un gap
    > abbastanza consistente,
    Mah, dunque, seguendo gli sviluppi del caso "number crunching" in effetti si evince che i risultati di "lentezza" residui non sono dovuti tanto alla lentezza di esecuzione del bytecode (che, appunto, non esiste, visto che il bytecode viene compilato dinamicamente nei punti che consumano cicli, e presumibilmente quindi in tutti i punti che interessano le performance di un programma di calcolo numerico), quanto al fatto che le librerie matematiche, particolarmente per le funzioni trigonometriche, non sono molto performanti. In altre parole, quello che si evince dal profilare i benchmark, è che il benchmark non misura le prestazioni del linguaggio o della piattaforma di runtime, ma quelle della libreria matematica. Ovvio che questo possa avere un peso per chi deve fare del calcolo numerico OGGI, ma non dice granché sulle questioni tipo "java sarà sempre più lento di un linguaggio compilato", che rimangono delle idiozie.

    > secondi. Ovvio che in altri casi una
    > differenza di questo tipo sia sufficiente
    > per orientare la scelta verso altri
    > linguaggi.
    Mi pare ragionevole.

    > Vedendo i risultati del tizio dunque non
    > sono rimasto troppo sorpreso; tutto sommato
    > sono rimasto più sorpreso dalla differenza
    > tra il idk 1.3 e 1.4, sun o ibm che sia:
    > praticamente la versione 1.4 è circa il 100%
    > più lenta.
    Sempre seguendo le discussioni di questi giorni, si capisce che sia Sun sia IBM nelle versioni 1.4 hanno deciso di passare il modello di calcolo da una versione "non-strict" ad una versione "strict" per aumentare la portabilità: benché io non capisca esattametne cosa ciò significhi, immagino che abbia a che fare con la precisione dei risultati. Da qualche parte ho letto che è possibile impostare anche sotto 1.4 l'altra modalità, ma non ho capito bene come.

    > "The problem with Java's performance is not
    > my code or my lack of Java skills -- the
    > real problem is that Java 1.4 is slow. Both
    > the Sun and IBM JVMs lost significant
    > performance in the move from 1.3.1 to 1.4,
    > whether due to a new language requirement or
    > other factors. My faith in Java is severely
    > shaken when applications lose significant
    > performance by "upgrading" to the current
    > release of Java.
    Guarda, quello che dice questo tizio può avere un suo senso per una persona il cui mondo sia limitato al calcolo numerico, ma è una puttanata altrove. Chiunque può osservare progressi notevoli nella velocità di applicazioni sia con GUI sia server-side, con le versioni 1.4. Se il tizio avesse fatto qualche ricerca in più, prima di tranciare le sue conclusioni, avrebbe scoperto le cose che ti ho scritto sopra, e invece ha preferito mettersi a dichiarare al mondo affermazioni definitive, che un giorno dopo l'altro vengono corrette per i miglioramenti nei benchmark ottenuti su piattaforme diverse, o con diversi parametri di esecuzione.

    > Difatti è vero che in un caso particolare
    > (JVM 1.3.1 di ibm vs gcc) il codice java è
    > risultato allineato con il codice c++, ma
    > ovviamente se si va a guardare la media o i
    > risultati migliori di entrambe le soluzioni
    > i risultati sono ben diversi.
    Questo è vero: in effetti quando avevo scritto il mio messaggio non avevo ancora letto il testo completo dell'articolo, ma solo le conclusioni che il tizio tirava su javalobby, dichiarandosi molto colpito dai risultati del jdk ibm. Non avevo poi colto il fatto che quando parlava di "velocità rispetto a C++" si riferiva al compilatore gcc, e non a quello di Intel. Rimane comunque il fatto che si tratta di un benchmark che misura le performance delle librerie trigonometriche, e non del "linguaggio": i risultati dipendono dal tempo di calcolo di seni e coseni, non dall'esecuzione del bytecode.

    > la vm 1.4 della ibm otteniamo che il codice
    > c++ risulta da 6 a 6,5 volte più performante
    > del codice java, a dir poco scoraggiante.
    Ok, ma rimangono veri i discorsi di cui sopra sul modello "strict".

    > Quindi, il tuo modo volutamente parziale di
    > presentare le cose non si discosta molto da
    In realtà non era volutamente parziale: mi ero solo basato sulle conclusioni del tizio su javalobby, e ho letto solo dopo l'articolo!

    > Ovvio che per il target a cui è rivolto java
    > la velocità pura risulta secondaria: il
    Uhm: no, in realtà anche la velocità pura ha la sua importanza, ma immagino che in effetti il calcolo numerico puro, sia secondario.

    > affermando che le cosiddette "ottimizzazioni
    > dinamiche e adattative" della vm sarebbero
    > in grado di far ottenere delle performance
    > superiori al codice compilato. In alcune
    Puoi mettere tutte le virgolette che vuoi, ma è verissimo. Non dimenticare che nelle applicazioni che gestiscono i sistemi web o i backend aziendali si usano modelli ad oggetti abbastanza complessi, con gerarchie decisamente profonde, polimorfismo, ecc. I modelli di risoluzione delle chiamate virtuali che possono essere eseguiti con ottimizzazioni adattative a runtime sono per loro stessa natura superiori alle ottimizzazioni statiche che può effettuare un compilatore ottimizzante.

    > rare situazioni questo può essere vero, come
    > si affanna a sostenere la sun presentando
    > benchmark fatti ad hoc, ma in altri casi no.
    Mah, io a dire il vero di benchmark "comparativi" fatti dalla Sun non ne ho mai letti, ma ho sperimentato sulla mia pelle come l'ottimizzazione, ad esempio, dei parametri della garbage collection, o una scelta accurata dei punti in cui fare ottimizzazione sulla base di dati di profiling possano avere impatti radicali sulle performance.

  • ...Che tutte le applicazioni potessero funzionare indipendentemente dalla piattaforma utilizzata e non fossero legate a filo doppio al sistema operativo windows.

    Java e' una minaccia piu' grande di Linux.

    L'idea di non dover dipendere da un solo sistema operativo "capriccioso" come quello della MS non credo che possa dispiacere agli sviluppatori di software anzi e' proprio una grande idea.

    O no?
    non+autenticato
  • > L'idea di non dover dipendere da un solo
    > sistema operativo "capriccioso" come quello
    > della MS non credo che possa dispiacere agli
    > sviluppatori di software anzi e' proprio una
    > grande idea.
    >
    beh, tu preferisci quindi far girare le tue applicazioni sulla JVM, che è cmq una tecnologia proprietaria. Dalla padella alla brace...
    > O no?
    vedi sopra Sorride
    non+autenticato
  • > beh, tu preferisci quindi far girare le tue
    > applicazioni sulla JVM, che è cmq una
    > tecnologia proprietaria. Dalla padella alla
    > brace...
    > > O no?
    > vedi sopra Sorride

    Sviluppare con strumenti della Microsoft vuol dire obbligare i propri clienti all'acquisto di windows mentre utilizzando java sono liberi di scegliere il so in base alle loro esigenze.

    Inoltre se il cliente non desidera utilizzare windows dovra' rivolgersi ad un mio concorrente che sviluppa in java Triste.

    java sembra essere il male minore rispetto a windows.

    non+autenticato

  • - Scritto da: Anonimo
    > > beh, tu preferisci quindi far girare le
    > tue
    > > applicazioni sulla JVM, che è cmq una
    > > tecnologia proprietaria. Dalla padella
    > alla
    > > brace...
    > > > O no?
    > > vedi sopra Sorride
    >
    > Sviluppare con strumenti della Microsoft
    > vuol dire obbligare i propri clienti
    > all'acquisto di windows mentre utilizzando
    > java sono liberi di scegliere il so in base
    > alle loro esigenze.
    >
    > Inoltre se il cliente non desidera
    > utilizzare windows dovra' rivolgersi ad un
    > mio concorrente che sviluppa in java Triste.
    >
    > java sembra essere il male minore rispetto a
    > windows.
    >
    Fino a quando SUN, vedendo che JAVA prende il sopravvento, decidera' di privilegiare la versione che gira sul proprio Hardware, costringendo tu e i tuoi clienti ad acquistare la sua piattaforma, che non costa nemmeno poco, cosi', dal monopolio Software MS, saremo passati al monopolio Hardware SUN.
    Uhm... bella prospettiva.
  • > Fino a quando SUN, vedendo che JAVA prende
    > il sopravvento, decidera' di privilegiare la
    > versione che gira sul proprio Hardware,
    > costringendo tu e i tuoi clienti ad
    > acquistare la sua piattaforma, che non costa
    > nemmeno poco, cosi', dal monopolio Software
    > MS, saremo passati al monopolio Hardware
    > SUN.
    > Uhm... bella prospettiva.
    Dire che usare java obbliga ad acquistare sistemi Sun è una sonora idiozia. In realtà la maggior parte dei benchmark (tipo il famoso Volano Report http://www.volano.com/report/ ) mostra che le virtual machine più veloci sono quelle IBM 1.3 che girano su Linux, seguite da Bea JRockit su piattaforma windows. In quasi tutti i benchmark, le VM Sun sono indietro, e generalmente tendono a performare più o meno nello stesso modo sia su Solaris sia su Windows. La mia azienda, ad esempio, che ha 5 server Sun in produzione, ha recentemente acquistato altrettante macchine IBM per passare ad un'architettura ibrida per un po', e poi eventualmente stabilizzarsi su sistemi IBM - Linux - Java - Tomcat/JBoss ecc.

  • - Scritto da: baroncelli
    > > Fino a quando SUN, vedendo che JAVA prende
    > > il sopravvento, decidera' di privilegiare
    > la
    > > versione che gira sul proprio Hardware,
    > > costringendo tu e i tuoi clienti ad
    > > acquistare la sua piattaforma, che non
    > costa
    > > nemmeno poco, cosi', dal monopolio
    > Software
    > > MS, saremo passati al monopolio Hardware
    > > SUN.
    > > Uhm... bella prospettiva.
    > Dire che usare java obbliga ad acquistare
    > sistemi Sun è una sonora idiozia. In realtà
    > la maggior parte dei benchmark (tipo il
    > famoso Volano Report
    > http://www.volano.com/report/ ) mostra che
    > le virtual machine più veloci sono quelle
    > IBM 1.3 che girano su Linux, seguite da Bea
    > JRockit su piattaforma windows. In quasi
    > tutti i benchmark, le VM Sun sono indietro,
    > e generalmente tendono a performare più o
    > meno nello stesso modo sia su Solaris sia su
    > Windows. La mia azienda, ad esempio, che ha
    > 5 server Sun in produzione, ha recentemente
    > acquistato altrettante macchine IBM per
    > passare ad un'architettura ibrida per un
    > po', e poi eventualmente stabilizzarsi su
    > sistemi IBM - Linux - Java - Tomcat/JBoss
    > ecc.
    >
    Ma leggi o fai finta, ho scritto "decidera' di privilegiare", non ho detto che e' lo stato dell'arte. E' una mia ipotesi, che certamente lascia il temo che trova, ma resta comunque una delle possibili evoluzioni.
    non+autenticato
  • > E' una mia ipotesi, che
    > certamente lascia il temo che trova,
    Confermo.
  • > Sviluppare con strumenti della Microsoft
    > vuol dire obbligare i propri clienti
    > all'acquisto di windows mentre utilizzando
    > java sono liberi di scegliere il so in base
    > alle loro esigenze.
    >
    ed infatti basta usare piattafore _davvero_ aperte, tipo ECMA335 o, se preferisci chiamarlo altrimenti, .NET
    > Inoltre se il cliente non desidera
    > utilizzare windows dovra' rivolgersi ad un
    > mio concorrente che sviluppa in java Triste.
    >
    ah, si?
    beh, per Linux e Unix-like potrebbe usare Mono:
    http://www.go-mono.org
    oppure, per altri scopi, DotGNU:
    http://www.gnu.org/projects/dotgnu/
    se, invece, vuoi solo studiare, puoi usare Rotor (disponibile per Windows, FreeBSD e MacOS X), e vedere il sorgente di MS:
    http://msdn.microsoft.com/downloads/default.asp?ur...

    Per sviluppare senza dare un euro a MS potresti usare #develop (http://www.icsharpcode.net/OpenSource/SD/Download/...), WebMatrix (http://www.asp.net) ed in futuro Eclipse.
    > java sembra essere il male minore rispetto a
    > windows.
    >
    ed infatti nessuno ti obbliga ad usare Wwindows! Sorride
    Allora, quale è la _vera_ piattaforma aperta? (Attenzioe! La domanda è subdola, e richiede di collegare il cervello di studiare _davvero_ prima di rispondere)
    non+autenticato

  • - Scritto da: Anonimo
    > ...Che tutte le applicazioni potessero
    > funzionare indipendentemente dalla
    > piattaforma utilizzata e non fossero legate
    > a filo doppio al sistema operativo windows.
    >
    > Java e' una minaccia piu' grande di Linux.
    >
    > L'idea di non dover dipendere da un solo
    > sistema operativo "capriccioso" come quello
    > della MS non credo che possa dispiacere agli
    > sviluppatori di software anzi e' proprio una
    > grande idea.
    >
    E' una questione di scelte.
    A mio avviso ( e sono uno sviluppatore C/C++ ), tutto dipende dalle caratteristiche che deve avere il tuo software. A meno che non facciano un processore ad-hoc per JAVA ( anche se in quel caso saresti costretto a cambiare processore ogni volta che vengono aggiunte nuove funzionalita' alla VM ), non puoi paragonare la velocita' di esecuzione di un Software Nativo, con uno scritto in JAVA, a parita' di macchina.
    Io penso che ci sia spazio per l'uno e per l'altro, basta non accanirsi nel voler trovare una soluzione che faccia contenti tutti. Anche nella vita ognuno ha i propri interessi, che fortunatamente divergono da quelli degli altri; ti immagini se tutti avessimo gli stessi interessi. Che noia. Sorride

    > O no?
    non+autenticato
  • > A mio avviso ( e sono uno sviluppatore C/C++
    > ), tutto dipende dalle caratteristiche che
    > deve avere il tuo software. A meno che non
    > facciano un processore ad-hoc per JAVA (
    > anche se in quel caso saresti costretto a
    > cambiare processore ogni volta che vengono
    > aggiunte nuove funzionalita' alla VM ), non
    > puoi paragonare la velocita' di esecuzione
    > di un Software Nativo, con uno scritto in
    > JAVA, a parita' di macchina.
    Uhm! In realtà c'è chi pensa di "poter paragonare" (che non significa dichiarare a priori "java è più veloce", ma può portare a interessanti considerazioni, su questo tipo di affermazioni tipo "java sarà sempre più lento"). Ti invito a leggere attentamente questo link: http://www.javalobby.org/members/jpr/index.jsp
  • Finalmente hanno fatto una cosa giusta dato
    che ultimamente Microsoft si stava dando da sola
    la zappa sui piedi.

    Per esempio l'installazione dei
    SP (Service Pack) per Office XP 2002 falliva
    su Windows 2000 SP3 perche` non era installata
    la Java Machine 2 di Sun !

    Tralascio il penoso fatto che questi SP x Office
    piu` che correggere bachi li mascherano in modo
    che Word non faccia crash !

    Non so perche` ma una vocina mi dice che
    Office 2002 funziona bene su XP ma non su Win2000
    e quindi prendo atto della conseguente subdola
    deduzione logica Con la lingua fuori

    non+autenticato

  • - Scritto da: Anonimo
    > Finalmente hanno fatto una cosa giusta dato
    > che ultimamente Microsoft si stava dando da
    > sola
    > la zappa sui piedi.
    >
    > Per esempio l'installazione dei
    > SP (Service Pack) per Office XP 2002 falliva
    > su Windows 2000 SP3 perche` non era
    > installata
    > la Java Machine 2 di Sun !
    >
    E' successo solo a te?
    A me non risulta, mai accaduto.

    > Tralascio il penoso fatto che questi SP x
    > Office
    > piu` che correggere bachi li mascherano in
    > modo
    > che Word non faccia crash !
    >
    > Non so perche` ma una vocina mi dice che
    > Office 2002 funziona bene su XP ma non su
    > Win2000
    > e quindi prendo atto della conseguente
    > subdola
    > deduzione logica Con la lingua fuori
    >
    Sei in errore, io uso Office XP (2002) anche su Windows 2000, e funziona perfettamente.
    Ripeto, forse sei sfortunato? Sorride
    non+autenticato
  • mi aggiungo..
    ho win 2000 e office xp.. funziona benone, mai un crash..

    mi sa che sei davvero sfortunato..

    Alex
    non+autenticato
  • ...in realtà anche i programmatori .NET dovrebbero esserne ben contenti: ora potranno usare Eclipse in maniera indolore sul loro OS preferito per programmare in C#

    http://www.sys-con.com/webservices/articlenews.cfm...

    (i programmatori PHP dovrebbero essere contenti uguale...).
  • > ...in realtà anche i programmatori .NET
    > dovrebbero esserne ben contenti: ora
    > potranno usare Eclipse in maniera indolore
    > sul loro OS preferito per programmare in C#
    >
    > http://www.sys-con.com/webservices/articlenew
    >
    > (i programmatori PHP dovrebbero essere
    > contenti uguale...).

    In realtà ci sono già #develop (http://www.icsharpcode.net/OpenSource/SD/default.a...), WebMatrix (www.asp.net), ecc. Sono tutti free....
    non+autenticato
  • > In realtà ci sono già #develop
    > (http://www.icsharpcode.net/OpenSource/SD/def
    Sì, ma non sono eclipse...
  • > Sì, ma non sono eclipse...
    li hai _provati_ hai _provato_ VS.NET? Hai _provato_ anche la beta di Everett? Li hai provati _seriamente_? Giacchè temo che molte delle risposte sarebbero: "NO" allora, per favore, taci. Studia e taci.
    non+autenticato
  • > li hai _provati_ hai _provato_ VS.NET? Hai
    > _provato_ anche la beta di Everett? Li hai
    > provati _seriamente_? Giacchè temo che molte
    > delle risposte sarebbero: "NO" allora, per
    > favore, taci. Studia e taci.
    Perché dovrei studiare e tacere mentre tu cianci? E' forse consentito solo ai blateratori aprire bocca? Mi piace troppo fare rosicare i dotnettisti... divertiti, con la _beta_ di _everett_, quando sarai diventato un programmatore abbastanza esperto, tra un paio d'anni, io probabilmente sarò il tuo manager...
  • - Scritto da: baroncelli
    ...
    > http://www.sys-con.com/webservices/articlenew

    Ma grazieeee!        Sorride
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | 4 | 5 | Successiva
(pagina 1/5 - 21 discussioni)