View Full Version : Java vs C++... Sono stanco...
sblantipodi
21-08-2007, 17:14
Io sono stanco di sentir dire che il C++ e' piu' potente di Java e blablabla...
Anche su questo forum si fanno paragoni di questo tipo?
Ditemelo cosi' vado via a priori :asd:
a dire il vero tutti ne dicono un sacco contro il c++ perchè segmentation fault di qua i puntatori di la.. non vedo come puoi dire una cosa del genere.. basta vedere in sondaggione ci sono molti piu fanboy java che lo difendono strenuamente..
a dire il vero tutti ne dicono un sacco contro il c++ perchè segmentation fault di qua i puntatori di la.. non vedo come puoi dire una cosa del genere.. basta vedere in sondaggione ci sono molti piu fanboy java che lo difendono strenuamente..
mi hai chiamato? :O
io ho programmato in c++ e in java e devo dire che IMHO (a parte quelle stronzate del turing del segmentation fault ecc) java è molto piu' bello, facile e leggibile del c++
Anche su questo forum si fanno paragoni di questo tipo?
Ditemelo cosi' vado via a priori :asd:
vattene prima che si scateni una diatriba :asd:
Io sono stanco di sentir dire che il C++ e' piu' potente di Java e blablabla... infatti è più potente, perché è possibile gestire layouts di memoria molto molto più facilmente :O
@cdimauro&PGI-Bis: scusatemi, volevo solo mischiare un po' le carte in tavola :asd: :asd: :asd:
infatti è più potente
http://img374.imageshack.us/img374/8839/noee0py5.gif (https://addons.mozilla.org/firefox/1174)
cdimauro
21-08-2007, 19:13
x 71104. Ma nemmeno rispondo, guarda. Come al solito il forum è pieno di fanatici irrispettosi delle opinioni altri (ovviamente non mi riferisco a te). :rolleyes:
x 71104. Ma nemmeno rispondo, guarda. Come al solito il forum è pieno di fanatici irrispettosi delle opinioni altri (ovviamente non mi riferisco a te). :rolleyes:
e neanche a me, vero? :D
bah, comunque me ne vado :p
franksisca
21-08-2007, 20:08
noooo, erano quasi due giorni che non si apriva una discussione del genere.
comunque, riguardo alla domanda del thread, bhè, come avrai potuto notare, si, anche qui ci sono.
però il bello è che ognuno dice la sua, quindi se anche tu ci dici la tua, saremo felici di accoglierti in famiglia:D
comunque forza java ;)
JAVA È IL MIGLIOR LINGUAGGIO DEL MONDO STRAFIGO POTENTISSIMO CI FACCIO DI TUTTO È SPETTACOLARE ALLA FACCIA DEL C++ DEL CAVOLO CHE I SUOI INVENTORI VENGANO PSICANALIZZATI E POI ELIMINATI PER IL BENE DELL'UMANITààààààààà!!!!!!!
so programmare solo in java, e anche poco:fagiano:
xabraita12
21-08-2007, 22:45
oddio.... forse ho fatto male ad aprire quel sondaggio:doh: :banned: :mad: :mc: :incazzed: :ops2:
franksisca
21-08-2007, 23:24
oddio.... forse ho fatto male ad aprire quel sondaggio:doh: :banned: :mad: :mc: :incazzed: :ops2:
tranquillo, c'era una discussione a settimana sull'argomento.
a proposito, molto ot, ma fek che fine ha fatto???
Demin Black Off
22-08-2007, 00:13
Usa java seriamente e ti renderai conto che per fare "finezze" di alto livello dovrai studiardi il c++, non ci sta niente da fare...
Cmq se per "più potente" si intende "fare più cose..." la risposta è ovvia...
Questo è anche il motivo perchè in sto mese mi so dovuto mettere a studiare il c++...
cdimauro
22-08-2007, 07:21
tranquillo, c'era una discussione a settimana sull'argomento.
Dovrebbero metterle nelle FAQ, ma sono sicuro che nessuno andrebbe a controllare prima di postare.
a proposito, molto ot, ma fek che fine ha fatto???
Non scrive più qui (lo fa, ma molto raramente, soltanto se c'è qualcosa che riguarda il suo lavoro più o meno direttamente).
cdimauro
22-08-2007, 07:23
Usa java seriamente e ti renderai conto che per fare "finezze" di alto livello dovrai studiardi il c++, non ci sta niente da fare...
Lo stesso vale per il C++: per certe "finezze" di alto livello dovrai studiarti Java.
Cmq se per "più potente" si intende "fare più cose..." la risposta è ovvia...
Perfettamente d'accordo, e infatti ne abbiamo parlato in un altro thread. In particolare qui: http://www.hwupgrade.it/forum/showpost.php?p=18329547&postcount=139
Questo è anche il motivo perchè in sto mese mi so dovuto mettere a studiare il c++...
Spero che tu abbia veramente dei buoni motivi (la "potenza", come puoi vedere da quella discussione, non lo è assolutamente) per buttare tempo in un linguaggio così ostico e poco produttivo.
Spero che tu abbia veramente dei buoni motivi (la "potenza", come puoi vedere da quella discussione, non lo è assolutamente) per buttare tempo in un linguaggio così ostico e poco produttivo.
poco produttivo? e in che senso?
poco produttivo? e in che senso? be' suvvia, in confronto alle moderne piattaforme managed... e guarda che il C++ c'ha pure gli anni che c'ha eh...
be' suvvia, in confronto alle moderne piattaforme managed... e guarda che il C++ c'ha pure gli anni che c'ha eh...
sono d'accordo che abbia un discreto numero di anni alle spalle, ma di sicuro non è questo che lo può rendere poco produttivo.
io lo trovo ancora utilizzatissimo in moltissimi ambienti e non vedo perchè cambiarlo.
sblantipodi
22-08-2007, 12:26
a proposito, molto ot, ma fek che fine ha fatto???
Ma FEK non era andato via da questo forum?
Era stato trattato molto male, dopo tutto quello che ha dato al forum... bah...
se lo merita hwupgrade...
Un tipo come FEK non poteva che dare lustro a questo forum...
Non ce lo siamo saputi tenere e adesso... Siamo senza di lui :cry:
sblantipodi
22-08-2007, 12:28
Spero che tu abbia veramente dei buoni motivi (la "potenza", come puoi vedere da quella discussione, non lo è assolutamente) per buttare tempo in un linguaggio così ostico e poco produttivo.
Io credo che cdimauro stia scherzando :D
sblantipodi
22-08-2007, 12:30
be' suvvia, in confronto alle moderne piattaforme managed... e guarda che il C++ c'ha pure gli anni che c'ha eh...
scusate l'ot, ma perche' questa signature?
Non credi che dovresti rispettare un po' le idee altrui...
Per alcuni potrebbe significare bestemmia la tua signature :D
sono d'accordo che abbia un discreto numero di anni alle spalle, ma di sicuro non è questo che lo può rendere poco produttivo.
io lo trovo ancora utilizzatissimo in moltissimi ambienti e non vedo perchè cambiarlo. io preciserei quel "in molti ambienti": diciamo "in molti ambienti dove non esiste di meglio".
scusate l'ot, ma perche' questa signature?
Non credi che dovresti rispettare un po' le idee altrui...
Per alcuni potrebbe significare bestemmia la tua signature :D parli della prima riga :O o delle ultime due :asd: ?
la prima riga non si tocca, è sacrosanta; le ultime due non mi va di toccarle :D
anche perché tante volte non lo sapessi l'ultima riga della mia signature è ispirata ad una famosa frase che fek scrisse su HWU... :)
Io sono stanco di sentir dire che il C++ e' piu' potente di Java e blablabla...
Anche su questo forum si fanno paragoni di questo tipo?
Ditemelo cosi' vado via a priori :asd:
scusa, ma tu hai scritto un programma del genere in java me e tifi per il c++? :eek:
scusa, ma tu hai scritto un programma del genere in java me e tifi per il c++? :eek: veramente no, lui è per Java a quanto sembra.
veramente no, lui è per Java a quanto sembra.
ah, menomale :D
sblantipodi
22-08-2007, 13:43
anche perché tante volte non lo sapessi l'ultima riga della mia signature è ispirata ad una famosa frase che fek scrisse su HWU... :)
Si lo so che FEK aveva idee poco chiare riguardo Linux, in ogni caso ti bannerei :sofico:
scusa, ma tu hai scritto un programma del genere in java me e tifi per il c++? :eek:
Sai qual'e' il fatto? Io non tifo nemmeno allo stadio :)
Adoro il Java e lo preferisco per sviluppare applicazioni rapide o per le applicazioni dove meglio si adatta una tecnologia di questo tipo, pero' non vedo che senso abbia paragonarlo al C++ :)
Sono due linguaggi troppo diversi, dipende da qual'e' il problema che si deve risolvere e poi scegliere il linguaggio + adatto.
Quindi perche' scegliere un vincitore o un vinto?
sblantipodi
22-08-2007, 13:46
veramente no, lui è per Java a quanto sembra.
Come ho detto su non sono ne' per Java ne' per C++.
Alcune applicazioni preferisco scriverle in Java altre trovo inevitabile scriverle in C++...
Non mi sembra una cosa strana no? :stordita:
cdimauro
22-08-2007, 13:48
poco produttivo? e in che senso?
sono d'accordo che abbia un discreto numero di anni alle spalle, ma di sicuro non è questo che lo può rendere poco produttivo.
io lo trovo ancora utilizzatissimo in moltissimi ambienti e non vedo perchè cambiarlo.
Il fatto che sia ancora molto usato NULLA nulla consente di affermare sulla sua produttività: sono due concetti completamente diversi.
Esempio:
def SetNames(self, BaseName, Extension, Filters):
self.Extension = Extension
Words = (Filters['BaseName'] if 'BaseName' in Filters else BaseName).split('|')
self.BaseName = ''.join(Words)
self.ItemName = Filters['ItemName'] if 'ItemName' in Filters else ''.join(((Word[ : -1] if Word[-1] == 's' else Word) for Word in Words))
self.EntityName = ''.join((Word.capitalize() for Word in Words))
self.FileName = self.BaseName + '.' + Extension
self.ArchiveName = BaseName + '.zip'
Sarei curioso di vedere in quanto tempo e quanto codice sarebbe necessario per fare la stessa cosa in C++ (è un metodo che prende due stringhe e un dizionario come parametri), e mantenendo pure una discreta leggibilità. ;)
cdimauro
22-08-2007, 13:50
Ma FEK non era andato via da questo forum?
Era stato trattato molto male, dopo tutto quello che ha dato al forum... bah...
se lo merita hwupgrade...
Un tipo come FEK non poteva che dare lustro a questo forum...
Non ce lo siamo saputi tenere e adesso... Siamo senza di lui :cry:
E' inutile discuterne: ognuno va dove trova un ambiente a lui conveniente.
cdimauro
22-08-2007, 13:50
Io credo che cdimauro stia scherzando :D
cdimauro non scherzava. ;)
cdimauro
22-08-2007, 13:52
Si lo so che FEK aveva idee poco chiare riguardo Linux, in ogni caso ti bannerei :sofico:
Vatti a rivedere alcuni suoi messaggi scritti nella sezione Linux (sempre se sono rimasti), e poi dimmi se aveva le idee poco chiare. ;)
sblantipodi
22-08-2007, 13:52
Il fatto che sia ancora molto usato NULLA nulla consente di affermare sulla sua produttività: sono due concetti completamente diversi.
Sarei curioso di vedere in quanto tempo e quanto codice sarebbe necessario per fare la stessa cosa in C++ (è un metodo che prende due stringhe e un dizionario come parametri), e mantenendo pure una discreta leggibilità. ;)
Paragoni/affermazioni del genere da te non me le aspettavo. :stordita:
Quindi per te dato che esistono altri linguaggi il C++ e' da buttare?
Dovremmo dirlo alla Microsoft o alla gente come FEK di darsi una svegliata :D
PS: Tempo fa dicesti che il mio Bench era un giocattolino :)
Volevo solo dirti che il Team Leader della sezione Java di Nokia Corporation non la pensa come te dato che FPC Bench e' stato presentato al Nokia Tech Days: Focus on Mobile Experience, Russia direttamente da lui. :)
Link (https://mktools.forum.nokia.com/pics/Java__Flash_development_on_Nokia_platforms_Lahtinen.pdf)
Forse tu conosci verita' superiori rispetto a questi "grandi dell'informatica", dovremmo avvisarli :)
sblantipodi
22-08-2007, 13:59
Vatti a rivedere alcuni suoi messaggi scritti nella sezione Linux (sempre se sono rimasti), e poi dimmi se aveva le idee poco chiare. ;)
Questo significa non rispettare le idee altrui.
Io utilizzo Linux da quasi un decennio e lo utilizzo normalmente come tu usi windows per quello che mi serve...
E' ovvio che dipende dall'utilizzo che se ne fa del PC, un game developer come FEK e' normale che preferisca Windows, ma per molti altri compiti scegliere windows non ha senso...
CMQ fine OT, scusateci.
sblantipodi
22-08-2007, 14:01
cdimauro non scherzava. ;)
Dovremmo dirlo a FEK di lasciar perdere il C++ e passare al Java o al C#.
Ma che discorso sensa senso....
Ti ricordavo un professionista... Eri tu? :confused:
cdimauro
22-08-2007, 14:05
Paragoni/affermazioni del genere da te non me le aspettavo. :stordita:
Quindi per te dato che esistono altri linguaggi il C++ e' da buttare?
Dovremmo dirlo alla Microsoft o alla gente come FEK di darsi una svegliata :D
Sì, sono decisamente da buttare. Infatti non è un caso che MS punti molto su C#, che è un linguaggio notoriamente managed, e che i programmatori cominciano a sviluppare giochi con C# e l'ultimo XDK, che è basato su questo linguaggio.
Inoltre linguaggi come Python e LUA oggi rappresentano la scelta d'elezione per implementare la parte di scripting dei videogiochi.
Non solo: il prossimo s.o. MS, che arriverà fra 3 anni, a quanto pare sarà basato interamente sulla piattaforma .NET, il cui runtime è anch'esso notoriamente managed (e alla base di linguaggi come C#, VB.NET, Delphi.NET, IronPython, ecc.. ecc.)
Saranno tutti pazzi...
PS: Tempo fa dicesti che il mio Bench era un giocattolino :)
Ah Adesso ricordo dove t'ho visto.
Volevo solo dirti che il Team Leader della sezione Java di Nokia Corporation non la pensa come te dato che FPC Bench e' stato presentato al Nokia Tech Days: Focus on Mobile Experience, Russia direttamente da lui. :)
Link (https://mktools.forum.nokia.com/pics/Java__Flash_development_on_Nokia_platforms_Lahtinen.pdf)
Forse tu conosci verita' superiori rispetto a questi "grandi dell'informatica", dovremmo avvisarli :)
Che ci vuoi fare: i consigli che ti diedi all'epoca continuano a rimanere validi anche oggi.
Alla Nokia, poi, dovrebbero imparare a programmare, visto che i loro telefonini sono dei colabrodi e non supportano gli standard come si deve (nella mia azienda abbiamo avuto problemi soltanto coi loro modelli, nella ricezione e trasferimento di videochiamate).
cdimauro
22-08-2007, 14:12
Questo significa non rispettare le idee altrui.
Io utilizzo Linux da quasi un decennio e lo utilizzo normalmente come tu usi windows per quello che mi serve...
Mi faresti vedere dove mancherebbe il rispetto delle idee altrui, cortesemente?
Hai mai fatto un giretto nella sezione news e articoli, quando si parla di Microsoft, Windows, Office, ecc.? :rolleyes:
E' ovvio che dipende dall'utilizzo che se ne fa del PC, un game developer come FEK e' normale che preferisca Windows, ma per molti altri compiti scegliere windows non ha senso...
Fran non sceglie Windows senza motivo. Se la LionHead non fosse stata acquisita da MS, probabilmente Fable 2 sarebbe arrivato anche per la PS3, sulla quale notoriamente non gira Windows, ma un s.o. custom (chiamato GameOS).
CMQ fine OT, scusateci.
Se possibile tagliamola, infatti.
cdimauro
22-08-2007, 14:15
Dovremmo dirlo a FEK di lasciar perdere il C++ e passare al Java o al C#.
Ma che discorso sensa senso....
Il discorso senza senso lo fai tu parlando di persone che NON conosci e mettendogli in bocca cose non hanno mai detto né pensato.
Sei amico di Fran? Hai parlato con lui di programmazione? Conosci la sua opinione su C# et similia?
Non credo. Per cui evita di tirarlo in ballo, che è meglio.
Ti ricordavo un professionista... Eri tu? :confused:
Non eri tu che parlavi di mancanza di rispetto verso gli altri utenti? Al solito si predica bene e si razzola male. :rolleyes:
Ma tant'è: il forum non è affatto cambiato. Anzi, continua a peggiorare. As usual...
sblantipodi
22-08-2007, 14:19
Ah Adesso ricordo dove t'ho visto.
Che ci vuoi fare: i consigli che ti diedi all'epoca continuano a rimanere validi anche oggi.
Alla Nokia, poi, dovrebbero imparare a programmare, visto che i loro telefonini sono dei colabrodi e non supportano gli standard come si deve (nella mia azienda abbiamo avuto problemi soltanto coi loro modelli, nella ricezione e trasferimento di videochiamate).
Ahahahaha :D
Scendi dal piedistallo.
Quelli della Nokia non sanno programmare.
E chi sei tu scusa? L'Albert Einstein dell'era tecnologica.
La presunzione e' una cosa che lascia sempre meno spazio all'umilta', chissa' dove andremo a finire.
Il Capo della Sezione Java della Nokia Corporation parla del mio programma a una conferenza formata dai principali sviluppatori della Nokia e tu parli ancora?
Ma tu sei un fenomeno. Albert Einstein e' troppo poco, scusami per il paragone...
UMILTA'. Io sono uno qualunque come te, non sentirti in diritto di giudicare.
sblantipodi
22-08-2007, 14:23
Ma tant'è: il forum non è affatto cambiato. Anzi, continua a peggiorare. As usual...
Sentirsi al di sopra di tutti e sentirsi in diritto di giudicare,
forse tu stai dando il tuo contributo non credi?
PS: Con Caru* ci ho parlato abbastanza da capire che non la pensa come te :)
cdimauro
22-08-2007, 14:28
Ahahahaha :D
Scendi dal piedistallo.
Quelli della Nokia non sanno programmare.
E chi sei tu scusa? L'Albert Einstein dell'era tecnologica.
La presunzione e' una cosa che lascia sempre meno spazio all'umilta', chissa' dove andremo a finire.
Non è certo presunzione prendere atto che DUE persone (un mio collega e un collaboratore esterno; io ho partecipato all'inizio del progetto, ma poi ho lasciato pedere perché ho avuto altro da fare) hanno implementato il protocollo H324M per le videochiamate seguendo lo standard 3G, mentre Nokia coi telefonini che abbiamo provato no.
Questi si chiamano dati di fatto, dalle mie parti.
Il Capo della Sezione Java della Nokia Corporation parla del mio programma a una conferenza formata dai principali sviluppatori della Nokia e tu parli ancora?
Certo che continuo a parlare, perché quello che ti dissi all'epoca è tuttora perfettamente valido.
Se ti vuoi confrontare nuovamente sull'argomento, recupera il thread perché io sono disponibilissimo. Così vediamo chi dei due ha detto cose sensate.
Ma tu sei un fenomeno. Albert Einstein e' troppo poco, scusami per il paragone...
UMILTA'. Io sono uno qualunque come te, non sentirti in diritto di giudicare.
Non serve scomodare Einstein: io giudico per quello che vedo, e all'epoca, come farei anche oggi, t'ho fatto notare cosa ci fosse che non andava e cosa migliorare.
L'umiltà la dovrebbe avere chi di fronte a una critica costruttiva piuttosto che rimboccarsi le maniche e s'incazza per lesa maestà. :rolleyes:
cdimauro
22-08-2007, 14:31
Sentirsi al di sopra di tutti
Questo da dove l'avresti dedotto?
e sentirsi in diritto di giudicare,
Certamente: siamo in un forum libero, no? Se non vuoi sentire i giudizi della gente che legge i tuoi messaggi ti basta fare una cosa semplicissima: non scrivere.
forse tu stai dando il tuo contributo non credi?
Dimostralo.
PS: Con Caru* ci ho parlato abbastanza da capire che non la pensa come te :)
In tal caso vedrò se ha voglia d'intervenire sull'argomento (ha il suo bel da fare, e non so se avrà tempo, ma soprattutto voglia di perderne con queste cose).
sblantipodi
22-08-2007, 14:34
scusa cd perdonami, ma tu cosa hai fatto nella vita per sentirti in diritto di dire che gli informatici della nokia non sanno programmare e che il C++ e' da buttare nel water o che il mio programma e' un cesso nonostante sia usato dal capo sez. java di nokia?
Cioe' non ti seguo, sto parlando con Dijkstra, Torvalds, Stallman?
Scienza, tecnica e filosofia o tutte e tre?
Chi sei? Come puoi dire quello che dici? Che diritto hai?
Cosa hai prodotto nella tua vita?
Ma xche' ogni volta che rimetto piede in questa sezione spunti tu ad accendere flame? :)
Ti do diritto di replica in PVT perche' non credo sia giusto che il forum partecipi a questa stupida discussione inscenata da tutti e due, me compreso.
Scusatemi.
PS: Ho letto adesso la tua signature...
cdimauro
22-08-2007, 14:43
scusa cd perdonami, ma tu cosa hai fatto nella vita per sentirti in diritto di dire che gli informatici della nokia non sanno programmare e che il C++ e' da buttare nel water?
Te l'ho già detto e te lo ripeto: i loro telefonini sono bacati e il loro (numeroso suppongo) staff tecnico non è stato nemmeno capace di implementare il protocollo H324M per le videochiamate. Cosa invece che è riuscita a DUE persone e in circa 4 mesi.
Cosa constatata personalmente (in parte, come dicevo, ho partecipato anch'io al progetto e ne ho comunque seguito gli sviluppi fino alla messa in produzione).
Se non ti basta questo quando vieni dalle parti di Catania fammelo sapere che ti faccio vedere una prova in tempo reale.
Cioe' non ti seguo, sto parlando con Dijkstra, Torvalds, Stallman?
Scienza, tecnica e filosofia o tutte e tre?
Chi sei? Come puoi dire quello che dici? Che diritto hai?
Quello che mi danno semplicemente logica e razionalità, e il diritto di parola del forum.
E, ripeto, non c'è bisogno di scomodare nessuno per fare certe affermazioni.
Io a ciò che dico porto SOLIDE ARGOMENTAZIONI a sostengo, e non mi rifugio dietro a un "tu non sai chi sono io" o a un "ma tu cos'hai fatto" come stai facendo tu.
Al 99,99% chi sposta la discussione sul piano personale è perché non è capace di sostenerla con FATTI e ARGOMENTAZIONI. As usual.
Ma xche' ogni volta che rimetto piede in questa sezione spunti tu ad accendere flame? :)
Me lo stavo chiedendo anch'io, visto che era da mesi che non scrivevo.
Inoltre dovresti dimostrarmi dov'è che avrei acceso il flame, cortesemente.
Ti do diritto di replica in PVT perche' non credo sia giusto che il forum partecipi a questa stupida discussione inscenata da tutti e due, me compreso.
Scusatemi.
Allora mi scrivevi direttamente in PVT, perché lanciare la pietra e nascondere la mano non mi sembra un comportamento corretto.
Se t'interessa, adesso ne parliamo in PVT. Se continuerai a rispondermi in pubblico lo farò anch'io, ovviamente.
PS: Ho letto adesso la tua signature...
E allora?
Dovremmo dirlo a FEK di lasciar perdere il C++ e passare al Java o al C#. fek lo sa già molto bene che a 2007 avanzato, quasi 2008, il C++ è bello che da buttare, altrimenti perché mai avremmo sviluppato Diamond Crush in Java visto che tutti tranne lui volevano farlo in C++?
quando ancora fek era sul forum diceva che lavorava ogni giorno in C++ e ne diceva peste e corna; in effetti è dura rinunciare ai garbage collectors una volta che ci hai fatto l'abitudine.
Ti ricordavo un professionista... Eri tu? :confused: occhio, questa sarebbe da segnalazione eh :D
Si lo so che FEK aveva idee poco chiare riguardo Linux, in ogni caso ti bannerei :sofico: 1) fek aveva le idee poco chiare su Linux? :asd:
per la cronaca, la mia firma è scaturita da una pessima esperienza che io ho personalmente avuto programmando su Linux per un esame (in C!!! ci ero costretto...). e tu che ci hai fatto per adorarlo così tanto, ti sei fatto il desktop XGL con le finestre che dondolano? :rolleyes:
2) hai aperto questo thread con l'evidente scopo di flammare ed infatti lo stai facendo. sei un troll, e di conseguenza sei l'unico da bannare che vedo qui dentro.
cdimauro
22-08-2007, 15:53
x 71104 Esattamente: non ne ha mai fatto mistero, infatti, come non fa mistero della sua passione per Ruby (notoriamente "molto simile" al C++ :asd: ). :p
Per chi realmente lo conosce, ovviamente. ;)
ERRATA CORRIGE: al posto di "ultimo XDK" sostituite XNA (non mi veniva il nome, e sono andato a controllare sul suto della MS. Niente, la mia memoria per i nomi fa veramente pena :muro: ).
In particolare, da qui http://msdn2.microsoft.com/en-us/xna/aa937793.aspx :
Q: What is XNA Game Studio Express?
A: XNA Game Studio Express is a new game development solution targeted primarily at students, hobbyists, and independent game developers. XNA Game Studio Express is based on Visual C# Express 2005 and lets developers create games for both Windows and Xbox 360. XNA Game Studio Express contains the following:
The XNA Framework, a set of managed code development libraries that make it possible for game developers to be more productive when creating games for Windows and the Xbox 360.
The XNA Framework Content Pipeline, a set of tools that allow developers to more easily incorporate 3D content into their games
XNA Game Studio Express also contains a full set of documentation, how-tos, and starter kits that demonstrate how best to use the content pipeline and XNA Framework.
XNA Game Studio Express runs side-by-side with other versions of Visual Studio without interference
XNA Game Studio Express has now been released, and can be found here. It supports both Windows and Xbox 360 game development.
Q: Isn’t managed code in the XNA Framework interpreted and therefore slow?
A: No, it is not interpreted. The IL is just-in-time (JIT) compiled into native code when it is initially loaded by a process, prior to execution. This allows hardware-specific optimizations unique to the PC and Xbox 360 architectures.
Q: How widely used is C# in the gaming industry?
A: The vast majority of game studios recognize the productivity benefits of C# and are already using it for creating internal tools within their studios. There are even a few great games for Windows written using C#. But before the advent of the XNA Framework, doing true cross-platform development with C# targeting both the Windows desktop and the Xbox 360 was not a reality. That’s why we believe the XNA Framework represents an exciting opportunity for game studios.
E' proprio vero: tutti pazzi per il C++...
Interessante 3d !
Tutti pro java, java estremamente potente...
Come cavolo si fanno a catturare gli eventi di sistema in java ?!? A me non sembra poi cosi potente sto linguaggio, ci sto praticamente impazzendo per una banalità ( catturare i doppi click su determinate finestre "esterne", catturare le azioni di riduzione a icona di particolari finestre "esterne" ).
Purtroppo sta cosa la sto facendo sotto c con la libx :cry:
Come cavolo si fanno a catturare gli eventi di sistema in java ?!? A me non sembra poi cosi potente sto linguaggio, ci sto praticamente impazzendo per una banalità ( catturare i doppi click su determinate finestre "esterne", catturare le azioni di riduzione a icona di particolari finestre "esterne" ). in Java non si può e non si deve poter fare, e a dirla tutta non si dovrebbe poter fare neanche utilizzando le chiamate del sistema nei programmi nativi, sempre che il sistema in oggetto sia dotato di un toolkit grafico decente. quello di Win32 ad esempio (costituito da User32+GDI32) ha dei bei difetti in quanto diretta evoluzione della sua versione a 16 bit nata in un'epoca in cui i dinosauri abitavano la terra e la sicurezza informatica era un argomento a cui non si dedicava l'importanza che merita. sono state poste delle soluzioni parziali ad alcuni di questi difetti, soluzioni anche ottime devo dire, ma i problemi ci sono ancora. per esempio inviare messaggi alle finestre di altre applicazioni che non prevedono di ricevere messaggi da processi esterni è scorretto e potrebbe causare comportamenti imprevisti (dovrai dire al tuo cliente che il tuo prodotto funziona in molti casi, ma è scritto in maniera carente e può facilmente causare malfunzionamenti in altri casi). se invece stiamo parlando di utilizzare interfacce come i Windows Hooks allora ritengo che Java non sia in grado a causa del fatto che si tratta di qualcosa di troppo specifico di un solo sistema; le due migliori soluzioni (mutuamente esclusive) in questo caso sono JNI e Managed C++.
Chiudiamola qui...ok ? non avevo visto :|
sblantipodi
22-08-2007, 17:36
Post cancellato, seguo il consiglio di cionci...
non avevo visto :|
Per carità...il tuo messaggio mi sembra più che normale ;)
Non intendevo chiudere la discussione, ma la polemica personale.
mindwings
22-08-2007, 18:35
cut cut tu che ci hai fatto per adorarlo così tanto, ti sei fatto il desktop XGL con le finestre che dondolano? :rolleyes:
Scusa ma questa è da incorniciare :D se un utente usa gnu/linux nn è detto che usi XGL :O , oltre al fatto che le finestre sbriluccicose ci sono anche su Vista...:rolleyes:
Se ti sei trovato male a sviluppare qualcosa in ambito linux la colpa non è di linux:) forse ti sei adattato troppo al SO che già usi da tempo...:p
Ci sono tanti buoni motivi per programmare in ambito gnu/linux:p
mmm sorgenti liberi?:) (se sei curioso e se hai la volontà puoi vedere cio che altre persone hanno sviluppato...)
imho prima di diventare bravi scrittori bisogna essere dei lettori assidui:D
Edit la tua firma contiene 2 frasi mooolto discutibili...
P.s uso indistintamente sia gnu linux che windows xp (al momento java)
cdimauro
22-08-2007, 19:52
Se ti sei trovato male a sviluppare qualcosa in ambito linux la colpa non è di linux:) forse ti sei adattato troppo al SO che già usi da tempo...:p
I s.o. non sono tutti uguali, per cui la tua affermazione è opinabile, visto che ci possono benissimo essere delle cose che si realizzano più facilmente con un s.o. piuttosto che con un altro.
Comunque non so a cosa ha lavorato Alberto e quali problemi ha avuto con Linux.
Ci sono tanti buoni motivi per programmare in ambito gnu/linux:p
Indubbiamente.
mmm sorgenti liberi?:) (se sei curioso e se hai la volontà puoi vedere cio che altre persone hanno sviluppato...)
Dipende. Tante volte passa anche la voglia. Vedi sotto.
imho prima di diventare bravi scrittori bisogna essere dei lettori assidui:D
Certamente, ma lettori assidui di... bravi scrittori. :p
Edit la tua firma contiene 2 frasi mooolto discutibili...
Infatti se n'è discusso, e pure parecchio, in questo forum. :D Non sono frutto della sua immaginazione o di un'avversione preconcetta nei confronti di Linux. ;)
Probabilmente ti sei perso dei thread molto belli e interessanti (anche nella sezione Linux), che hanno fatto storia in questo forum. Peccato.
P.s uso indistintamente sia gnu linux che windows xp (al momento java)
Idem (a lavoro sviluppo su Windows, ma tutte le mie applicazioni girano su server con Red Hat Enterprise o Slackware).
Sì, sono decisamente da buttare. Infatti non è un caso che MS punti molto su C#, che è un linguaggio notoriamente managed, e che i programmatori cominciano a sviluppare giochi con C# e l'ultimo XDK, che è basato su questo linguaggio.
L'ultimo XDK basato su C#? A me proprio non risulta... Mi sa tanto che ti confondi con XNA, Cesare...
Dire che C++ è da buttare secondo me è una cavolata. Come cavolo la fai funzionare la VM senza programmazione low level?
Comunque quando ci fai il manico C++ è un bel linguaggio anche se la produttività di c# o Java non la ottieni sicuramente. C'è da dire però che se programmi con la testa programmare in C++ non risulta così da incubo. Non capisco i super insulti verso i designer del C++... Boh... Produttività di questo topic 0 :P
^TiGeRShArK^
23-08-2007, 00:58
Allora andiamo con ordine:
Cellulari Nokia buggatissimi...
purtroppo è vero.
Lavorando con il Personal Profile e con MIDP 2.0 su Nokia 9500 ho potuto riscontrare diversi bug anche piuttosto rompenti.
Ovviamente dei workaround sono possibili. bhè.. ma è piuttosto antipatico usare un workaround.
Addirittura il PErsona Profile era inusabile in quanto presentava diversi bug "strutturali".
Il profilo CLDC era decisamente meglio da questo punto di vista e a parte qualke workaround, usabilissimo.
Gli emulatori.
Per me sono la vera piaga.
E' mai possibile che appena scrivo una sola riga di codice che mi va ad attivare il bluetooth mi esplode letteralmente l'emulatore? :rolleyes:
(E sul telefono lo stesso codice funzionava perfettamente quindi deduco che il problema non era il mio codice ma l'emulatore.)
Linux:
lasciamo stare le mie esperienza con linux vah ke è meglio :asd:
l'ultima chicca in ordine temporale è quando dovevo cambiare il crontab..
bhè...
che faccio..
scrivo:
crontab -r *INVIO*
guardo lo schermo... :mbe: :stordita:
BESTEMMIONE in diretta...
anzikè scrivere -e ho scritto -r che notoriamente CANCELLA il crontab.
Risultato?
SSH su un'altra macchina e copia incolla della configurazione del crontab (LIEVEMENTE incasinata :muro: )
E tanto per restare in tema voleva vedere cosa accadeva scrivendo il classico rm -rf /* anzikè rm -rf * visto tutti i permessi che avevo in quel momento :muro:
Per me è semplicemente PERICOLOSO linux.
infatti è più potente, perché è possibile gestire layouts di memoria molto molto più facilmente :O
Fosse quello l'una tantum per definire cos'è e cosa non è produttivo in un linguaggio. Per come la vedo io sono due linguaggi paralleli e non affatto mutualmente esclusivi l'uno dall'altro. Inoltre paragonare una "piattaforma" intera ad un "mero" linguaggio, a mio avviso non ha senso. Che piaccia o meno, C++ è un linguaggio con una libreria standard che assolve ai principali compiti che si necessitano in un linguaggio che deve coprire piu' piattaforme possibili, Java è un linguaggio con una libreria che assomiglia molto piu' a un "prodotto". Questo è un vantaggio come può essere uno svantaggio (e certo dipende dall'ambito). In ogni caso, Dio sia lodato se esistono ancora i soli "linguaggi di programmazione" intesi come li si intendeva una volta.
Prendiamo gli elementi sintattici dei due linguaggi: in Java ci sono molte cose di indubbia comodità e produttività, ma anch'esso non ha potuto far a meno di ereditare diversi costrutti da C++ nelle ultime versioni. Chi segue lo sviluppo di Java non può non aver notato che piu' il tempo è passato e piu' ha teso ad assomigliare a C++. In molte situazioni addirittura ho avuto l'impressione che Java avesse fatto delle "inversioni di rotta". Nessuno dei due può essere considerato un OO puro, eppure tecnicamente parlando, in Java si può scrivere solo a oggetti (a meno di voler dichiarare tutti metodi statici, che comunque non è fattibile), in C++ si può fare una programmazione ibrida (e questo è un notevole vantaggio di C++ in determinati ambiti, uno che mi viene in mente per esempio è la programmazione scientifica).
Per quanto riguarda i campi applicativi, c'è poco da discutere: molte cose che si possono fare con C++ in Java non si possono fare, proprio per via della sua natura (e trascurando le questioni sulla produttività). E proprio sulla produttività vorrei porre un appunto: qui dentro sembra che si dichari come vincitore il linguaggio piu' produttivo: ci sono campi dove la produttività non è un componente critico e si predilige la versatilità o altre cose. In quei campi C/C++ è ancora il linguaggio padrone. Per le applicazioni di uso comune, Java è ancora un fantasma, anche se qualcosa si muove in questa direzione. E se vogliamo scomodare la produttività, allora esistono linguaggi molto piu' produttivi di Java, come ad esempio Python e Delphi.
Inoltre, ciò che in Java si "può fare" con la JFC, si può fare anche con C++ utilizzando librerie esterne. Avere una mega libreria ingestibile dalla mente umana tutto in un unico pacchetto è un vantaggio sicuramente quando si cerca di risolvere un problema velocemente e senza avere troppi requisiti di base, ma comunque non è detto che usare classi e metodi delle librerie fornite a corredo sia sempre il metodo ottimale di risolvere un problema o sia sempre il piu' adatto. Swing è sicuramente un progetto ambizioso e fantastico ma purtroppo molte volte non riesce ad assolvere a determinati requisiti. E allora ci si rivolge a SWT, QT Jambi e altro. Ovvero si fa la stessa cosa che si fa con C++: si cercano librerie esterne. Questo per dire che paragonare il solo linguaggio C++ all'intera piattaforma Java è scorretto e tecnicamente non ha senso. Non ha senso villantare le enormi capacità di Java di fare programmazione di rete e la sua gestione nativa dei socket quando in C++ basta per esempio utilizzare netlib per avere pressappoco la stessa potenza. Oppure non ha senso immolare le notevoli capacità e facilità della programmazione multithread in Java quando in C++ basta usare OpenMP.
Piccoli esempi che mi vengono in mente cosi a pelle mentre scrivo, che magari non sono nemmeno estremamente esatti o rappresentativi della situazione, ma che comunque voglioni dire che essere puristi di uno o dell'altro linguaggio, sostanzialmente a mio modo di vedere significa solo precludersi determinate strade. E' impossibile conoscere tutti i linguaggi piu' cool della terra, ma in determinati ambiti ci serve quel determinato linguaggio e non conoscerlo, ignorarlo o semplicemente schifarlo significa essere semplicemente fuori. Anche Prolog in determinate circostanze è richiesto, checcè sembri primitivo o non piu' all'altezza della moderna programmazione logica (tanto per fare un'esempio).
Il discorso è che nessuno vince sull'altro e i motivi mi sembrano anche abbastanza ovvi.
Fosse quello l'una tantum per definire cos'è e cosa non è produttivo in un linguaggio...
[CUT]
:mano: questo è parlare in modo costruttivo.
cdimauro
23-08-2007, 07:40
L'ultimo XDK basato su C#? A me proprio non risulta... Mi sa tanto che ti confondi con XNA, Cesare...
L'avevo scritto sopra: mi riferivo a XNA.
Dire che C++ è da buttare secondo me è una cavolata. Come cavolo la fai funzionare la VM senza programmazione low level?
Qui ci stiamo spostando sulla programmazione di sistema, in cui linguaggi non managed come C/C++, Pascal, ecc. hanno ancora senso, e hai ragione.
Ma a livello di programmazione applicativa, se la piattaforma gira interamente in ambiente managed (come il futuro Windows, a quanto pare) a te come programmatore rimane ben poca scelta: o passi al C++ managed o fai uno sforzo e passi al C# (tanto a livello prestazionale non noteresti particolari cambiamenti).
Comunque quando ci fai il manico C++ è un bel linguaggio anche se la produttività di c# o Java non la ottieni sicuramente.
Già.
Che il C++ sia un bel linguaggio è una questione ampiamente soggettiva: qui si va a gusti. A me non piacciono i linguaggi C-like, particolarmente se hanno una sintassi poco leggibile e/o contorta.
L'ultima volta che ho lavorato col C++ è stato per un paio di mesi fra dicembre e gennaio quando sviluppavo il protocollo H245 per quello H324M (per le videochiamate), ma pur apprezzandone gli strumenti che mi ha messo a disposizione non mi ci trovavo proprio bene. Non ci posso fare niente: non mi piace proprio.
C'è da dire però che se programmi con la testa programmare in C++ non risulta così da incubo.
Federico, con la testa bisognerebbe programmarci sempre, a prescindere dal linguaggio usato!!! :p
Per me il C++ rimane da incubo: troppo diverso da quello che voglio da un linguaggio.
Non capisco i super insulti verso i designer del C++... Boh... Produttività di questo topic 0 :P
Non è il primo e non sarà l'ultimo: capitano spesso thread con scontri titanici fra i sostenitori dei diversi linguaggi.
Perché si sa che il mio linguaggio è più potente del tuo, no? E' un atto di fede razionale per un programmatore. :asd:
cdimauro
23-08-2007, 08:05
Fosse quello l'una tantum per definire cos'è e cosa non è produttivo in un linguaggio. Per come la vedo io sono due linguaggi paralleli e non affatto mutualmente esclusivi l'uno dall'altro. Inoltre paragonare una "piattaforma" intera ad un "mero" linguaggio, a mio avviso non ha senso. Che piaccia o meno, C++ è un linguaggio con una libreria standard che assolve ai principali compiti che si necessitano in un linguaggio che deve coprire piu' piattaforme possibili, Java è un linguaggio con una libreria che assomiglia molto piu' a un "prodotto". Questo è un vantaggio come può essere uno svantaggio (e certo dipende dall'ambito). In ogni caso, Dio sia lodato se esistono ancora i soli "linguaggi di programmazione" intesi come li si intendeva una volta.
Il problema è determinare il criterio (oggettivo) con cui stabilire cosa deve contenere una libreria standard e cosa no. E questo è alquanto difficile (per non dire impossibile) perché non si può definire il concetto di "compito principale".
Infatti per il C++ da tempo viene ventilata l'ipotesi di integrare il progetto BOOST nella libreria standard, che è un framework ENORME che non ha nulla da invidiare a quelli che certi linguaggi/ambienti mettono a disposizione. Se dovesse succedere, cosa faremo? Diremo no, non lo integrate perché si va (molto) oltre i "principali compiti"?
Idem per linguaggi come Delphi: togliere la VCL dall'ambiente è come buttare via una parte consistente e versatile del linguaggio. Ci si fa ben poco.
In soldoni: col solo linguaggio, per quanto "bello" possa sembrarci, non si va molto avanti.
Alla fine anche se il framework in dotazione è enorme, useremo soltanto quello che c'interessa. ;)
Prendiamo gli elementi sintattici dei due linguaggi: in Java ci sono molte cose di indubbia comodità e produttività, ma anch'esso non ha potuto far a meno di ereditare diversi costrutti da C++ nelle ultime versioni. Chi segue lo sviluppo di Java non può non aver notato che piu' il tempo è passato e piu' ha teso ad assomigliare a C++. In molte situazioni addirittura ho avuto l'impressione che Java avesse fatto delle "inversioni di rotta". Nessuno dei due può essere considerato un OO puro, eppure tecnicamente parlando, in Java si può scrivere solo a oggetti (a meno di voler dichiarare tutti metodi statici, che comunque non è fattibile), in C++ si può fare una programmazione ibrida (e questo è un notevole vantaggio di C++ in determinati ambiti, uno che mi viene in mente per esempio è la programmazione scientifica).
Nessuno t'impedisce di usare una sola classe in Java, con metodi statici e realizzare così l'intera applicazione. Quindi "mimando" ciò che avviene con la programmazione strutturata.
Per quanto riguarda i campi applicativi, c'è poco da discutere: molte cose che si possono fare con C++ in Java non si possono fare, proprio per via della sua natura (e trascurando le questioni sulla produttività). E proprio sulla produttività vorrei porre un appunto: qui dentro sembra che si dichari come vincitore il linguaggio piu' produttivo: ci sono campi dove la produttività non è un componente critico e si predilige la versatilità o altre cose. In quei campi C/C++ è ancora il linguaggio padrone. Per le applicazioni di uso comune, Java è ancora un fantasma, anche se qualcosa si muove in questa direzione. E se vogliamo scomodare la produttività, allora esistono linguaggi molto piu' produttivi di Java, come ad esempio Python e Delphi.
I miei linguaggi preferiti. :D In questo periodo li sto usando assieme, grazie al progetto Python for Delphi. :p
A parte ciò, la produttività non è mai un componente critico: bisognerebbe essere sempre quanto più produttivi possibili, a prescindere dal linguaggio usato.
Discorso diverso, invece, è quello dei requisiti di un progetto. Ce ne potrebbe essere qualcuno che esclude a priori la possibilità di utilizzare certi linguaggi (esempio: sviluppo di un driver), ma per le applicazioni di uso comune generalmente non ne esistono di così restrittivi, e qui la produttività di un linguaggio/ambiente è facile che faccia la differenza.
Inoltre, ciò che in Java si "può fare" con la JFC, si può fare anche con C++ utilizzando librerie esterne. Avere una mega libreria ingestibile dalla mente umana tutto in un unico pacchetto è un vantaggio sicuramente quando si cerca di risolvere un problema velocemente e senza avere troppi requisiti di base, ma comunque non è detto che usare classi e metodi delle librerie fornite a corredo sia sempre il metodo ottimale di risolvere un problema o sia sempre il piu' adatto. Swing è sicuramente un progetto ambizioso e fantastico ma purtroppo molte volte non riesce ad assolvere a determinati requisiti. E allora ci si rivolge a SWT, QT Jambi e altro. Ovvero si fa la stessa cosa che si fa con C++: si cercano librerie esterne. Questo per dire che paragonare il solo linguaggio C++ all'intera piattaforma Java è scorretto e tecnicamente non ha senso. Non ha senso villantare le enormi capacità di Java di fare programmazione di rete e la sua gestione nativa dei socket quando in C++ basta per esempio utilizzare netlib per avere pressappoco la stessa potenza. Oppure non ha senso immolare le notevoli capacità e facilità della programmazione multithread in Java quando in C++ basta usare OpenMP.
Sì, ma li devi conoscere questi framework. Java ha l'indubbio vantaggio di mettere già a disposizione un'enorme libreria che copre parecchi settori applicativi. Come programmatore Java sai che se ti serve qualcosa ti basta dare un'occhiata per vedere se c'è la classe che ti serve.
E' un vantaggio non da poco.
Piccoli esempi che mi vengono in mente cosi a pelle mentre scrivo, che magari non sono nemmeno estremamente esatti o rappresentativi della situazione, ma che comunque voglioni dire che essere puristi di uno o dell'altro linguaggio, sostanzialmente a mio modo di vedere significa solo precludersi determinate strade. E' impossibile conoscere tutti i linguaggi piu' cool della terra, ma in determinati ambiti ci serve quel determinato linguaggio e non conoscerlo, ignorarlo o semplicemente schifarlo significa essere semplicemente fuori. Anche Prolog in determinate circostanze è richiesto, checcè sembri primitivo o non piu' all'altezza della moderna programmazione logica (tanto per fare un'esempio).
Il discorso è che nessuno vince sull'altro e i motivi mi sembrano anche abbastanza ovvi.
E' vero, non ci sarebbe una così gran varietà di linguaggi, ma è pure vero che linguaggi nuovi nascono per porre rimedio a deficienze di quelli più vecchi (così come il C++ prima e il D di recente sono nati come estensione del vecchio e farraginoso C).
Conoscere tutti i linguaggi di programmazione (quello che offrono, in particolare) è molto difficile, ma almeno a quelli più recenti dargli un'occhiata non sarebbe male, per quanto scritto poco sopra. ;)
Dire che C++ è da buttare secondo me è una cavolata. Come cavolo la fai funzionare la VM senza programmazione low level? la programmazione di sistema in piattaforme managed a livello puramente teorico per ora (e anche pratico un giorno si spera) è perfettamente possibile: non mi risulta ci sia nulla che la vieti.
Produttività di questo topic 0 :P potevi anche smettere di leggerlo allora...
Intendevo: insultare i designer di un linguaggio perche` non e` figo come l'altro linguaggo ha produttivita` 0.
Dark Phoenix
23-08-2007, 10:26
Secondo me paragonare 2 linguaggi tende all'impossibile...
ipotizziamo di poter fare il conto dei "pro" e dei "contro" (secondo me già ipossibile), fatto questo dovremmo passare al peso dei "pro" e dei "contro", ed infine dovremmo fare una media...
ehm... fare una media.... non si può scegliere un linguaggio secondo una media, (IMHO) un linguaggio va scelto in base ai requisiti che si devono soddisfare.
Aggiungiamo poi l'utilizzo di uno o addirittura più strumenti di middleware... ora siamo proprio troppo all'argo per poter valutare anche la sola produttività, immaginiamo la "potenza".
PS.
:rolleyes: Potenza di un linguaggio... ci si potrebbe scrivere un libro solo su cos'è!
Ma a livello di programmazione applicativa, se la piattaforma gira interamente in ambiente managed (come il futuro Windows, a quanto pare) a te come programmatore rimane ben poca scelta: o passi al C++ managed o fai uno sforzo e passi al C# (tanto a livello prestazionale non noteresti particolari cambiamenti).
già Vista doveva avere queste caratteristiche e dubito che il prossimo windows le avrà. forse se ne parla tra 5 o 6 anni se mai se ne parlerà di nuovo.
comunque sia in C# c'è la parola chiave unsafe ;) e poi windows non è l'unico sistema operativo
Dark Phoenix
23-08-2007, 11:02
comunque sia in C# c'è la parola chiave unsafe ;)
Scusami k0nt3 ho capito che il significato della frase sull'unsafe era più a titolo informativo che altro... ma lasciami fare un esempio :)
C# unsafe
Java native
premetto che non consco i dettagli di entrambi
Chi è meglio?! Sono uguali?! Io non lo so... Ma mi ricordo senpre cosa disse un grande esponente dell'XP...
...per ottimizzare ci sono 2 regole:
1) Non ottimizzare
2) Ricorri alla prima regola
Quindi per ottimizzare è meglio non usarli... Non so se possono servire per altri scopi....
Con questo chiudo la mia teoria, scusate per la pesantezza espressiva :D
Intendevo: insultare i designer di un linguaggio perche` non e` figo come l'altro linguaggo ha produttivita` 0. potevi smettere di leggerlo lo stesso...
cdimauro
23-08-2007, 13:06
Intendevo: insultare i designer di un linguaggio perche` non e` figo come l'altro linguaggo ha produttivita` 0.
Non foss'altro perché manca la definizione di "linguaggio figo". :p
cdimauro
23-08-2007, 13:08
Secondo me paragonare 2 linguaggi tende all'impossibile...
ipotizziamo di poter fare il conto dei "pro" e dei "contro" (secondo me già ipossibile), fatto questo dovremmo passare al peso dei "pro" e dei "contro", ed infine dovremmo fare una media...
ehm... fare una media.... non si può scegliere un linguaggio secondo una media, (IMHO) un linguaggio va scelto in base ai requisiti che si devono soddisfare.
Appunto, perché non esiste e non esisterà mai una metrica oggettiva per confrontare la "potenza" di un linguaggio.
Aggiungiamo poi l'utilizzo di uno o addirittura più strumenti di middleware... ora siamo proprio troppo all'argo per poter valutare anche la sola produttività, immaginiamo la "potenza".
Vedi sopra: la "potenza" per un linguaggio NON si può definire oggettivamente.
Idem per la produttività. L'unico elemento per poterla valutare è l'esperienza individuale.
PS.
:rolleyes: Potenza di un linguaggio... ci si potrebbe scrivere un libro solo su cos'è!
Non credo proprio, visto che non esiste nemmeno una sua definizione (oggettiva). ;)
Semplicemente c'e` linguaggio e linguaggio.
Comunque spero di poter usare managed a lavoro, un giorno :P
cdimauro
23-08-2007, 13:17
già Vista doveva avere queste caratteristiche e dubito che il prossimo windows le avrà. forse se ne parla tra 5 o 6 anni se mai se ne parlerà di nuovo.
Vedremo. E' presto per parlarne.
comunque sia in C# c'è la parola chiave unsafe ;)
Quindi si può usare anche per applicazioni di sistema.
e poi windows non è l'unico sistema operativo
Vero, ma è il più diffuso al momento, per cui è quello a cui presto più attenzione.
cdimauro
23-08-2007, 13:20
potevi smettere di leggerlo lo stesso...
Basta con la vostra guerra personale, Alberto. Se tu e Federico vi volete scannare a causa della vecchia lite che avete avuto, questo non è il posto giusto.
Fermo restando che il motivo per cui vi siete azzuffatti mi pare un'emerita minchiata e non vale la pena rovinare un rapporto d'amicizia per questo motivo.
Fine OT.
cdimauro
23-08-2007, 13:21
Semplicemente c'e` linguaggio e linguaggio.
Comunque spero di poter usare managed a lavoro, un giorno :P
Te lo auguro veramente: ci sono decisamente meno rogne lavorando in un ambiente managed. :)
già Vista doveva avere queste caratteristiche e dubito che il prossimo windows le avrà. forse se ne parla tra 5 o 6 anni se mai se ne parlerà di nuovo. "se mai se ne parlerà di nuovo"? scusate, questo post m'era sfuggito :D
secondo te nel 2020 i kernels saranno scritti ancora in C? quando già nel 2008 esistono esperimenti di sistemi operativi in Java poi... mi spiace per la tua grande passione per le cose ostiche ma il trend è quello: il mondo verge verso il managed, Microsoft sta puntando molto sul .NET tanto che voleva addirittura che esso sostituisse MFC. in parte lo sta facendo, ma purtroppo MFC è molto affermato e dura a morire, percui ne è stato addirittura ripreso lo sviluppo; ma vedrai che finirà tutto in backward compatibility mode.
scusate l'OT:
Basta con la vostra guerra personale, Alberto. Se tu e Federico vi volete scannare a causa della vecchia lite che avete avuto, questo non è il posto giusto. e chi ha detto niente :O
Fermo restando che il motivo per cui vi siete azzuffatti mi pare un'emerita minchiata e non vale la pena rovinare un rapporto d'amicizia per questo motivo. ma tu questo motivo l'hai capito? io no, semplicemente a un certo punto ho iniziato a leggere insulti.
"se mai se ne parlerà di nuovo"? scusate, questo post m'era sfuggito :D
secondo te nel 2020 i kernels saranno scritti ancora in C? quando già nel 2008 esistono esperimenti di sistemi operativi in Java poi... mi spiace per la tua grande passione per le cose ostiche ma il trend è quello: il mondo verge verso il managed, Microsoft sta puntando molto sul .NET tanto che voleva addirittura che esso sostituisse MFC. in parte lo sta facendo, ma purtroppo MFC è molto affermato e dura a morire, percui ne è stato addirittura ripreso lo sviluppo; ma vedrai che finirà tutto in backward compatibility mode.
beh non farmi dire cose che non ho detto.. non è che c'è solo il C o i linguaggi "managed". io sono dell'idea che i sistemi operativi managed non convengono (chissà, magari il futuro cambierà le cose) ma sono a favore di linguaggi più moderni del C perchè aumentano la produttività e diminuiscono le cause di errore
beh non farmi dire cose che non ho detto.. non è che c'è solo il C o i linguaggi "managed". la verità è che per la scrittura dei kernels non ci sono molte vie di mezzo: l'unica che conosco è il C++, per la quale però secondo me Microsoft non passerà.
io sono dell'idea che i sistemi operativi managed non convengono (chissà, magari il futuro cambierà le cose) reinterpreto la frase come: "sono dell'idea che gli ambienti managed non convengano alla programmazione di sistemi operativi". è vero che quelli attualmente esistenti non sono fatti per la programmazione di sistema e il controllo della macchina a basso livello, ma nulla permette di affermare che per definizione un ambiente managed non possa essere progettato a tali scopi. e che una volta progettati "non convengano" è tutto da dimostrare (ma secondo me sprecheresti solo tempo a cercare di dimostrarlo).
ma sono a favore di linguaggi più moderni del C perchè aumentano la produttività e diminuiscono le cause di errore credo che sia opinione abbastanza diffusa che gli errori più brutti che la storia della programmazione abbia mai visto sono quelli relativi alla corruzione di memoria e all'uso errato della memoria allocata dinamicamente. non sono certo gli operatori new e delete a risolvere tale problema: per quanto mi riguarda sono quasi identici a malloc e free (faccio solo meno fatica a scriverli perché richiedono meno caratteri e non serve il cast). il passo decisivo verso una nuova era di gestione della memoria dinamica (lol :D) sono i garbage collectors e gli array managed. gcnew e niente delete. eccezione se sforo un buffer.
cdimauro
23-08-2007, 13:45
beh non farmi dire cose che non ho detto.. non è che c'è solo il C o i linguaggi "managed". io sono dell'idea che i sistemi operativi managed non convengono (chissà, magari il futuro cambierà le cose) ma sono a favore di linguaggi più moderni del C perchè aumentano la produttività e diminuiscono le cause di errore
Perché dici che non convengono?
x Alberto: non ho letto i log della vostra discussione, e nemmeno ho piacere di farlo. Mi piacerebbe, invece, vedervi nuovamente amici come prima.
Comunque ti ho quotato perché ho visto delle risposte piccate nei confronti di Federico. C'è modo e modo di esprimere disaccordo. Il tutto, ovviamente, IMHO. ;)
la programmazione di sistema in piattaforme managed a livello puramente teorico per ora (e anche pratico un giorno si spera) è perfettamente possibile: non mi risulta ci sia nulla che la vieti.
potevi anche smettere di leggerlo allora...
Se non c'è nulla che la vieti, allora perchè parli di livello teorico? Se ci mettiamo a parlare pure del futuro per confrontare i linguaggi di adesso abbiamo finito.
Se non c'è nulla che la vieti, allora perchè parli di livello teorico? dove sarebbe il controsenso? :wtf:
tomminno
23-08-2007, 18:30
Sì, sono decisamente da buttare. Infatti non è un caso che MS punti molto su C#, che è un linguaggio notoriamente managed, e che i programmatori cominciano a sviluppare giochi con C# e l'ultimo XDK, che è basato su questo linguaggio.
Inoltre linguaggi come Python e LUA oggi rappresentano la scelta d'elezione per implementare la parte di scripting dei videogiochi.
Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature.
Non solo: il prossimo s.o. MS, che arriverà fra 3 anni, a quanto pare sarà basato interamente sulla piattaforma .NET, il cui runtime è anch'esso notoriamente managed (e alla base di linguaggi come C#, VB.NET, Delphi.NET, IronPython, ecc.. ecc.)
Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...
Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero ;)
Saranno tutti pazzi...
No tirano acqua al loro mulino, tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas...
Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature. il framework è ancora giuovine, dagli tempo: è solo alla versione 3, Java per esempio è già alla 6. chissà quali difetti aveva Java quando era alla versione 3 :O a partire dalla numerazione delle versioni :D
io mi chiedo sinceramente cosa diamine avessero in mente di fare alla Sun prima di ottenere la major version numero 2.
Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno... perché? :O
Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero ;) in 3 anni lo scrivi un sistema operativo, dipende da quali sono gli obiettivi e quanta manodopera c'è a disposizione. più che altro io dubito che riusciranno veramente a realizzare un intero sistema operativo (kernel compreso) in .NET, Microsoft vorrà anche investire su questa nuova tecnologia ma non così tanto... considera che comunque il tutto dovrebbe continuare a supportare in backward compatibility gli attuali drivers e l'attuale subsystem Win32, altrimenti è un semplice suicidio. raramente però nelle piattaforme managed è facile gestire ciò di cui gli attuali device drivers per Windows hanno bisogno: tutte le struct che essi utilizzano, tra documentate, opache e non documentate, hanno un layout ben preciso che penso in C# sarebbe decisamente meno gestibile che in C. forse è per questo che il C# ha la keyword unsafe :D
No tirano acqua al loro mulino, convertire il mondo alle piattaforme managed secondo te è un comodo loro? certo, lo sarà di sicuro quando il mondo sarà stato convertito ad una piattaforma managed loro, ma vorrei sapere cosa importa a te: la tua vita non può che cambiare in meglio senza i puntatori, e allora stacci senza tante storie, no? ti fanno un grande favore, si vede che meritano un ringraziamento.
tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas... tipo? uno formato universale per i puntatori a metodi? :asd:
comunque non vedo cosa c'entri: hai fatto un'affermazione ("tirano acqua al loro mulino") già di per se' discutibile e pretendi di anche rifilarcela molto alla lontana.
Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno... ah, dimenticavo: http://en.wikipedia.org/wiki/Physical_Address_Extension
ah, dimenticavo: http://en.wikipedia.org/wiki/Physical_Address_Extension
71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.
cdimauro
23-08-2007, 19:12
Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature.
Questo potrebbe succedere se ogni major version rompesse pesantemente la compatibilità col passato, ma non mi risulta.
Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...
Non vedo il nesso. Managed <> enorme quantità di memoria richiesta.
Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero ;)
Con Vista Windows è stato oggetto di una profonda riscrittura (e .NET è stato utilizzato estensivamente), che però non è ancora stata completata: lo sarà, appunto, con la prossima versione.
No tirano acqua al loro mulino, tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas...
Mi sembra normale: il futuro è managed, e ha poco senso continuare a investire su prodotti che diventeranno presto obsoleti (C# ha già rosicchiato una buona fetta del mercato, e considerato che è un linguaggio molto giovane ha tutte le carte in regole per imporsi).
Per il resto, chi non tira acqua al proprio mulino? ;)
cdimauro
23-08-2007, 19:12
71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.
Dipende da come viene usato. ;)
Dipende da come viene usato. ;)
Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.
la verità è che per la scrittura dei kernels non ci sono molte vie di mezzo: l'unica che conosco è il C++, per la quale però secondo me Microsoft non passerà.
il C++ se usato come si deve è una buona alternativa, ma per fare il primo esempio che mi viene in mente c'è anche il D
reinterpreto la frase come: "sono dell'idea che gli ambienti managed non convengano alla programmazione di sistemi operativi". è vero che quelli attualmente esistenti non sono fatti per la programmazione di sistema e il controllo della macchina a basso livello, ma nulla permette di affermare che per definizione un ambiente managed non possa essere progettato a tali scopi. e che una volta progettati "non convengano" è tutto da dimostrare (ma secondo me sprecheresti solo tempo a cercare di dimostrarlo).
io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.
credo che sia opinione abbastanza diffusa che gli errori più brutti che la storia della programmazione abbia mai visto sono quelli relativi alla corruzione di memoria e all'uso errato della memoria allocata dinamicamente. non sono certo gli operatori new e delete a risolvere tale problema: per quanto mi riguarda sono quasi identici a malloc e free (faccio solo meno fatica a scriverli perché richiedono meno caratteri e non serve il cast). il passo decisivo verso una nuova era di gestione della memoria dinamica (lol :D) sono i garbage collectors e gli array managed. gcnew e niente delete. eccezione se sforo un buffer.
non vedo come le cose siano correlate :mbe:
il garbage collector non è una peculiarità degli ambienti managed (anche se sono loro ad averne spinto l'uso) ci sono dei GC anche per il C
la peculiarità degli ambienti managed è quella di girare dentro una VM e attualmente non vedo perchè dovrebbe farlo il SO, in fondo il vantaggio più evidente di queste soluzioni è la portabilità e non mi sembra un'esigenza nella programmazione di un SO.
prendi un linguaggio come il D ad esempio.. offre tutto quello che offrono i linguaggi degli ambienti managed come java e C# (se non di più) e inoltre permette anche di inserire direttamente codice assembly nel sorgente (cosa che nella programmazione di un SO fa sempre comodo)
Un Gabage Collector fatto con gli smart pointer si scrive in 10 minuti con la STL ;)
cdimauro
23-08-2007, 19:25
Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.
Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.
La fregatura col PAE è quando la memoria in più viene usata come la vecchissima EMS dei tempi dell'8086, cioé copiando in segmenti sotto il limite dei 4GB le zone di memoria alta a cui bisogna accedere. :muro:
^TiGeRShArK^
23-08-2007, 19:26
io mi chiedo sinceramente cosa diamine avessero in mente di fare alla Sun prima di ottenere la major version numero 2.
perché? :fagiano:
La fregatura col PAE è quando la memoria in più viene usata come la vecchissima EMS dei tempi dell'8086, cioé copiando in segmenti sotto il limite dei 4GB le zone di memoria alta a cui bisogna accedere. :muro:
E Windows Server come fa ? Se non sbaglio NT e 2000 facevano come hai detto te.
Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.
a me sembra tantissimo per un SO :eek:
^TiGeRShArK^
23-08-2007, 19:27
71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.
confermo :O
Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.
Non solo della tag cache. Mi sembra di aver letto che c'è un'ulteriore livello nella tabella delle pagine e questo mette in crisi il TLB.
^TiGeRShArK^
23-08-2007, 19:32
Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.
da quello che ricordo io quello era il problema minore..
quando dovevi accedere continuamente a pagine situate in blocchi diversi avevi prestazioni decisamente catastrofiche.
Quello era uno dei principali vantaggi dell'uso di x86-64 con programmi che usavano enormi quantità di memoria.
^TiGeRShArK^
23-08-2007, 19:34
io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.
da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione :stordita:
da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione :stordita:
vero! ma in questo caso la portabilità è un'esigenza piuttosto importante :D
cdimauro
23-08-2007, 19:36
il C++ se usato come si deve è una buona alternativa, ma per fare il primo esempio che mi viene in mente c'è anche il D
Concordo: il D lo trovo nettamente migliore del C++.
Per il resto, non credo che i tempi siano maturi per un s.o. totalmente managed.
Personalmente propendo per un piccolo kernel scritto con un linguaggio non-managed e che si occupa di far girare la VM (col JIT compiler) su cui poi poggia tutto il resto.
io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.
Ricordo di aver letto tempo fa che mediamente le prestazioni di un'applicazione managed .NET 2.0 sono del 90% circa rispetto alla stessa, ma compilata in x86 per win32.
Mi sembra un ottimo risultato, con margini di miglioramento per il futuro.
non vedo come le cose siano correlate :mbe:
il garbage collector non è una peculiarità degli ambienti managed (anche se sono loro ad averne spinto l'uso) ci sono dei GC anche per il C
la peculiarità degli ambienti managed è quella di girare dentro una VM e attualmente non vedo perchè dovrebbe farlo il SO, in fondo il vantaggio più evidente di queste soluzioni è la portabilità e non mi sembra un'esigenza nella programmazione di un SO.
Certamente (e ancora per un po').
Comunque la VM di cui parli con .NET si traduce sempre in JIT compiler per l'architettura su cui sta girando l'applicazione.
prendi un linguaggio come il D ad esempio.. offre tutto quello che offrono i linguaggi degli ambienti managed come java e C# (se non di più)
In Java e C# viene usato il GC per TUTTO, e infatti non c'è più spazio per i segmentation fault. Non mi risulta che il D faccia lo stesso.
e inoltre permette anche di inserire direttamente codice assembly nel sorgente (cosa che nella programmazione di un SO fa sempre comodo)
Considerato il ristrettissimo uso che se ne fa dell'assembly (dentro un s.o. in particolare) ormai, non sarebbe una gran perdita.
cdimauro
23-08-2007, 19:37
Un Gabage Collector fatto con gli smart pointer si scrive in 10 minuti con la STL ;)
Ma nessuno lo fa a quanto pare. :p
cdimauro
23-08-2007, 19:38
E Windows Server come fa ? Se non sbaglio NT e 2000 facevano come hai detto te.
Anche Tiger fa così.
E infatti lo ribadisco: la PAE viene usata male così.
cdimauro
23-08-2007, 19:38
a me sembra tantissimo per un SO :eek:
Non sarebbe per il solo s.o., ma per tutto.
cdimauro
23-08-2007, 19:39
Non solo della tag cache. Mi sembra di aver letto che c'è un'ulteriore livello nella tabella delle pagine e questo mette in crisi il TLB.
Francamente non ricordo proprio dell'aggiunta di un ulteriore livello per la decodifica dell'indirizzo virtuale.
Ma nessuno lo fa a quanto pare. :p
cerca bene su internet ;)
^TiGeRShArK^
23-08-2007, 19:40
Ricordo di aver letto tempo fa che mediamente le prestazioni di un'applicazione managed .NET 2.0 sono del 90% circa rispetto alla stessa, ma compilata in x86 per win32.
da vari test che avevo visto qualche tempo fa risultava che C# era in effetti su quei livelli, mentre java arrivava quasi sempre intorno al 95% delle prestazioni con codice non managed, quindi java ad oggi risulta essere addirittura + veloce del C# contrariamente a quanto molti ancora pensano (c'è ancora ki dice ke è un ordine di grandezza + lento del C++ :asd: ).
Avevo visto i risultati del linpack e di non mi ricordo quale altro bench.. forse lo sciencemark..
cdimauro
23-08-2007, 19:40
da quello che ricordo io quello era il problema minore..
quando dovevi accedere continuamente a pagine situate in blocchi diversi avevi prestazioni decisamente catastrofiche.
Quello era uno dei principali vantaggi dell'uso di x86-64 con programmi che usavano enormi quantità di memoria.
Esattamente: la penalizzazione c'è, ma usando la memoria alta come "area di transito".
cdimauro
23-08-2007, 19:43
da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione :stordita:
Sono gli ultimi modelli della famiglia ARM:
http://www.arm.com/products/CPUs/ARM7EJSCore.html
http://www.arm.com/products/CPUs/ARM926EJ-S.html
http://www.arm.com/products/CPUs/ARM1026EJS.html
http://www.arm.com/products/CPUs/ARM1136JF-S.html
http://www.arm.com/products/CPUs/ARM1176.html
In particolare: http://www.arm.com/products/esd/jazelle_home.html
cdimauro
23-08-2007, 19:45
cerca bene su internet ;)
Non avresti qualche link "on-the-fly", cortesemente?
^TiGeRShArK^
23-08-2007, 19:46
Sono gli ultimi modelli della famiglia ARM:
http://www.arm.com/products/CPUs/ARM7EJSCore.html
http://www.arm.com/products/CPUs/ARM926EJ-S.html
http://www.arm.com/products/CPUs/ARM1026EJS.html
http://www.arm.com/products/CPUs/ARM1136JF-S.html
http://www.arm.com/products/CPUs/ARM1176.html
In particolare: http://www.arm.com/products/esd/jazelle_home.html
yep jazelle :O
mi sa ke è lui :p
in effetti mi ricordavo un nome un pò... "gaio" :D
@cdimauro
http://www.google.it/search?q=c%2B%2B+garbage+collector&ie=UTF-8&oe=UTF-8
@cdimauro
http://www.google.it/search?q=c%2B%2B+garbage+collector&ie=UTF-8&oe=UTF-8
Credo che intendesse "ma nessuno ne fa uso" :D
cdimauro
23-08-2007, 19:48
da vari test che avevo visto qualche tempo fa risultava che C# era in effetti su quei livelli, mentre java arrivava quasi sempre intorno al 95% delle prestazioni con codice non managed, quindi java ad oggi risulta essere addirittura + veloce del C# contrariamente a quanto molti ancora pensano
In effetti pensavo anch'io che le prestazioni di .NET 2.0 fossero migliori rispetto a Java.
(c'è ancora ki dice ke è un ordine di grandezza + lento del C++ :asd: ).
Sarà rimasto fermo alla JVM totalmente interpretata: :fagiano:
Avevo visto i risultati del linpack e di non mi ricordo quale altro bench.. forse lo sciencemark..
Il LinPack non lo prenderei come riferimento, perché è basato su UN solo algoritmo (risoluzione di sistemi di equazioni differenziali a matrici sparse, se non ricordomale).
ScienceMark dovrebbe essere costituito da una suite più diversificata, ma sempre orientata ad applicazioni scientifiche.
Sarebbe interessate lo SPEC, che la cui suite è costituta da centinaia di applicazioni delle più disparate tipologie.
cdimauro
23-08-2007, 19:50
Credo che intendesse "ma nessuno ne fa uso" :D
Esattamente. Altrimenti i segmentation fault sarebbero stati debellati da un pezzo (per lo meno col C++). :p
tomminno
23-08-2007, 20:42
perché? :O
Mai dato un'occhita all'occupazione di memoria di un programma C#?
in 3 anni lo scrivi un sistema operativo, dipende da quali sono gli obiettivi e quanta manodopera c'è a disposizione. più che altro io dubito che riusciranno veramente a realizzare un intero sistema operativo (kernel compreso) in .NET, Microsoft vorrà anche investire su questa nuova tecnologia ma non così tanto... considera che comunque il tutto dovrebbe continuare a supportare in backward compatibility gli attuali drivers e l'attuale subsystem Win32, altrimenti è un semplice suicidio. raramente però nelle piattaforme managed è facile gestire ciò di cui gli attuali device drivers per Windows hanno bisogno: tutte le struct che essi utilizzano, tra documentate, opache e non documentate, hanno un layout ben preciso che penso in C# sarebbe decisamente meno gestibile che in C. forse è per questo che il C# ha la keyword unsafe :D
Si pensa che per i dipendenti M$ siano tutte documentate.
Comunque ci hanno messo 6 anni a sviluppare Vista che non è certo un OS scritto da 0, probabilmente ci vorranno almeno 15 anni prima di avere un OS desktop interamente managed.
convertire il mondo alle piattaforme managed secondo te è un comodo loro? certo, lo sarà di sicuro quando il mondo sarà stato convertito ad una piattaforma managed loro, ma vorrei sapere cosa importa a te: la tua vita non può che cambiare in meglio senza i puntatori, e allora stacci senza tante storie, no? ti fanno un grande favore, si vede che meritano un ringraziamento.
Che dire a me non piace assolutamente il C#
tipo? uno formato universale per i puntatori a metodi? :asd:
comunque non vedo cosa c'entri: hai fatto un'affermazione ("tirano acqua al loro mulino") già di per se' discutibile e pretendi di anche rifilarcela molto alla lontana.
Tiri ancora in ballo la storia dei puntatori a metodo quanto non sapevi nemmeno dell'esistenza di auto_ptr? ;)
Che ne dici di una sciocchezzuola come il refactoring, niente a che vedere con il linguaggio in sè ma con l'editor, tant'è che ti fanno scaricare un plugin di terze parti.
O il class designer introdotto solo in Orcas.
O i bug che per essere corretti sei obbligato a comprarti Orcas visto che non sono stati corretti nell'SP1.
O l'intellisense che funziona 100 volte peggio di quello del C#. E non diamo la colpa alla difficoltà della sintassi perchè è proprio il funzionamento ad essere differente.
In M$ stanno spingeno verso il mondo .NET il resto sta già andando a morire.
tomminno
23-08-2007, 21:03
Questo potrebbe succedere se ogni major version rompesse pesantemente la compatibilità col passato, ma non mi risulta.
A livello di sintassi no ma i controlli grafici col C# 2.0 si legano ai datasource con tutto quello che ne consegue, nell'1.1 si usavano i dataset. E siccome C# significa usare l'editor in tutte le sue funzionalità...
Per risolvere i casini creati dall'editor hanno introdotto le partial class, mah.
Hai mai provato a passare da ASP 1.1 a ASP 2.0? Sempre codice C# è ma è assolutamente impossibile farne il porting.
Riuso del codice: se hai scritto delle classi in C# 1.1 che segue il paradigma dei dataset chiaramente farai inmodo che queste manipolino e restituiscano dataset, ma come la mettiamo se volessi riusare quel codice per un programma C# 2.0? La procedura di creazione di un dataset è volutamente macchinosa nel VS2005 proprio per invogliare il passaggio ai datasource, questo comporta che non riutilizzerò mai il codice che ho scritto un anno fa.
Non vedo il nesso. Managed <> enorme quantità di memoria richiesta.
Quindi non ti è mai capitato di notare l'abnorme uso di memoria del C#?
Del resto è del tutto normale, visto tutto quello che si porta dietro.
Con Vista Windows è stato oggetto di una profonda riscrittura (e .NET è stato utilizzato estensivamente), che però non è ancora stata completata: lo sarà, appunto, con la prossima versione.
Non so quale sia la parte dell'OS oggetto della scrittura in .NET so solo che sul mio nuovo portatile con 2GB di ram, senza antivirus mi ritrovo con il 46% di memoria occupata con FF e un paio di finestre aperte.
Se usassi Matlab o Photoshop cosa dovrei fare comprare l'espansione di memoria?
Mi sembra normale: il futuro è managed, e ha poco senso continuare a investire su prodotti che diventeranno presto obsoleti (C# ha già rosicchiato una buona fetta del mercato, e considerato che è un linguaggio molto giovane ha tutte le carte in regole per imporsi).
Per il resto, chi non tira acqua al proprio mulino? ;)
Ma come la mettiamo con il supporto a lungo termine? A lavoro seguo dei progetti nati nel 1998 in VB che già da parecchio tempo sentono il peso degli anni per la mancanza del multithreading e ora per l'impossibilità di girare su Vista. Un analogo programma scritto in C++ non avrebbe di questi problemi.
Sicuro che un programma C# di oggi tra 10 anni non avrà gli stessi problemi?
Non tutti i software sono fatti per durare un paio d'anni.
Comunque per come la vedo io:
1) Dire che C e C++ sono linguaggi obsoleti e morti è una gran cagata. Nuove API nascono ogni giorno per questi linguaggi e nuove estensioni a tali linguaggi vengono presentate con cadenza regolare. Il GPGPU è appannaggio esclusivo del C cosi come molte altre tecnologie. Diciamo che C sta diventando sempre piu' specifico, non per questo è un linguaggio morto. Stesso dicasi per C++. A sostegno di ciò, sarei curioso di sapere quanti dicono che C è un linguaggio morto e sono fermi al C89 (o peggio ancora al K&R), mentre i rispettivi comitati di standardizzazione stanno per rilasciare nuove spec (e meno male che sono morti).
2) C# da quando Java è stato aperto è diventato molto meno interessante rispetto a prima (e comunque è sempre stato un linguaggio dall'evoluzione molto piu' chiusa di Java in ogni caso).
3) I linguaggi di programmazione e che sono riusciti a sopravvivere nel tempo sono sempre stati quelli che non hanno mai intralciato le palle ad altri linguaggi che dominavano in determinati settori e inoltre sono stati portati con successo su molte piattaforme. C# intralcia le palle a troppi linguaggi e come portabilità su sistemi diversi da Microsoft è ancora un giocattolino accademico (e visto il trend lo rimarrà).
Ho una domanda sugli ambienti managed...
Da quello che mi risulta, nei games, la console va sfruttata al 100%... Non parlo tanto di velocità quanto di uso della memoria, per questo spendiamo un sacco di tempo ad elaborare l'allocazione di memoria con lo scopo di ridurre al minimo la frammentazione e svariate altre cose...
Mi chiedo ora.. In ambienti managed cosa succede? .NET per esempio usa la memoria (e altre risorse) come vuole?
Inoltre come sapete i processori hanno istruzioni SSE2/SSE3/ALTIVEC che richiedono strutture dati allineate ed altro. In ambiente managed cosa succede? Puoi sfruttare questi instruction set? Fa tutto .NET / Java?
Il GPGPU è appannaggio esclusivo del C cosi come molte altre tecnologie.
Uhm? Noi GPGPU lo scriviamo in HLSL/CG...
Sono d'accordissimo sul fatto che C++ non è proprio morto per niente... Boost porta avanti un sacco di cose interessanti, inoltre pare che sia prevista una nuova revisione...
Uhm? Noi GPGPU lo scriviamo in HLSL/CG...
Bhè, Cg non significa forse "C for graphics"? ;) Non è forse pesantemente basato su C come sintassi? Comunque io mi riferivo a Cuda, che è molto piu' ad alto livello di HLSL/Cg/GLSL, oltre ad essere piu' adatto al GPGPU (quelli citati sopra sono pur sempre linguaggi pensati per lo shading).
Il futuro del GPGPU è questo e non sarà di certo l'unico esempio. Si possono fare altri milioni di esempi in cui C e C++ sono gli unici e rimarranno tali, per molto ma molto tempo.
Sono d'accordissimo sul fatto che C++ non è proprio morto per niente... Boost porta avanti un sacco di cose interessanti, inoltre pare che sia prevista una nuova revisione...
http://www.artima.com/cppsource/cpp0x.html
^TiGeRShArK^
23-08-2007, 23:45
Sarà rimasto fermo alla JVM totalmente interpretata: :fagiano:
si infatti :asd:
Il LinPack non lo prenderei come riferimento, perché è basato su UN solo algoritmo (risoluzione di sistemi di equazioni differenziali a matrici sparse, se non ricordomale).
ScienceMark dovrebbe essere costituito da una suite più diversificata, ma sempre orientata ad applicazioni scientifiche.
Sarebbe interessate lo SPEC, che la cui suite è costituta da centinaia di applicazioni delle più disparate tipologie.
http://www.shudo.net/jit/perf/
questo è il link ke avevo visto...
c'è anke lo SPEC ma è inutile perchè confronta solo le varie versioni di JAVA :fagiano:
però in teoria basterebbe prendere il punteggio equivalente x lo SPEC di un northwood e di un opteron a 2.2 ghz e compararlo..
solo ke non mi ci sono mai messo :p
^TiGeRShArK^
23-08-2007, 23:53
Inoltre come sapete i processori hanno istruzioni SSE2/SSE3/ALTIVEC che richiedono strutture dati allineate ed altro. In ambiente managed cosa succede? Puoi sfruttare questi instruction set? Fa tutto .NET / Java?
Il JIT del C# onestamente non so come si comporta, ma per quanto riguarda l'ottimizzazione della VM Java non penso che ci sia niente da ridire.
Basta guardare il link di cui sopra.
In alcuni casi il Java risulta addirittura + veloce del C++..
e questo onestamente mi fa pensare che l'ottimizzazione dinamica del codice da parte del JIT funzioni abbastanza bene ;)
Ovviamente cmq poi dipende dalla VM che si usa e dal livello di ottimizzazione che essa utilizza :p
Mi chiedo ora.. In ambienti managed cosa succede? .NET per esempio usa la memoria (e altre risorse) come vuole?
Premessa: ti rispondo riferendomi a Java perchè C# non lo conosco e non mi interessa.
Si, "come vuole" inteso però "nel miglior modo possibile". Ci sono molti algoritmi in uso comune nei garbage collector e la maggior parte considerano anche la frammentazione della memoria. I collector "mark and sweep" per esempio muovono gli oggetti in memoria al volo durante l'esecuzione per ridurre o eliminare la frammentazione. C'è da dire però che le Java Specification non dicono nulla circa l'implementazione del gc e quindi questi comportamenti non sono totalmente predicibili o comunque garantiti. Inoltre, sebbene automatici e quindi estremamente versatili, i gc sono anche il piu' grande collo di bottiglia dei linguaggi semi-interpretati. E' stato calcolato che in media i gc occupano dal 5% al 20% di cpu durante l'esecuzione di un programma correttamente funzionante e ben scritto. E questo in alcuni casi è inaccettabile. In Java puoi controllare in parte come far comportare il gc impostando vari tipi di reference nel codice (parlo dei reference soft, weak, ghost e phantom) o settando alcuni flag a run-time durante l'esecuzione della VM. La versatilità ha un costo e questo costo potrebbe non essere accettabile.
C'è da dire anche che sebbene si venga sgravati dal compito di allocare/deallocare memoria e finalizzare gli oggetti, i gc non proteggono dai memory leak, come molti stupidamente pensano. Ne risulta che programmare correttamente anche usando un gc richiede un livello di attenzione sicuramente non banale quando si trattano questioni non elementari su strutture dati dinamiche evolute e che quella "libertà di pensiero" che si vuole far intendere ci sia mentre si programma con un linguaggio "managed" è in realtà un caso di ingenuità. Un riferimento persistente non è molto diverso da un puntatore pendente, come errore. Inoltre, quando si deve gestire in maniera ottimale e fine casi relativi al memory management (parlo di Java) bisogna considerare argomenti che in C/C++ nemmeno esistono e sono anche di una certa complessità. In sostanza, il discorso che si fa sul "garbage collector scaccia pensieri" in realtà funziona solo su programmi che non appartengono al mondo reale ma sono confinati in esercizietti di programmazione da conservare per 5 giorni sull'hard disk intanto che si assimilano i concetti. Difatti la maggior parte dei programmatori Java scrivono codice che nella maggior parte dei casi ha dei leak quando si utilizzano strutture dati meno stupide di una semplice lista (trovai un sito che citava peste e corna sull'uso delle tabelle hash e il programmatore Java medio e la sua mente "spensierata e produttiva") :asd:
Detto ciò, secondo me uno che non si è mai occupato di questioni relative al memory management in un linguaggio tradizionale come C o C++ mi risulta di dubbia credibilità anche quando usa Java o C#. E di fatti i luoghi comuni in quest'area oltre che abbondare sono ben radicati.
Inoltre come sapete i processori hanno istruzioni SSE2/SSE3/ALTIVEC che richiedono strutture dati allineate ed altro. In ambiente managed cosa succede? Puoi sfruttare questi instruction set? Fa tutto .NET / Java?
Si. Il supporto alle SSE/SSE2 è stato introdotto a partire da Java 1.4.2 per tutte le operazioni floating point in modo del tutto automatico. Padding, alignment, endianness è quant'altro viene tutto gestito dalla VM senza alcun intervento. Da JSE 5 si introduce il supporto alle SSE3 (se non ricordo male ma potrei sbagliarmi).
io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare. più avanti nel thread leggo statistiche circa le prestazioni di Java che sarebbero mediamente il 95% rispetto a quelle di programmi nativi. se i numeri fossero più o meno questi sarebbe un risultato eccellente e per quanto mi riguarda mi accontenterei molto volentieri di perdere un 5% per poter programmare in maniera 10 volte più facile e produttiva per il resto della mia vita: a recuperare quel 5% ci penserà la tecnologia.
non vedo come le cose siano correlate :mbe:
il garbage collector non è una peculiarità degli ambienti managed (anche se sono loro ad averne spinto l'uso) ci sono dei GC anche per il C
la peculiarità degli ambienti managed è quella di girare dentro una VM e attualmente non vedo perchè dovrebbe farlo il SO, in fondo il vantaggio più evidente di queste soluzioni è la portabilità e non mi sembra un'esigenza nella programmazione di un SO. in effetti facendo l'uguaglianza "piattaforma managed = garbage collector" temo di aver approssimato un po' troppo, ma la portabilità non è certo l'unico vantaggio del tipico ambiente managed, è solo quello più specifico; e sarebbe comunque un vantaggio.
prendi un linguaggio come il D ad esempio.. offre tutto quello che offrono i linguaggi degli ambienti managed come java e C# (se non di più) e inoltre permette anche di inserire direttamente codice assembly nel sorgente (cosa che nella programmazione di un SO fa sempre comodo) non mi pronuncio sul D perchè ne conosco solo il nome, ma come ha detto cdimauro quella dell'assembly non sarebbe una gran perdita e soprattutto si può tranquillamente rimediare.
perché? :fagiano: perché hanno lavorato a dir poco un boato per arrivare alla 1.6, quanto ci manca ancora alla 2.0? :D
^TiGeRShArK^
24-08-2007, 01:17
perché hanno lavorato a dir poco un boato per arrivare alla 1.6, quanto ci manca ancora alla 2.0? :D
si ma x java 2 in realtà si intende java 1.2 :p
e da java 1.5 in poi si usa chiamarle java 5 e java 6..
Non per niente la versione EE è passata da J2EE (fino a java 1.4) a JEE 5 :p
cmq in effetti è una numerazione lievemente fatta a cazzo :asd:
Mai dato un'occhita all'occupazione di memoria di un programma C#? il Task Manager per ciascun processo mi mostra solo l'occupazione di memoria virtuale, che, come ben saprai, è cosa ben diversa dall'occupazione di memoria fisica :)
Si pensa che per i dipendenti M$ siano tutte documentate. ovvio, mi sono espresso malissimo io :D
era solo per dire "oh mamma quante sono, guarda là, ce ne sono di documentate, di opache, di..." :D :D :D
Comunque ci hanno messo 6 anni a sviluppare Vista che non è certo un OS scritto da 0, ricordo una news su HWU in cui si diceva che a un certo punto era reiniziata una riscrittura del 60%; non ricordo se del solo kernel o dell'intero sistema, molto più probabilmente la prima visto che era una news relativamente recente.
probabilmente ci vorranno almeno 15 anni prima di avere un OS desktop interamente managed. non vedo l'ora :O
Che dire a me non piace assolutamente il C# fek diceva che in informatica non esistono religioni :O
Tiri ancora in ballo la storia dei puntatori a metodo quanto non sapevi nemmeno dell'esistenza di auto_ptr? ;) embe'? :wtf:
se è per questo a suo tempo non sapevo neanche della storia dei puntatori ai metodi virtuali :D
anzi a dirla tutta manco me la ricordo :asd:
Che ne dici di una sciocchezzuola come il refactoring, niente a che vedere con il linguaggio in sè ma con l'editor, tant'è che ti fanno scaricare un plugin di terze parti.
O il class designer introdotto solo in Orcas.
O i bug che per essere corretti sei obbligato a comprarti Orcas visto che non sono stati corretti nell'SP1.
O l'intellisense che funziona 100 volte peggio di quello del C#. E non diamo la colpa alla difficoltà della sintassi perchè è proprio il funzionamento ad essere differente. èèèèè non c'è bisogno di soggiogarmi psicologicamente :O, la domanda sul formato dei puntatori a metodi virtuali era una presa in giro ma il "tipo?" era una domanda sinceramente interessata :O
In M$ stanno spingeno verso il mondo .NET il resto sta già andando a morire. questa l'avevo praticamente detta prima io :Prrr:
si ma x java 2 in realtà si intende java 1.2 :p
e da java 1.5 in poi si usa chiamarle java 5 e java 6..
Non per niente la versione EE è passata da J2EE (fino a java 1.4) a JEE 5 :p
cmq in effetti è una numerazione lievemente fatta a cazzo :asd: appunto, è questo quello che dicevo: loro per la versione numero 2.0 (major version 2 e minor version 0) avevano in mente chissà quali progetti macrocosmici, che in tutti questi anni sono riusciti a realizzare in percentuale talmente ridotta che alla fine hanno deciso di utilizzare il numero della minor version per numerare la major version!!! ROTFL :D
vorrei proprio sapere che cosa avevano progettato, anche a grandi linee, per quella che in teoria inizialmente avrebbe dovuto essere la versione 2.0 :eek: :eek:
forse giustappunto il sistema operativo completamente managed :sofico:
^TiGeRShArK^
24-08-2007, 01:25
il Task Manager per ciascun processo mi mostra solo l'occupazione di memoria virtuale, che, come ben saprai, è cosa ben diversa dall'occupazione di memoria fisica :)
ehmm..
di default il task manager mi sa che ti fa vedere la memoria fisica occupata in ram dal processo..
se selezioni l'apposita colonna nell'apposito menu puoi anche vedere la memoria virtuale del processo..
spesso è per quello ke se fai la somma della memoria occupata dai processi il conto non ti torna col simpatico grafico dell'occupazione della memoria xkè quello in effetti visualizza solo l'occupazione di memoria virtuale :p
P.S. è drammatico vedere come ogni volta che torno la sera vedo + attiva questa sezione di piazzetta :asd:
siamo tutti nottambuli? :fagiano:
ops, hai ragione, mea culpa :fagiano:
P.S. è drammatico vedere come ogni volta che torno la sera vedo + attiva questa sezione di piazzetta :asd:
siamo tutti nottambuli? :fagiano: io sono nottambulo solo il Giovedì perché c'è Prison Break :D :D :D
EDIT - anzi, diciamo che Prison Break c'è sia il Giovedì sera che il Venerdì mattina, visto che alla Mediaset sono dei geni e hanno scelto degli orari perfetti :fagiano: :fagiano: :fagiano:
più avanti nel thread leggo statistiche circa le prestazioni di Java che sarebbero mediamente il 95% rispetto a quelle di programmi nativi. se i numeri fossero più o meno questi sarebbe un risultato eccellente e per quanto mi riguarda mi accontenterei molto volentieri di perdere un 5% per poter programmare in maniera 10 volte più facile e produttiva per il resto della mia vita: a recuperare quel 5% ci penserà la tecnologia.
Ora diciamo anche in quali programmi. Perchè nel mondo reale che Java ha il 95% delle performance di un'applicazione nativa fa semplicemente ridere.
Come ho già detto, il solo gc prende in media dal 5 al 20% del cpu time. Se poi parliamo di programmini che fanno conticini e allocano si e no 100k di memoria complessiva, allora si, abbiamo il 95% delle prestazioni native.
C'è da dire anche che sebbene si venga sgravati dal compito di allocare/deallocare memoria e finalizzare gli oggetti, i gc non proteggono dai memory leak, come molti stupidamente pensano. di certo chi sceglie di fare a meno del garbage collector ha solo problemi in più nello scrivere codice, quindi deve trattarsi di situazioni in cui la performance è un fattore moolto critico... se mai avessi a che fare con la scrittura di quei tipi di software (non che io speri di no) prima di scegliere definitivamente di rinunciare ad un linguaggio managed studierò attentamente come è possibile controllare il comportamento del garbage collector.
cdimauro
24-08-2007, 07:39
A livello di sintassi no ma i controlli grafici col C# 2.0 si legano ai datasource con tutto quello che ne consegue, nell'1.1 si usavano i dataset. E siccome C# significa usare l'editor in tutte le sue funzionalità...
Per risolvere i casini creati dall'editor hanno introdotto le partial class, mah.
Questo mi sembra molto strano, perché l'architetto che ha creato .NET e C# è lo stesso che ha realizzato Delphi, in cui i controlli grafici sono legati ai datasource, che a loro volta sono legati ai dataset.
Comunque con C# non ci lavoro, per cui mi fido della tua valutazione.
Hai mai provato a passare da ASP 1.1 a ASP 2.0? Sempre codice C# è ma è assolutamente impossibile farne il porting.
Non ho mai lavorato in ASP, quindi non ho idea dei problemi che hai avuto.
Riuso del codice: se hai scritto delle classi in C# 1.1 che segue il paradigma dei dataset chiaramente farai inmodo che queste manipolino e restituiscano dataset, ma come la mettiamo se volessi riusare quel codice per un programma C# 2.0? La procedura di creazione di un dataset è volutamente macchinosa nel VS2005 proprio per invogliare il passaggio ai datasource, questo comporta che non riutilizzerò mai il codice che ho scritto un anno fa.
Ho capito qual è il tuo problema. Non dipende dal linguaggio di per sé, ma da "quello che ci sta attorno", e se è così hai perfettamente ragione: la portabilità è a rischio.
Quindi non ti è mai capitato di notare l'abnorme uso di memoria del C#?
Del resto è del tutto normale, visto tutto quello che si porta dietro.
Se per "portarsi dietro" ti riferisci alle librerie che carica, mi sembra normale.
Altrimenti dovresti essere più chiaro.
Non so quale sia la parte dell'OS oggetto della scrittura in .NET so solo che sul mio nuovo portatile con 2GB di ram, senza antivirus mi ritrovo con il 46% di memoria occupata con FF e un paio di finestre aperte.
Se usassi Matlab o Photoshop cosa dovrei fare comprare l'espansione di memoria?
Non ho parlato del solo s.o., ma dell'intero Windows.
Comunque l'occupazione di memoria di cui parli è relativa: bisogna vedere che uso ne fa.
Ad esempio attualmente nella mia macchina con 1,5GB di ram ho il 62% di memoria fisica allocata, ma andando a controllare il kernel occupa 158MB (di cui ben 95 paginabile), poi ho Opera con una ventina di tab aperti, Thunderbird 2.0, SPE, PSPad, FireFox con 2 tab aperti, una finestra di esplora risorse, un console con Firebird SQL aperto su un database, una command line, la guida di Python in formato CHM, una console di Python, Total Commander con una quindicina di tab, Miranda con 3 tab aperti, Skype, PageAnt (per lavorare con SSH), RMClock, Winamp 5.x, e l'immancabile Sidebar piena di gadget.
Mi rimangono ancora 765MB che sono usati come cache. Direi che non è male.
Ma come la mettiamo con il supporto a lungo termine? A lavoro seguo dei progetti nati nel 1998 in VB che già da parecchio tempo sentono il peso degli anni per la mancanza del multithreading e ora per l'impossibilità di girare su Vista. Un analogo programma scritto in C++ non avrebbe di questi problemi.
Sicuro che un programma C# di oggi tra 10 anni non avrà gli stessi problemi?
Non tutti i software sono fatti per durare un paio d'anni.
Indubbiamente, ma 9 anni (dal 1998 a oggi) per un'applicazione sono anche troppi nel mondo dell'informatica: avete perso anche troppo tempo nel non aggiornarli.
Da qui a 10 anni non posso certo sapere se un'applicazione C# darà gli stessi problemi.
cdimauro
24-08-2007, 07:55
Comunque per come la vedo io:
1) Dire che C e C++ sono linguaggi obsoleti e morti è una gran cagata. Nuove API nascono ogni giorno per questi linguaggi e nuove estensioni a tali linguaggi vengono presentate con cadenza regolare.
Bisogna vedere la portata di queste estensioni: a me sembrano semplici ritocchi. Nulla di particolarmente sostanzioso, insomma.
Il GPGPU è appannaggio esclusivo del C cosi come molte altre tecnologie.
Lo stesso si diceva dell'assembly prima, del C poi, ma oggi il mercato è strapieno di soluzioni managed. Prima o poi arriverà anche alle GPGPU.
Diciamo che C sta diventando sempre piu' specifico, non per questo è un linguaggio morto. Stesso dicasi per C++. A sostegno di ciò, sarei curioso di sapere quanti dicono che C è un linguaggio morto e sono fermi al C89 (o peggio ancora al K&R), mentre i rispettivi comitati di standardizzazione stanno per rilasciare nuove spec (e meno male che sono morti).
Vedi sopra: bisogna vedere quali nuovi elementi introducono.
Vogliamo vedere da quand'è nato il C o il C++ tutte le migliorie che sono state apportate al linguaggio? Facciamo lo stesso anche con Java (peggio ancora sarebbe con Python): confrontiamoli e vediamo cosa ne esce fuori.
2) C# da quando Java è stato aperto è diventato molto meno interessante rispetto a prima (e comunque è sempre stato un linguaggio dall'evoluzione molto piu' chiusa di Java in ogni caso).
E' presto per dirlo: se C# continuerà a guadagnare quote di mercato, vuol dire che l'interesse non sarà venuto a mancare.
Poi l'evoluzione è ben più rapida rispetto a quella di Java, e per chi sviluppa le innovazioni introdotte possono essere particolarmente appetibili.
3) I linguaggi di programmazione e che sono riusciti a sopravvivere nel tempo sono sempre stati quelli che non hanno mai intralciato le palle ad altri linguaggi che dominavano in determinati settori e inoltre sono stati portati con successo su molte piattaforme. C# intralcia le palle a troppi linguaggi e come portabilità su sistemi diversi da Microsoft è ancora un giocattolino accademico (e visto il trend lo rimarrà).
Si potrebbe dire la stessa cosa del C. Il Pascal esisteva già, e il C come linguaggio non ha portato NESSUNA innovazione; tanto che all'epoca veniva ridicolizzato chiamandolo "Pascal mascherato".
E' normale che un nuovo linguaggio "intralci le palle" a quelli esistenti: è sempre stato così, e continuerà a esserlo.
Per quanto riguarda la portabilità di C# su altri sistemi, non è certo compito di MS: il linguaggio (come pure il framework .NET) è standardizzato e CHIUNQUE può tranquillamente cimentarsi nell'impresa (infatti esiste Mono).
E' dagli albori dell'informatica che esiste il problema della portabilità di un linguaggio / framework, e nessuno s'è stracciato le vesti: non vedo, quindi, perché dovremmo farlo per C# (anzi, ci sono stati parecchi problemi col C++ agli inizi a causa della complessità del linguaggio).
Indubbiamente, ma 9 anni (dal 1998 a oggi) per un'applicazione sono anche troppi nel mondo dell'informatica: avete perso anche troppo tempo nel non aggiornarli.
Il tempo vita di alcune applicazioni va anche oltre 10 anni...pensa a tutte le applicazioni critiche. Anche se queste non hanno praticamente mai Windows e hanno tutte sistemi operativi realtime.
Pensa a tutte quelle applicazioni integrate nei sistemi...ad esempio macchine per la gestione delle videoteche e relativa parte server.
Oppure i sistemi informativi delle banche (qualcuno è ancora fermo al Cobol)...o i bancomat.
L'informatica non è solo la realizzazione di programmi per PC con l'interfaccina grafica o la programmazione lato server.
cdimauro
24-08-2007, 08:01
Ho una domanda sugli ambienti managed...
Da quello che mi risulta, nei games, la console va sfruttata al 100%... Non parlo tanto di velocità quanto di uso della memoria, per questo spendiamo un sacco di tempo ad elaborare l'allocazione di memoria con lo scopo di ridurre al minimo la frammentazione e svariate altre cose...
Mi chiedo ora.. In ambienti managed cosa succede? .NET per esempio usa la memoria (e altre risorse) come vuole?
Su questo la persona più indicata per risponderti sarebbe Fran, che c'ha smanettato. :p
Inoltre come sapete i processori hanno istruzioni SSE2/SSE3/ALTIVEC che richiedono strutture dati allineate ed altro. In ambiente managed cosa succede? Puoi sfruttare questi instruction set? Fa tutto .NET / Java?
Fa tutto il compilatore JIT.
La situazione è decisamente migliore rispetto alle applicazioni non-managed, perché nel momento in cui compili il tuo eseguibile per una certa architettura, quello è e quello rimane.
Invece con un'applicazione managed è sufficiente aggiornare il compilatore JIT per far sì che la stessa applicazione tragga beneficio delle innovazioni architetturali in maniera trasparente. Molto meno lavoro per i programmatori, insomma. :p
cdimauro
24-08-2007, 08:04
Uhm? Noi GPGPU lo scriviamo in HLSL/CG...
E in futuro si potrebbe utilizzare anche un qualche linguaggio managed per farlo. ;)
Sono d'accordissimo sul fatto che C++ non è proprio morto per niente... Boost porta avanti un sacco di cose interessanti, inoltre pare che sia prevista una nuova revisione...
Infatti, come dicevo anche prima, circolano voci che in futuro la vorrebbero integrata nella libreria standard del C++.
Solo che BOOST è un framework ENORME (l'ultima volta che l'ho installato mi ha consumato circa 1GB di memoria).
cdimauro
24-08-2007, 08:05
Bhè, Cg non significa forse "C for graphics"? ;) Non è forse pesantemente basato su C come sintassi?
Anche Java e PHP sono pesantemente basati sul C come sintassi, ma sono un tantino diversi. :p
Comunque io mi riferivo a Cuda, che è molto piu' ad alto livello di HLSL/Cg/GLSL, oltre ad essere piu' adatto al GPGPU (quelli citati sopra sono pur sempre linguaggi pensati per lo shading).
Il futuro del GPGPU è questo e non sarà di certo l'unico esempio. Si possono fare altri milioni di esempi in cui C e C++ sono gli unici e rimarranno tali, per molto ma molto tempo.
Ma è indubbio che l'interesse verso di loro sia in costante calo. Ci sarà un perché... ;)
cdimauro
24-08-2007, 08:08
http://www.shudo.net/jit/perf/
questo è il link ke avevo visto...
c'è anke lo SPEC ma è inutile perchè confronta solo le varie versioni di JAVA :fagiano:
Ma sono test vecchissimi! Addirittura basati sul framework 1.1. :(
però in teoria basterebbe prendere il punteggio equivalente x lo SPEC di un northwood e di un opteron a 2.2 ghz e compararlo..
solo ke non mi ci sono mai messo :p
Sarebbe interessante fare dei test adesso, con Java 6 e .NET 3.0 che sono decisamente migliorati.
cdimauro
24-08-2007, 08:10
Il JIT del C# onestamente non so come si comporta, ma per quanto riguarda l'ottimizzazione della VM Java non penso che ci sia niente da ridire.
Basta guardare il link di cui sopra.
In alcuni casi il Java risulta addirittura + veloce del C++..
e questo onestamente mi fa pensare che l'ottimizzazione dinamica del codice da parte del JIT funzioni abbastanza bene ;)
Ovviamente cmq poi dipende dalla VM che si usa e dal livello di ottimizzazione che essa utilizza :p
L'ottimizzazione dinamica funziona bene soprattutto perché ha il vantaggio che può profilare a runtime e "aggiustare" il codice generato. Cosa impossibile per un'applicazione che è stata compilata staticamente.
cdimauro
24-08-2007, 08:19
Premessa: ti rispondo riferendomi a Java perchè C# non lo conosco e non mi interessa.
Si, "come vuole" inteso però "nel miglior modo possibile". Ci sono molti algoritmi in uso comune nei garbage collector e la maggior parte considerano anche la frammentazione della memoria. I collector "mark and sweep" per esempio muovono gli oggetti in memoria al volo durante l'esecuzione per ridurre o eliminare la frammentazione. C'è da dire però che le Java Specification non dicono nulla circa l'implementazione del gc e quindi questi comportamenti non sono totalmente predicibili o comunque garantiti. Inoltre, sebbene automatici e quindi estremamente versatili, i gc sono anche il piu' grande collo di bottiglia dei linguaggi semi-interpretati. E' stato calcolato che in media i gc occupano dal 5% al 20% di cpu durante l'esecuzione di un programma correttamente funzionante e ben scritto. E questo in alcuni casi è inaccettabile.
Anche se fosse così, se alla fine le prestazioni sono quelle di cui abbiamo parlato, il loro consumo di risorse è del tutto trascurabile.
In Java puoi controllare in parte come far comportare il gc impostando vari tipi di reference nel codice (parlo dei reference soft, weak, ghost e phantom) o settando alcuni flag a run-time durante l'esecuzione della VM. La versatilità ha un costo e questo costo potrebbe non essere accettabile.
Dipende sempre da quello che ci devi fare.
C'è da dire anche che sebbene si venga sgravati dal compito di allocare/deallocare memoria e finalizzare gli oggetti, i gc non proteggono dai memory leak, come molti stupidamente pensano. Ne risulta che programmare correttamente anche usando un gc richiede un livello di attenzione sicuramente non banale quando si trattano questioni non elementari su strutture dati dinamiche evolute e che quella "libertà di pensiero" che si vuole far intendere ci sia mentre si programma con un linguaggio "managed" è in realtà un caso di ingenuità. Un riferimento persistente non è molto diverso da un puntatore pendente, come errore.
Chiaro, ma la situazione non è certo la stessa: generalmente i GC fanno un ottimo lavoro per liberare la memoria non usata. Poi è chiaro che miracoli non ne possono fare. Sempre meglio che della situazione che si crea con linguaggi non managed, comunque, dove sei spesso a rischio di memory leak e doppia deallocazione della memoria.
Inoltre, quando si deve gestire in maniera ottimale e fine casi relativi al memory management (parlo di Java) bisogna considerare argomenti che in C/C++ nemmeno esistono e sono anche di una certa complessità. In sostanza, il discorso che si fa sul "garbage collector scaccia pensieri" in realtà funziona solo su programmi che non appartengono al mondo reale ma sono confinati in esercizietti di programmazione da conservare per 5 giorni sull'hard disk intanto che si assimilano i concetti.
Ampiamente opinabile: stai generalizzando troppo.
Difatti la maggior parte dei programmatori Java scrivono codice che nella maggior parte dei casi ha dei leak quando si utilizzano strutture dati meno stupide di una semplice lista (trovai un sito che citava peste e corna sull'uso delle tabelle hash e il programmatore Java medio e la sua mente "spensierata e produttiva") :asd:
Sarebbe interessate dargli un'occhiata, ma immagino che tu non abbia più il link a disposizione.
Detto ciò, secondo me uno che non si è mai occupato di questioni relative al memory management in un linguaggio tradizionale come C o C++ mi risulta di dubbia credibilità anche quando usa Java o C#. E di fatti i luoghi comuni in quest'area oltre che abbondare sono ben radicati.
Uno che non si è mai posto questioni del genere con C o C++ o s'è fermato al classico "Hello, world!", oppure ha passato la vita a chiedersi il perché di tutti i segmentation fault e i comportamenti anomali che vengono fuori dalle sue applicazioni. :asd:
cdimauro
24-08-2007, 08:23
Ora diciamo anche in quali programmi. Perchè nel mondo reale che Java ha il 95% delle performance di un'applicazione nativa fa semplicemente ridere.
Come ho già detto, il solo gc prende in media dal 5 al 20% del cpu time. Se poi parliamo di programmini che fanno conticini e allocano si e no 100k di memoria complessiva, allora si, abbiamo il 95% delle prestazioni native.
Se il GC prende in media dal 5 al 20%, ma complessivamente le prestazioni sono il 95% di quelle native, non vedo quale sia il problema.
Comunque servirebbero test più recenti e con suite più corpose e diversificate (come tipologie di applicazione).
cdimauro
24-08-2007, 08:24
Il tempo vita di alcune applicazioni va anche oltre 10 anni...pensa a tutte le applicazioni critiche. Anche se queste non hanno praticamente mai Windows e hanno tutte sistemi operativi realtime.
Pensa a tutte quelle applicazioni integrate nei sistemi...ad esempio macchine per la gestione delle videoteche e relativa parte server.
Oppure i sistemi informativi delle banche (qualcuno è ancora fermo al Cobol)...o i bancomat.
L'informatica non è solo la realizzazione di programmi per PC con l'interfaccina grafica o la programmazione lato server.
Chiaro, ma quelli che hai citato sono settori molto particolari.
Chiaro, ma quelli che hai citato sono settori molto particolari.
Molto particolari, ma nemmeno poco diffusi. Quante aziende ad esempio hanno ancora gli AS400 ? Certo a livello di client a quel punto di sbizzarrisci, ma chi programma sul server si deve scordare di tutto quello di cui abbiamo parlato qui.
A livello di banche si fa tutto o con vecchi sistemi + COBOL o con server Linux/Unix con un DBMS + programmi ad hoc (ovviamente non certo in Python o Mono) e con client Windows.
Nota che la maggior parte delle volte i programmi sui client sono scritti in VB6 (o addirittura 5), e dopo il 2002, con l'avvento dell'euro, questi programmi dovranno funzionare ancora molto a lungo visto l'investimento fatto per l'adeguamento alla nuova moneta. Quindi immaginati che tempo di vita hanno :)
E non sono settori di nicchia: danno lavoro ad una buona fetta del personale IT in Italia.
cdimauro
24-08-2007, 10:19
Non lo metto in dubbio.
E' anche vero che spesso sono realizzati da personalmente assolutamente non qualificato (che è la vera piaga dell'informatica).
D'altra parte fino a quando non ci sarà un vero ordine degli informatici, la situazione non cambierà di sicuro.
più avanti nel thread leggo statistiche circa le prestazioni di Java che sarebbero mediamente il 95% rispetto a quelle di programmi nativi. se i numeri fossero più o meno questi sarebbe un risultato eccellente e per quanto mi riguarda mi accontenterei molto volentieri di perdere un 5% per poter programmare in maniera 10 volte più facile e produttiva per il resto della mia vita: a recuperare quel 5% ci penserà la tecnologia.
evidentemente un bech non significa niente.. di sicuro non hanno testato il comportamento di un sistema operativo che è ben più complesso e meno ripetitivo di un bench. i linguaggi interpretati si comportano decisamente meglio nei compiti ripetitivi e nonostante questo non raggiungono mai le prestazioni dei linguaggi non interpretati, poi c'è da dire che valutare le prestazioni di un linguaggio interpretato è più complesso perchè bisognerebbe anche aggiungere il carico dovuto all'interprete (cosa che raramente si fa nei bench)
in effetti facendo l'uguaglianza "piattaforma managed = garbage collector" temo di aver approssimato un po' troppo, ma la portabilità non è certo l'unico vantaggio del tipico ambiente managed, è solo quello più specifico; e sarebbe comunque un vantaggio.
bisogna vedere se per un SO è più importante la portabilità o le prestazioni, perchè non si può avere la botte piena e la moglie ubriaca
comunque sia solitamente si intende che un'applicazione è portabile se gira su sistemi operativi diversi senza modifiche.. mi risulta un pò difficile pensare a un SO che gira su sistemi operativi diversi :stordita:
il solo problema di portabilità in un SO riguarda l'architettura, ma quello è un problema di altro tipo e gli ambienti managed non servono a molto
non mi pronuncio sul D perchè ne conosco solo il nome, ma come ha detto cdimauro quella dell'assembly non sarebbe una gran perdita e soprattutto si può tranquillamente rimediare.
certo a tutto si può rimediare, ma a un prezzo! in un SO ci sono dei pezzi di codice che sono critici, che tradotto in parole povere significa che se ci guadagni anche solo un ciclo di clock potresti avere un vantaggio enorme in termini di prestazioni (certo è un pò esagerato per rendere l'idea, ma tanto la differenza tra ASM e .NET non è un ciclo di clock ;) )
ovviamente si tratta di piccolissimi pezzi di codice, nessuno è così pazzo da riempire il codice di assembly
ps. io il D l'ho visto per la prima volta pochi giorni fa, ma mi sembra di averlo sempre conosciuto ihih leggi qua http://www.digitalmars.com/d/overview.html
fek diceva che in informatica non esistono religioni :O
è la stessa persona che sosteneva che l'XP è superiore a qualsiasi altra metodologia di sviluppo? :fagiano:
tomminno
24-08-2007, 13:02
Questo mi sembra molto strano, perché l'architetto che ha creato .NET e C# è lo stesso che ha realizzato Delphi, in cui i controlli grafici sono legati ai datasource, che a loro volta sono legati ai dataset.
Non conosco Delphi, ma in C# dataset e datasource sono 2 mondi distinti, il primo è legato al "modello di programmazione" tipico dell'1.1 e l'altro, tipico del 2.0, è nato grazie all'introduzione dei generics.
Ho capito qual è il tuo problema. Non dipende dal linguaggio di per sé, ma da "quello che ci sta attorno", e se è così hai perfettamente ragione: la portabilità è a rischio.
Una cosa che non mi piace del C# è questo stretto legame che viene a crearsi tra linguaggio ed editor, tanto che si creano estensioni al linguaggio per rimediare a gravi problemi dell'editor, e si usa l'editor per scoraggiare tecniche di programmazione ritenute "obsolete".
Se per "portarsi dietro" ti riferisci alle librerie che carica, mi sembra normale.
Altrimenti dovresti essere più chiaro.
Si mi riferisco a tutto quello che sta dietro alla creazione di un oggetto, a tutta la gerarchia di classi da cui deriva, a tutti i campi spesso inutili che un oggetto si porta dietro (penso ad esempio ai DateTime).
Dopotutto la completezza del framework in qualche modo la devi pagare.
Comunque l'occupazione di memoria di cui parli è relativa: bisogna vedere che uso ne fa.
Ad esempio attualmente nella mia macchina con 1,5GB di ram ho il 62% di memoria fisica allocata, ma andando a controllare il kernel occupa 158MB (di cui ben 95 paginabile), poi ho Opera con una ventina di tab aperti, Thunderbird 2.0, SPE, PSPad, FireFox con 2 tab aperti, una finestra di esplora risorse, un console con Firebird SQL aperto su un database, una command line, la guida di Python in formato CHM, una console di Python, Total Commander con una quindicina di tab, Miranda con 3 tab aperti, Skype, PageAnt (per lavorare con SSH), RMClock, Winamp 5.x, e l'immancabile Sidebar piena di gadget.
Mi rimangono ancora 765MB che sono usati come cache. Direi che non è male.
Che dire sul mio portatile vanno via quasi 300MB (100MB l'svchost e 180MB il processo dwm da esso dipendente) solo per il reparto grafico e la versione di Vista non dovrebbe avere Aero.
Indubbiamente, ma 9 anni (dal 1998 a oggi) per un'applicazione sono anche troppi nel mondo dell'informatica: avete perso anche troppo tempo nel non aggiornarli.
Lo convinci te il cliente a sborsare i soldi per aggiornare un intero sistema funzionante (anche se scritto da cani) se non ne sente la necessità impellente?
Inoltre non è che in 10 anni non è mai stato aggiornato, si è evoluto nelle funzionalità, ma sempre in VB6 è rimasto, con tutti i difetti del caso.
E poi dove lavoro usavano VB6 fino all'anno scorso...
Da qui a 10 anni non posso certo sapere se un'applicazione C# darà gli stessi problemi.
Vista l'elevata obsolescenza del codice C# ho il vago sospetto che ciò puntualmente avverrà.
^TiGeRShArK^
24-08-2007, 13:03
Ora diciamo anche in quali programmi. Perchè nel mondo reale che Java ha il 95% delle performance di un'applicazione nativa fa semplicemente ridere.
Come ho già detto, il solo gc prende in media dal 5 al 20% del cpu time. Se poi parliamo di programmini che fanno conticini e allocano si e no 100k di memoria complessiva, allora si, abbiamo il 95% delle prestazioni native.
Bhè...
Eclipse non mi pare abbia niente da invidiare a programmi nativi :p
E cmq per programmi che fanno conticini le performance possono essere considerate praticamente equivalenti al C++ come puoi vedere dai grafici postati.
Se dici che il problema è il Garbage Collector basta fare in modo di non doverlo usare a sproposito ingegnerizzando a dovere l'apllicazione e dimensionando adeguatamente la dimensione dell'Heap space in modo da far intervenire il garbage collector solo quando strettamente necessario :p
^TiGeRShArK^
24-08-2007, 13:04
di certo chi sceglie di fare a meno del garbage collector ha solo problemi in più nello scrivere codice, quindi deve trattarsi di situazioni in cui la performance è un fattore moolto critico... se mai avessi a che fare con la scrittura di quei tipi di software (non che io speri di no) prima di scegliere definitivamente di rinunciare ad un linguaggio managed studierò attentamente come è possibile controllare il comportamento del garbage collector.
Oppure in maniera + semplice usi Java Real Time che ti da un cotrollo praticamente assoluto sul GC tanto che al limite puoi anche decidere di non usarlo (a tuo rischio e pericolo ovviamente :asd: ):p
^TiGeRShArK^
24-08-2007, 13:12
Molto particolari, ma nemmeno poco diffusi. Quante aziende ad esempio hanno ancora gli AS400 ? Certo a livello di client a quel punto di sbizzarrisci, ma chi programma sul server si deve scordare di tutto quello di cui abbiamo parlato qui.
Perchè ? :fagiano:
per AS400 IBM ti fornisce delle API Java che ti permettono di fare veramente la qualunque ;)
Preso dal sito di JTOPEN, la versione open source delle API IBM:
Here are just a few of the many i5/OS and OS/400 resources you can access using JTOpen:
* Database -- JDBC (SQL) and record-level access (DDM)
* Integrated File System
* Program calls
* Commands
* Data queues
* Data areas
* Print/spool resources
* Product and PTF information
* Jobs and job logs
* Messages, message queues, message files
* Users and groups
* User spaces
* System values
* System status
Se dici che il problema è il Garbage Collector basta fare in modo di non doverlo usare a sproposito ingegnerizzando a dovere l'apllicazione e dimensionando adeguatamente la dimensione dell'Heap space in modo da far intervenire il garbage collector solo quando strettamente necessario :p
il problema del GC:
"per avere un GC veramente accurato bisognerebbe usare più risorse di quelle che riuscirebbe a liberare" :Prrr:
per essere usato in pratica un GC non può essere troppo accurato, ma deve essere un buon compromesso
tomminno
24-08-2007, 13:13
Oppure in maniera + semplice usi Java Real Time che ti da un cotrollo praticamente assoluto sul GC tanto che al limite puoi anche decidere di non usarlo (a tuo rischio e pericolo ovviamente :asd: ):p
Io i sistemi real time li ho visti con 4kB di RAM. Dove lo metti Java?
E se non usi il GC come la liberi la memoria? Tipicamente i sistemi RT non hanno grossi requisiti HW.
^TiGeRShArK^
24-08-2007, 13:14
evidentemente un bech non significa niente.. di sicuro non hanno testato il comportamento di un sistema operativo che è ben più complesso e meno ripetitivo di un bench. i linguaggi interpretati si comportano decisamente meglio nei compiti ripetitivi e nonostante questo non raggiungono mai le prestazioni dei linguaggi non interpretati, poi c'è da dire che valutare le prestazioni di un linguaggio interpretato è più complesso perchè bisognerebbe anche aggiungere il carico dovuto all'interprete (cosa che raramente si fa nei bench)
Ehmm..
java non è interpretato + da un bel pezzo oramai :stordita:
Bhè...
Eclipse non mi pare abbia niente da invidiare a programmi nativi :p
oddio.. in quanto a reattività ha molto da invidiare
tomminno
24-08-2007, 13:18
Perchè ? :fagiano:
per AS400 IBM ti fornisce delle API Java che ti permettono di fare veramente la qualunque ;)
Preso dal sito di JTOPEN, la versione open source delle API IBM:
Sembra che tu non abbia idea di cosa possa significare riscrivere software finanziari super-collaudati, di quali investimenti necessitino e di quanto testing sia necessario prima di una loro messa in opera. E tutto solo per fare le stesse medesime cose che vengono già fatte adesso? A che pro?
^TiGeRShArK^
24-08-2007, 13:18
è la stessa persona che sosteneva che l'XP è superiore a qualsiasi altra metodologia di sviluppo? :fagiano:
No.
non ha mai detto quello.
Ha detto che in molte situazioni quella metodologia era superiore alle altre.
^TiGeRShArK^
24-08-2007, 13:20
Io i sistemi real time li ho visti con 4kB di RAM. Dove lo metti Java?
E se non usi il GC come la liberi la memoria? Tipicamente i sistemi RT non hanno grossi requisiti HW.
come si libera la memoria?
come fai nei linguaggi non managed di solito scusa? :asd:
e cmq quello è solo il meccanismo + estremo di controllo del GC.
Ce ne sono molti altri a disposizione.
^TiGeRShArK^
24-08-2007, 13:21
oddio.. in quanto a reattività ha molto da invidiare
:rolleyes:
Guarda..
se riesco ad usarlo decentemente io quando ho caricato progetti per un totale di diverse centinaia di migliaia di righe di codice non vedo come si possa dire che non è reattivo...
certo..
se lo usi con macchine con poca memoria e/o lo fai partire SENZA specificare l'opzione Xmx nel collegamento che lo fa partire allora sò cazzi tuoi :Prrr:
^TiGeRShArK^
24-08-2007, 13:23
Sembra che tu non abbia idea di cosa possa significare riscrivere software finanziari super-collaudati, di quali investimenti necessitino e di quanto testing sia necessario prima di una loro messa in opera. E tutto solo per fare le stesse medesime cose che vengono già fatte adesso? A che pro?
E chi ha mai detto di riscriverle?
stavo solo facendo vedere che anche sugli AS400 si può usare MOLTO efficacemente codice Java.
Quando lavoravo su quelle macchine non ci pensavo proprio ad usare un altro linguaggio dato che per le mie esigenze le api Java erano anche troppo.
Ehmm..
java non è interpretato + da un bel pezzo oramai :stordita:
chiamalo compilato Just In Time o come vuoi, fatto sta che ha bisogno di una VM
No.
non ha mai detto quello.
Ha detto che in molte situazioni quella metodologia era superiore alle altre.
come no.. io c'ero :fagiano:
:rolleyes:
Guarda..
se riesco ad usarlo decentemente io quando ho caricato progetti per un totale di diverse centinaia di migliaia di righe di codice non vedo come si possa dire che non è reattivo...
certo..
se lo usi con macchine con poca memoria e/o lo fai partire SENZA specificare l'opzione Xmx nel collegamento che lo fa partire allora sò cazzi tuoi :Prrr:
ah non dirlo a me che l'ho usato per fare di tutto e lo uso ancora :D di certo non mi sognerei mai di dire che la reattività è il suo forte (però effettivamente VS2005 l'ho trovato anche peggiore).
purtroppo sul portatile ho solo 512Mb di RAM e sono al limite per eclipse.. per fare un paragone kdevelop e codeblocks hanno caratteristiche simili (anche se inferiori oggettivamente) eppure sono proprio su un altro pianeta in quanto a reattività
Se il GC prende in media dal 5 al 20%, ma complessivamente le prestazioni sono il 95% di quelle native, non vedo quale sia il problema.
Il problema sorge quando si eseguono determinate applicazioni su PC non proprio all'ultimo grido e li la percezione è tutt'altra che quel 95% di codice nativo. Eclipse è semplicemente un mulo, Netbeans altrettanto. O possiamo citare anche un Poseidon for UML, dove ai tempi di avvio biblici si verificano tempi di esecuzione non proprio fulminei nell'usare componenti GUI non proprio fuori norma.
Su un misero portatile con Athlon XP 1500+ con 512MB di ram, per esempio, la differenza in performance si nota drasticamente: un ipotetico Eclipse ad avviarsi ci mette quanto l'intero KDE e molto piu' di Gnome. Magari l'esecuzione non è lentissima, anzi considerando la metodologia di esecuzione, la velocità è sicuramente impressionante. Ma i tempi di avvio sono ancora drastici. In un moderno PC magari queste cose non si notano ma in genere le mancanze di performance si notano piu' sui PC che non hanno cicli da sprecare. E nei benchmark, come diceva qualcuno, queste cose non si considerano.
Anche Java e PHP sono pesantemente basati sul C come sintassi, ma sono un tantino diversi. :p
Ma è indubbio che l'interesse verso di loro sia in costante calo. Ci sarà un perché... ;)
Io tutto questo interesse in calo non lo vedo sinceramente e non vedo nemmeno tutto questo interesse in crescita per C#. Nuove API nascono in C/C++ tutti i giorni cosi come nuovi software. Si possono fare milioni di esempi a riguardo. Molte API importanti hanno subito dei porting verso Java e di C# nemmeno l'ombra (vedi ad esempio QT Jambi). In ambito mobile .NET compact è morto prima ancora di nascere e paragonato a MIDP si mette a piangere. Per il resto su smart phone C e C++ dominano. Per il server side, oltre ai metodi tradizionali in cui PHP/Apache la fanno da padroni da sempre, è molto piu' facile incontrare tecnologie JEE + Tomcat. Su piattaforme non Microsoft, come ad esempio Mac, Apple produce un JDK nativo MacOSX e non ha mai preso in considerazione l'ipotesi di implementare un framework .NET
Mono semplicemente non è un'opzione. Certo, come dici il compito non è di Microsoft portare l'intera piattaforma su macchine diverse (opinabile) ma Sun lo fa ed è questo che importa. All'attualità non si può dire che .NET abbia la stessa valenza di Java su macchine non Microsoft perchè le implementazioni sono immature e incomplete. Quello che ci sarà nel futuro non lo guardo perchè stiamo facendo un discorso proiettato nel presente.
Moltissime aziende hanno intranet basate su servizi Java. Magari per .NET c'è qualche crescita in qualche direzione, ma non è tutto questo rose e fiori.
^TiGeRShArK^
24-08-2007, 14:01
chiamalo compilato Just In Time o come vuoi, fatto sta che ha bisogno di una VM
come no.. io c'ero :fagiano:
ah non dirlo a me che l'ho usato per fare di tutto e lo uso ancora :D di certo non mi sognerei mai di dire che la reattività è il suo forte (però effettivamente VS2005 l'ho trovato anche peggiore).
purtroppo sul portatile ho solo 512Mb di RAM e sono al limite per eclipse.. per fare un paragone kdevelop e codeblocks hanno caratteristiche simili (anche se inferiori oggettivamente) eppure sono proprio su un altro pianeta in quanto a reattività
Ecco..
VS2005 è ancora peggio...
Come completezza kdevelop e codeblocks sono paragonabili ad eclipse?
Io non lo so xkè non li ho mai usati..
ma qualche dubbio ce l'avrei :p
^TiGeRShArK^
24-08-2007, 14:02
Il problema sorge quando si eseguono determinate applicazioni su PC non proprio all'ultimo grido e li la percezione è tutt'altra che quel 95% di codice nativo. Eclipse è semplicemente un mulo, Netbeans altrettanto. O possiamo citare anche un Poseidon for UML, dove ai tempi di avvio biblici si verificano tempi di esecuzione non proprio fulminei nell'usare componenti GUI non proprio fuori norma.
Su un misero portatile con Athlon XP 1500+ con 512MB di ram, per esempio, la differenza in performance si nota drasticamente: un ipotetico Eclipse ad avviarsi ci mette quanto l'intero KDE e molto piu' di Gnome. Magari l'esecuzione non è lentissima, anzi considerando la metodologia di esecuzione, la velocità è sicuramente impressionante. Ma i tempi di avvio sono ancora drastici. In un moderno PC magari queste cose non si notano ma in genere le mancanze di performance si notano piu' sui PC che non hanno cicli da sprecare. E nei benchmark, come diceva qualcuno, queste cose non si considerano.
Il tempo di avvio però non lo considero un becnh affidabile io :p
e quello non ho mai messo in dubbio che sia lento..
Certo ke però a farlo partire dal RAID 0 con il workspace vuoto sembra un fulmine :asd:
Eclipse è semplicemente un mulo, Netbeans altrettanto. ma cazz dici, non è assolutamente vero :mbe:
dove li fai girare per vederli tanto lenti? 486 e 1 MB di RAM con Windows Vista?
Su un misero portatile con Athlon XP 1500+ con 512MB di ram, per esempio, la differenza in performance si nota drasticamente: un ipotetico Eclipse ad avviarsi ci mette quanto l'intero KDE e molto piu' di Gnome. KDE non ci mette mica tanto più di Gnome eh...
Magari l'esecuzione non è lentissima, anzi considerando la metodologia di esecuzione, la velocità è sicuramente impressionante. la "metodologia" di esecuzione non vedo cos'abbia di diverso da quella dei programmi nativi visto che il bytecode viene compilato in codice nativo prima di essere eseguito. infatti è per questo che i tempi di caricamento possono lasciare qualcuno a desiderare.
Ecco..
VS2005 è ancora peggio...
Come completezza kdevelop e codeblocks sono paragonabili ad eclipse?
Io non lo so xkè non li ho mai usati..
ma qualche dubbio ce l'avrei :p abbilo, abbilo :D
Bhè...
Eclipse non mi pare abbia niente da invidiare a programmi nativi :p
E cmq per programmi che fanno conticini le performance possono essere considerate praticamente equivalenti al C++ come puoi vedere dai grafici postati.
Io da i grafici postati vedo test che snobbano 10 anni di innovazione in materia di compilatori. E la data dei test risale anche a periodi in cui i compilatori C++ è noto che non fossero gran che ottimali. Inoltre il flag -O2 è un'ottimizzazione generica quindi non è corretta. Le VM guardano al tipo di processore in uso quando eseguono codice e si regolano di conseguenza. Io avrei usato anche i flag -mtune e -march. E soprattutto vorrei vederlo adesso. Il flag -fvisibility=hidden ha portato nuovi livelli di performance nella rilocazione dei simboli in programmi C++.
Se dici che il problema è il Garbage Collector basta fare in modo di non doverlo usare a sproposito ingegnerizzando a dovere l'apllicazione e dimensionando adeguatamente la dimensione dell'Heap space in modo da far intervenire il garbage collector solo quando strettamente necessario :p
Non è forse un tipo di ottimizzazione che si fa anche in qualsiasi altro programma scritto sulla terra? In nessun programma degno di questo nome non si cerca di minimizzare allocazione/deallocazione ai minimi termini e solo quando serve. Questo non risolve il problema perchè queste considerazioni erano chiaramente incluse nel discorso, parliamo di applicazioni scritte comunque a regola d'arte. Il codice Java è sicuramente velocissimo (considerando il metodo di esecuzione) ma i tempi di start-up piu' le latenze del GC non sono trascurabili. E sinceramente si avverte. La questione del 5 al 20% di latenza media non l'ho misutato io ma è uno studio fatto da IBM con applicazioni un tantino piu' complesse di un benchmark.
Nuove API nascono in C/C++ tutti i giorni cosi come nuovi software. aridaje... se così fosse adesso la STL o le Boost o qualunque altro set di cui tu stia parlando ammonterebbe ad un numero di API superiore a quello di Win32 :asd:
come no.. io c'ero :fagiano: link :O
Perchè ? :fagiano:
per AS400 IBM ti fornisce delle API Java che ti permettono di fare veramente la qualunque ;)
Preso dal sito di JTOPEN, la versione open source delle API IBM:
Sì...quelle sono API client, ma l'AS/400 lo devi pure programmare dal lato AS/400 :D
Il flag -fvisibility=hidden ha portato nuovi livelli di performance nella rilocazione dei simboli in programmi C++. finalmente l'hanno capito che devono fare come si fa su Windows :asd:
Come completezza kdevelop e codeblocks sono paragonabili ad eclipse?
CDT è veramente minimale, hai un decimo delle funzionalità che hai con Java. Code::Blocks è forse anche meglio. Anjuta è sicuramente più avanti.
ma cazz dici, non è assolutamente vero :mbe:
dove li fai girare per vederli tanto lenti? 486 e 1 MB di RAM con Windows Vista?
KDE non ci mette mica tanto più di Gnome eh...
Con un computer dove le applicazioni native ci mettono di meno. Basta? Se dobbiamo paragonare le performance lo dobbiamo fare a parità di hardware no? Se lo eseguissi su un 486 con 1MB di ram non ndrebbe bene lo stesso? Li le applicazioni native in C/C++ pare che si utilizzavano. :rolleyes:
la "metodologia" di esecuzione non vedo cos'abbia di diverso da quella dei programmi nativi visto che il bytecode viene compilato in codice nativo prima di essere eseguito.
Appunto, lo stai dicendo tu cos'ha di diverso. Ti risulta che i programmi nativi compilano bytecode a runtime? :rolleyes:
infatti è per questo che i tempi di caricamento possono lasciare qualcuno a desiderare.
Ma non erano uguali i metodi? :mbe:
aridaje... se così fosse adesso la STL o le Boost o qualunque altro set di cui tu stia parlando ammonterebbe ad un numero di API superiore a quello di Win32 :asd:
Perchè, ti risulta difficile credere che il numero di API esistente in circolazione scritto in C/C++ supera di brutto quello fornito dal solo Win32? :confused:
^TiGeRShArK^
24-08-2007, 14:39
CDT è veramente minimale, hai un decimo delle funzionalità che hai con Java. Code::Blocks è forse anche meglio. Anjuta è sicuramente più avanti.
Ehm..
infatti io lo paragonavo col JDT che fa veramente di tutto :p
il CDT non l'ho mai usato con eclipse... l'ho solo scaricato una volta ma mai aperto :fagiano:
Ehm..
infatti io lo paragonavo col JDT che fa veramente di tutto :p
il CDT non l'ho mai usato con eclipse... l'ho solo scaricato una volta ma mai aperto :fagiano:
Pensa che non esiste, o almeno non l'ho ancora trovato, un tool per il refactoring del C++...purtroppo.
Anzi, se ne conoscete uno ditemelo :D
Perchè, ti risulta difficile credere che il numero di API esistente in circolazione scritto in C/C++ supera di brutto quello fornito dal solo Win32? :confused:
Questo senza ombra di dubbio...
Con un computer dove le applicazioni native ci mettono di meno. Basta? Se dobbiamo paragonare le performance lo dobbiamo fare a parità di hardware no? Se lo eseguissi su un 486 con 1MB di ram non ndrebbe bene lo stesso? Li le applicazioni native in C/C++ pare che si utilizzavano. :rolleyes: tu hai detto che trovi Eclipse e NetBeans molto lenti, in assoluto.
Appunto, lo stai dicendo tu cos'ha di diverso. Ti risulta che i programmi nativi compilano bytecode a runtime? :rolleyes: se è per questo non lo fanno neanche quelli managed: lo fanno solo le virtual machine.
Ma non erano uguali i metodi? :mbe: di esecuzione, non di caricamento. il caricamento non fa parte dell'esecuzione del programma in se' perché viene effettuato dal sistema operativo nel caso di programmi nativi e dalla virtual machine nel caso di programmi managed.
Perchè, ti risulta difficile credere che il numero di API esistente in circolazione scritto in C/C++ supera di brutto quello fornito dal solo Win32? :confused: ah be' se nel numero contiamo tutte quelle scritte da cani&porci sparsi per il mondo sono d'accordissimo... io avevo inteso che parlassi di qualche set più o meno ufficiale del C e/o del C++, come le rispettive standard libraries e come pare che diventeranno le Boost.
ah be' se nel numero contiamo tutte quelle scritte da cani&porci sparsi per il mondo sono d'accordissimo... io avevo inteso che parlassi di qualche set più o meno ufficiale del C e/o del C++, come le rispettive standard libraries e come pare che diventeranno le Boost.
Io a volte ho l'impressione di parlare con gente che risponde senza capire quello che uno sta dicendo... :mbe:
Ho parlato di nuove librerie che continuamente nascono native in C/C++ (sempre che un cane&porco possa scrivere una libreria che si possa definire tale) per rispondere a cdimauro del fatto che c'è sempre meno interesse in C/C++ e di come non ci sia tutto questo fiorire per quanto riguarda C#/.NET in generale. Mi rispondi con "aridaje" per poi parlare di "set piu' o meno ufficiali" e ancora non riesco a capire che cosa vuoi dire.
Io a volte ho l'impressione di parlare con gente che risponde senza capire quello che uno sta dicendo... :mbe: io a volte ho l'impressione che mo' ti segnalo :huh:
Ho parlato di nuove librerie che continuamente nascono native in C/C++ (sempre che un cane&porco possa scrivere una libreria che si possa definire tale) per rispondere a cdimauro del fatto che c'è sempre meno interesse in C/C++ e di come non ci sia tutto questo fiorire per quanto riguarda C#/.NET in generale. Mi rispondi con "aridaje" per poi parlare di "set piu' o meno ufficiali" e ancora non riesco a capire che cosa vuoi dire. toglici "ufficiali" e mettici "standard"; per il resto ho letto male.
^TiGeRShArK^
24-08-2007, 17:00
Il problema sorge quando si eseguono determinate applicazioni su PC non proprio all'ultimo grido e li la percezione è tutt'altra che quel 95% di codice nativo. Eclipse è semplicemente un mulo, Netbeans altrettanto.
E xkè forse firefox o l'ultima versione di office su quei pc vanno meglio? :mbe:
Perchè non confrontarli allora su windows 95 che gira su un 386 con 4 MB di RAM già ke ci siamo.
Nessuno sta dicendo che siano delle piume, ma per quello che deve fare, almeno dall'esperienza che ho avuto io, Eclipse è quanto di meglio ci sia.
Il problema sorge quando si eseguono determinate applicazioni su PC non proprio all'ultimo grido e li la percezione è tutt'altra che quel 95% di codice nativo. Eclipse è semplicemente un mulo, Netbeans altrettanto. O possiamo citare anche un Poseidon for UML, dove ai tempi di avvio biblici si verificano tempi di esecuzione non proprio fulminei nell'usare componenti GUI non proprio fuori norma.
La mia impressione è in questo casi che la colpa non sia tanto del linguaggio e della VM, quanto del framework. Continuo a domandarmi come mai ci siano un sacco di programmi scritti con linguaggi di scripting che funzionano tranquillamente se senza occupare una quantità eccessiva di memoria, mentre ci sono dei "mostri" scritti in Java (e qualcuno anche .NET) che si succhiamo memoria, memoria, memoria, memoria.
Secondo me la cosa è dovuto un po' alla "mentalità" tipica di chi programma in Java, che porta a cataste di oggetti che chiamano cataste di metodi per fare quattro boiate... quando vedo perle come questa (http://ws.apache.org/axis/java/apiDocs/org/apache/axis/components/net/SocketFactoryFactory.html)
mi viene il dubbio che forse ho ragione...
Per inciso Eclipse usa un toolkit grafico nativo (le swt) a suo tempo nato, oltre per il look 'n feel, perchè quello cross-platform di Java era troppo pesante ..
^TiGeRShArK^
24-08-2007, 17:41
La mia impressione è in questo casi che la colpa non sia tanto del linguaggio e della VM, quanto del framework. Continuo a domandarmi come mai ci siano un sacco di programmi scritti con linguaggi di scripting che funzionano tranquillamente se senza occupare una quantità eccessiva di memoria, mentre ci sono dei "mostri" scritti in Java (e qualcuno anche .NET) che si succhiamo memoria, memoria, memoria, memoria.
Secondo me la cosa è dovuto un po' alla "mentalità" tipica di chi programma in Java, che porta a cataste di oggetti che chiamano cataste di metodi per fare quattro boiate... quando vedo perle come questa (http://ws.apache.org/axis/java/apiDocs/org/apache/axis/components/net/SocketFactoryFactory.html)
mi viene il dubbio che forse ho ragione...
Per inciso Eclipse usa un toolkit grafico nativo (le awt) a suo tempo nato, oltre per il look 'n feel, perchè quello cross-platform di Java era troppo pesante ..
ehmm..
SWT Standard Widget Toolkit :p
E cmq mi piacciono di + le SWT di eclipse delle AWT di Netbeans :O
ehmm..
SWT Standard Widget Toolkit :p
Sì, chiedo scusa per il refuso :p, ora correggo[/QUOTE]
quando vedo perle come questa (http://ws.apache.org/axis/java/apiDocs/org/apache/axis/components/net/SocketFactoryFactory.html) :rotfl: oddio bellissima
^TiGeRShArK^
24-08-2007, 18:05
:rotfl: oddio bellissima
ah ecco da dove era saltato fuori il tab della documentazione di axis.. :mbe:
certo che per fare una factory di una factory ce ne vuole di fantasia :stordita:
io a volte ho l'impressione che mo' ti segnalo :huh:
Mi segnali per cosa, per aver letto male e averci usato pure un tono arrogante?
"Aridaje" allora lo dico io... :rolleyes:
E xkè forse firefox o l'ultima versione di office su quei pc vanno meglio? :mbe:
Io non sto confrontando prodotti in particolare. E' chiaro che c'è la freccia in Java e il cesso in C++. Vedo comunque che ci sono programmi nativi anche dai requisiti hardware piu' alti di quelli di un IDE che su un PC di fascia bassa girano decentemente, rispetto a un programmone scritto in Java. Anche perchè in Java di programmi complessi e grossi ci sono solo i tool di sviluppo :fagiano:
Nessuno sta dicendo che siano delle piume, ma per quello che deve fare, almeno dall'esperienza che ho avuto io, Eclipse è quanto di meglio ci sia.
Nessuno non proprio, se non ricordo male hai detto che Eclipse non ha niente da invidiare in quanto a velocità (ma lo stesso dicasi per Netbeans). Il che non è proprio vero. Per le funzionalità non mi pronuncio perchè siamo OT anche se io preferisco nettamente Netbeans.
Ahhh la buona vecchia diatriba Java vs C++. Me l'ero quasi dimenticata. Quante cialtronate si sentivano. E quante se ne sentono ancora...
Ahhh la buona vecchia diatriba Java vs C++. Me l'ero quasi dimenticata. Quante cialtronate si sentivano. E quante se ne sentono ancora...
Dal tuo avatar suppongo che per cialtronata si intenda qualsiasi cosa violi la sacra perfezione di Java.
Potresti per esempio, dall'alto delle conoscenze superiori di cui disponi, indicarci la retta via mostrando a noi poveri comuni mortali ove pecchiamo con cialtronate comuni. No perchè arrivare cosi in una discussione come se tu fossi l'eletto è abbastanza irritante, oltre che non aggiunge niente alla discussione se non mostrare agli altri di quali verità superiori sei dotato. Supponendo io stesso abbia detto cialtronate (non lo escludo, sono mortale), allora io ti imploro: ho bisogno di luce.
Il mio avatar significa qualcos'altro. Forse si vede male ma c'è scritto "pojo". E' velatamente critico verso certe evoluzioni della piattaforma Java.
Non cito le baggianate perchè è come puntare il dito contro tizio o caio. E' una questione umana, tutti ne diciamo. Constatavo semplicemente come queste tendano ad accumularsi quando si cerchi di accoppiare certe cose. Java e C++ sono un classico da questo punto di vista.
Noto che tu la butti sul personale ma è una causa persa. Io non credo di essere l'eletto, lo sono.
io lo sapevo che eri un Plain Old Java Object Warrior :sofico:
comunque a parte le baggianate che possiamo aver detto tutti.. sia ben chiaro che anche io considero il confronto tra questi due linguaggi inutile, come anche il confronto tra managed e non-managed.
non vedo per quale motivo uno dei due approcci dovrebbe essere superiore all'altro considerando che nessuno dei due domina l'altro (nel senso che è migliore sempre) e quindi continueranno ad avere senso di esistere entrambi
Il mio avatar significa qualcos'altro. Forse si vede male ma c'è scritto "pojo". E' velatamente critico verso certe evoluzioni della piattaforma Java.
Non cito le baggianate perchè è come puntare il dito contro tizio o caio. E' una questione umana, tutti ne diciamo. Constatavo semplicemente come queste tendano ad accumularsi quando si cerchi di accoppiare certe cose. Java e C++ sono un classico da questo punto di vista.
Noto che tu la butti sul personale ma è una causa persa. Io non credo di essere l'eletto, lo sono.
Niente di personale è che dal tono sembrava volessi dire "fermi tutti so arrivato io". :asd: :D
^TiGeRShArK^
25-08-2007, 00:17
Nessuno non proprio, se non ricordo male hai detto che Eclipse non ha niente da invidiare in quanto a velocità (ma lo stesso dicasi per Netbeans). Il che non è proprio vero. Per le funzionalità non mi pronuncio perchè siamo OT anche se io preferisco nettamente Netbeans.
Quanto a funzionalità generali integrate anch'io preferisco netbeans e spesso lo consiglio..
ma quanto a scrivere codice..
bhè..
ho confrontato TUTTE le versioni di netbeans fino alla 5.5 con eclipse fino ad europa.
Per scrivere codice java PURO senza interfacce grafiche, codice web e quant'altro, eclipse non ha uguali ;)
La 6.0 preview di netbeans ancora la devo provare onestamente, ma permettimi qualche dubbio così sulla fiducia :D
ma quanto a scrivere codice..
bhè..
ho confrontato TUTTE le versioni di netbeans fino alla 5.5 con eclipse fino ad europa.
Per scrivere codice java PURO senza interfacce grafiche, codice web e quant'altro, eclipse non ha uguali ;)
Perchè? Dov'è che Eclipse è piu' forte? Non seguo piu' Eclipse dalla 3.3 :fagiano:
La 6.0 preview di netbeans ancora la devo provare onestamente, ma permettimi qualche dubbio così sulla fiducia :D
Ho visto che ci sono nuovi tool da paura nella 6.0, ma non conoscendo i punti di forza di Eclipse che citavi prima, non ti so dire onestamente.
La 6 ha l'editor di codice nuovo di zecca. Con la M10 le differenze si vedono. Comunque Eclipse, Netbeans... certo sono applicazioni notevoli ma parliamo sempre di moscardini, gazzelle, libellule. Il client JFB di Fiducia da solo ha 10 milioni di linee. Ed è una piuma rispetto a BARX. Programmi magari poco noti al grande pubblico ma che girano su centinaia di migliaia di PC da almeno sei anni. E sei anni fa le prestazioni della piattaforma Java erano ridicole rispetto a quelle di oggi.
E poi non dimentichiamo la piattaforma ME. Un po' castrato, certo, ma è pur sempre un bel po' di Java quello che ci gira.
Ma si può veramente fare il confronto con C++? Uno ha un sistema di tipi l'altro no, uno controlla il limite di accesso ai componenti degli array l'altro no, uno ha i metodi virtuali salvo eccezioni l'altro il contrario, uno carica le classi dinamicamente l'altro staticamente, la versione standard di uno è garbage collected l'altro unmanaged... cioè praticamente sono l'uno il contrario dell'altro!
La 6 ha l'editor di codice nuovo di zecca. Con la M10 le differenze si vedono. Comunque Eclipse, Netbeans... certo sono applicazioni notevoli ma parliamo sempre di moscardini, gazzelle, libellule. Il client JFB di Fiducia da solo ha 10 milioni di linee. Ed è una piuma rispetto a BARX. Programmi magari poco noti al grande pubblico ma che girano su centinaia di migliaia di PC da almeno sei anni. E sei anni fa le prestazioni della piattaforma Java erano ridicole rispetto a quelle di oggi.
JFB, BARX? Di cosa parli? Nomi mai sentiti.
JFB, BARX? Di cosa parli? Nomi mai sentiti.
Bel tono, complimenti.
Parlo della vacca vittoria, non è ovvio? Sono applicazioni desktop Java una da 10 e l'altra da 14 milioni di righe. Tutte e due hanno più di sei anni. Certo non hanno l'importanza di WinZip ma una gestisce 3.2 miliardi di transazioni bancarie all'anno, l'altra è il prodotto di punta di una società che non è certo un'azienda del calibro di ID Software ma riesce comunque a tirar su una ciotola di riso e 2 miliardi di dollari l'anno.
Sempre perchè io sono una perla d'uomo dico pacatamente che considerare Netbeans o Eclipse "grosse applicazioni desktop" non è propriamente esatto. Sono certamente dei bei pacconi ma ce ne sono di più grosse e sembra che, per quanto voluminosi, facciano il loro dovere.
Bel tono, complimenti.
Parlo della vacca vittoria, non è ovvio?
:confused:
Scusami un attimo è forse un reato non conoscere simili programmi o cosa? Ma state tutti surriscaldati quà dentro? :doh:
Sempre perchè io sono una perla d'uomo dico pacatamente che considerare Netbeans o Eclipse "grosse applicazioni desktop" non è propriamente esatto. Sono certamente dei bei pacconi ma ce ne sono di più grosse e sembra che, per quanto voluminosi, facciano il loro dovere.
Bhè, io personalmente non le conoscevo. Generalmente non guardo roba finanziaria. Non è la mia materia e non me ne interesso.
la versione standard di uno è garbage collected l'altro unmanaged... cioè praticamente sono l'uno il contrario dell'altro!
premessa: niente di personale ma noto che si continua a fare lo stesso errore in questo thread
perchè la gente continua a confondere la presenza del garbage collector con il fatto che il codice sia managed? sono due cose totalmente scorrelate e la definizione di managed è stata inventata da MS per cui penso che loro sappiano quale sia http://blogs.msdn.com/brada/archive/2004/01/09/48925.aspx
Uno ha un sistema di tipi l'altro no
Che intendi ?
uno controlla il limite di accesso ai componenti degli array l'altro no
Con i vector il limite viene controllato. In C++ bisogna usare vector, se si usano gli array standard si fa a proprio rischio e pericolo.
Ho usato il termine "unmanaged" a sproposito :fagiano:. L'implementazione più diffusa di Java ha il gc, c++ non ha un gc. Non è una differenza tra le lingue (entrambe possono usare o non usare un gc) ma, all'atto pratico, Java ha 'sto gc.
Per "sistema di tipi" intendo una radice predefinita per i tipi definiti attraverso il linguaggio. java.lang.Object vs niente.
Con i vector il limite non viene controllato oppure no. Ad esempio at(n) controlla ma [n] no. Ma il linguaggio di programmazione C++ non prevede che l'indice di accesso agli elementi di un array stia nei limiti dell'array.
Per "sistema di tipi" intendo una radice predefinita per i tipi definiti attraverso il linguaggio. java.lang.Object vs niente.
domandone: ma anche i tipi primitivi hanno questa caratteristica? :fagiano:
Non "i tipi definiti dal linguaggio" ma attraverso il linguaggio. Non essendo possibile introdurre un nuovo tipo primitivo essi risultano per definizione esclusi.
ah ecco da dove era saltato fuori il tab della documentazione di axis.. :mbe:
certo che per fare una factory di una factory ce ne vuole di fantasia :stordita:
Il mondo e' pieno di programmatori fantasiosi allora...
http://www.google.com/codesearch?q=FactoryFactory&hl=en&btnG=Search+Code
^TiGeRShArK^
25-08-2007, 17:52
Il mondo e' pieno di programmatori fantasiosi allora...
http://www.google.com/codesearch?q=FactoryFactory&hl=en&btnG=Search+Code
:mbe:
ma a ke kazz serve una factory di una factory? :stordita:
^TiGeRShArK^
25-08-2007, 17:59
Perchè? Dov'è che Eclipse è piu' forte? Non seguo piu' Eclipse dalla 3.3 :fagiano:
Ho visto che ci sono nuovi tool da paura nella 6.0, ma non conoscendo i punti di forza di Eclipse che citavi prima, non ti so dire onestamente.
Intendo tutti i vari strumenti di refactoring, i code templates, call & type hierarchy, e queste sono le prime cose che mi vengono in mente.
X quanto riguarda il refactoring netbeans ha fatto enormi passi avanti ma ancora alla versione 5.5 restava indietro.
Cmq ora non ricordo le varie cose nel dettaglio, ma mi sono messo ad usare netbeans per qualche giorno e ho notato che diversi strumenti di eclipse mancavano....
:mbe:
ma a ke kazz serve una factory di una factory? :stordita:
Qualcuno qui te lo puo' spiegare in modo molto chiaro... :D
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
^TiGeRShArK^
25-08-2007, 19:15
Qualcuno qui te lo puo' spiegare in modo molto chiaro... :D
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
:asd:
spettacolare :D
e il dramma è ke basta guardarsi in giro x accorgersi ke è verissimo...:stordita:
cdimauro
25-08-2007, 19:22
evidentemente un bech non significa niente.. di sicuro non hanno testato il comportamento di un sistema operativo che è ben più complesso e meno ripetitivo di un bench.
Che c'entra: vuoi dirmi che soltanto un s.o. è degno di essere "cronometrato"? Non esistono altre applicazioni che meritano lo stesso trattamento?
E' vero che il s.o. lo si usa sempre e comunque, ma è del tutto trasparente, perché gli utenti il computer lo usano con le APPLICAZIONI che gli interessano, e per cui quindi vale la pena di eseguire dei benchmark. ;)
Ovviamente anche il s.o. ha il suo peso, sia chiaro, ma la "fetta più grossa" dei tempi di esecuzione è a carico dell'applicazione.
i linguaggi interpretati si comportano decisamente meglio nei compiti ripetitivi e nonostante questo non raggiungono mai le prestazioni dei linguaggi non interpretati, poi c'è da dire che valutare le prestazioni di un linguaggio interpretato è più complesso perchè bisognerebbe anche aggiungere il carico dovuto all'interprete (cosa che raramente si fa nei bench)
I linguaggi managed non sono sempre interpretati, ma tante volte compilati (spesso in tempo reale).
Inoltre quando si fa un benchmark si calcola il tempo dall'inizio dell'applicazione alla sua fine, per cui il tempo speso da compilatore JIT e garbage collector è sempre INCLUSO nella computazione finale.
bisogna vedere se per un SO è più importante la portabilità o le prestazioni, perchè non si può avere la botte piena e la moglie ubriaca
Ormai si hanno ottime prestazioni anche a fronte di un core / framework portabile (e relative applicazioni): vedi il link che ha riportato Danilo.
Parlo di framework e applicazioni perché sono le cose per cui ha più senso parlare di portabilità (sempre per il discorso che facevo all'inizio: all'utente interessa usare le applicazioni).
comunque sia solitamente si intende che un'applicazione è portabile se gira su sistemi operativi diversi senza modifiche.. mi risulta un pò difficile pensare a un SO che gira su sistemi operativi diversi :stordita:
Risulta anche a me, ma non all'hypervisor di una virtual machine. :p
il solo problema di portabilità in un SO riguarda l'architettura, ma quello è un problema di altro tipo e gli ambienti managed non servono a molto
L'architettura conta fino a un certo punto, tant'è che il codice a esso legato è ridotto ai minimi termini ormai.
Un ambiente managed può, comunque, essere MOLTO utile su particolari architetture che, ad esempio, non sono dotate di protezione della memoria (e ti assicuro che ce ne sono tantissime. E' che noi siamo troppo ben abituati con x86).
certo a tutto si può rimediare, ma a un prezzo! in un SO ci sono dei pezzi di codice che sono critici, che tradotto in parole povere significa che se ci guadagni anche solo un ciclo di clock potresti avere un vantaggio enorme in termini di prestazioni (certo è un pò esagerato per rendere l'idea, ma tanto la differenza tra ASM e .NET non è un ciclo di clock ;) )
ovviamente si tratta di piccolissimi pezzi di codice, nessuno è così pazzo da rempire il codice di assembly
Dimentichi che con architetture particolarmente spinte sul fronte dell'esecuzione out-of-order (come gli x86 da un bel po' di anni a questa parte) ha poco senso ottimizzare a manina il codice in assembly: il compilatore di un linguaggio ad alto livello generalmente è capace di generare codice più efficiente.
ps. io il D l'ho visto per la prima volta pochi giorni fa, ma mi sembra di averlo sempre conosciuto ihih leggi qua http://www.digitalmars.com/d/overview.html
E' molto interessante, ma anche pochissimo usato. Peccato.
cdimauro
25-08-2007, 19:30
Non conosco Delphi, ma in C# dataset e datasource sono 2 mondi distinti, il primo è legato al "modello di programmazione" tipico dell'1.1 e l'altro, tipico del 2.0, è nato grazie all'introduzione dei generics.
OK (comunque per capire meglio mi dovrei documentare, ma al momento, non avendo interesse verso il C#, ne faccio a meno. :p).
Una cosa che non mi piace del C# è questo stretto legame che viene a crearsi tra linguaggio ed editor, tanto che si creano estensioni al linguaggio per rimediare a gravi problemi dell'editor, e si usa l'editor per scoraggiare tecniche di programmazione ritenute "obsolete".
Questo non piace assolutamente anche a me.
Si mi riferisco a tutto quello che sta dietro alla creazione di un oggetto, a tutta la gerarchia di classi da cui deriva, a tutti i campi spesso inutili che un oggetto si porta dietro (penso ad esempio ai DateTime).
Dopotutto la completezza del framework in qualche modo la devi pagare.
Esattamente, ed è un problema che con Java c'è da tempo (se non ricordo male con AWT per visualizzare una finestra con "Hello, world!" vengono caricate 600 classi, e 800 con SWT. O qualcosa del genere).
D'altra parte un framework come quello permette di essere più produttivi, grazie a tante "ruote" che non bisogna inventarsi perché già a disposizione.
Che dire sul mio portatile vanno via quasi 300MB (100MB l'svchost e 180MB il processo dwm da esso dipendente) solo per il reparto grafico e la versione di Vista non dovrebbe avere Aero.
Non so che dire: a quanto pare abbiamo due esperienze molto diverse.
Lo convinci te il cliente a sborsare i soldi per aggiornare un intero sistema funzionante (anche se scritto da cani) se non ne sente la necessità impellente?
Inoltre non è che in 10 anni non è mai stato aggiornato, si è evoluto nelle funzionalità, ma sempre in VB6 è rimasto, con tutti i difetti del caso.
E poi dove lavoro usavano VB6 fino all'anno scorso...
Beh, se non vogliono metter mano al portafogli, allora che si accontentino di quello che hanno. :p
Vista l'elevata obsolescenza del codice C# ho il vago sospetto che ciò puntualmente avverrà.
Vedremo. Non penso che l'obiettivo con cui è stato realizzato C# e fatto evolvere sia quello di rendere obsolete le vecchie applicazioni così velocemente: si dovrò pur arrivare a un certo livello di stabilità prima o poi. ;)
cdimauro
25-08-2007, 19:36
chiamalo compilato Just In Time o come vuoi, fatto sta che ha bisogno di una VM
Non sempre. Con .NET, ad esempio, puoi scegliere di precompilare tutti gli assembly di un'applicazione nei binari dell'architettura, la prima volta che viene eseguita.
come no.. io c'ero :fagiano:
Io pure e ricordo diversamente. Come al mettiamo? Link please, così vediamo chi ha ragione.
ah non dirlo a me che l'ho usato per fare di tutto e lo uso ancora :D di certo non mi sognerei mai di dire che la reattività è il suo forte (però effettivamente VS2005 l'ho trovato anche peggiore).
purtroppo sul portatile ho solo 512Mb di RAM e sono al limite per eclipse.. per fare un paragone kdevelop e codeblocks hanno caratteristiche simili (anche se inferiori oggettivamente) eppure sono proprio su un altro pianeta in quanto a reattività
Dovresti provare l'ultima versione di Eclipse: l'ho vista girare su un PC con XP HE con soli 512MB ed era MOLTO, ma molto più reattivo di quella che avevo usato ai tempi dello sviluppo di Diamonds. A me e al mio collega sembra un'applicazione win32, poi siamo andati a vedere e c'erano i pacchetti Java... :p
cdimauro
25-08-2007, 19:40
Il problema sorge quando si eseguono determinate applicazioni su PC non proprio all'ultimo grido e li la percezione è tutt'altra che quel 95% di codice nativo.
Sarei curioso di provare adesso, con Java 6.
Eclipse è semplicemente un mulo, Netbeans altrettanto.
Per Eclipse vedi sopra. E' talmente migliorato che un mio collega (che lavora nella divisione mobile sviluppando giochi Java per telefonini), che ha sempre usato NetBeans e schifato Eclipse, adesso è passato in pianta stabile a quest'ultimo. :p
O possiamo citare anche un Poseidon for UML, dove ai tempi di avvio biblici si verificano tempi di esecuzione non proprio fulminei nell'usare componenti GUI non proprio fuori norma.
Quando l'ho provato pure io era molto pesante, ma può essere un problema dell'applicazione.
Su un misero portatile con Athlon XP 1500+ con 512MB di ram, per esempio, la differenza in performance si nota drasticamente: un ipotetico Eclipse ad avviarsi ci mette quanto l'intero KDE e molto piu' di Gnome. Magari l'esecuzione non è lentissima, anzi considerando la metodologia di esecuzione, la velocità è sicuramente impressionante. Ma i tempi di avvio sono ancora drastici. In un moderno PC magari queste cose non si notano ma in genere le mancanze di performance si notano piu' sui PC che non hanno cicli da sprecare. E nei benchmark, come diceva qualcuno, queste cose non si considerano.
Vedi sopra per Eclipse. Per il resto mi piacerebbe vedere dei test con delle applicazioni reali per chiarire meglio la situazione.
cdimauro
25-08-2007, 19:59
Io tutto questo interesse in calo non lo vedo sinceramente e non vedo nemmeno tutto questo interesse in crescita per C#.
Qualche tempo fa ho visto delle statistiche e la situazione è quella che ho delineato. Confermata finora dallo scambio di opinioni con altri programmatori.
Nuove API nascono in C/C++ tutti i giorni cosi come nuovi software. Si possono fare milioni di esempi a riguardo.
Lo stesso si può dire anche per gli altri linguaggi / ambienti.
Molte API importanti hanno subito dei porting verso Java e di C# nemmeno l'ombra (vedi ad esempio QT Jambi).
Mi sembra normale: C# ha appena 6 anni di vita. Nonostante tutto ha un notevole supporto, in continua espansione. Non è affatto poco: tutt'altro.
In ambito mobile .NET compact è morto prima ancora di nascere e paragonato a MIDP si mette a piangere.
Idem come sopra: è presto per delle sentenze definitive.
Per il resto su smart phone C e C++ dominano.
O Java?
Per il server side, oltre ai metodi tradizionali in cui PHP/Apache la fanno da padroni da sempre,
Windows e IIS/ASP sono in crescita però, al contrario di quello che ci si potrebbe aspettare.
Su PHP preferisco non commentare.
è molto piu' facile incontrare tecnologie JEE + Tomcat.
Anche IIS/ASP.
Su piattaforme non Microsoft, come ad esempio Mac, Apple produce un JDK nativo MacOSX e non ha mai preso in considerazione l'ipotesi di implementare un framework .NET
Perché ha deciso di affidarsi a Mono per .NET.
Comunque la politica di Apple è quella di sfruttare più che può il lavoro della comunità open source.
Mono semplicemente non è un'opzione.
Perché è ancora immaturo come progetto.
Certo, come dici il compito non è di Microsoft portare l'intera piattaforma su macchine diverse (opinabile) ma Sun lo fa ed è questo che importa.
No, Sun il porting di Java lo fa soltanto sulle piattaforme per cui ha interessi. Tra l'altro le implementazioni di Java non sono tutte le stesse; ad esempio le versioni x64 non sono complete, oppure certe caratteristiche sono disponibili soltanto per alcune piattaforme.
Basta vedere lo stato dei porting di Java per s.o. diversi da quelli elencati qui: http://www.java.com/it/download/
All'attualità non si può dire che .NET abbia la stessa valenza di Java su macchine non Microsoft perchè le implementazioni sono immature e incomplete. Quello che ci sarà nel futuro non lo guardo perchè stiamo facendo un discorso proiettato nel presente.
Indubbiamente, ma vedi sopra: MS non ha alcun interesse a supportare piattaforme diverse da Windows.
E' già un'ottima cosa il fatto che abbia rilasciato pubblicamente e fatto standardizzare sia la piattaforma .NET che i linguaggi come C#.
Moltissime aziende hanno intranet basate su servizi Java. Magari per .NET c'è qualche crescita in qualche direzione, ma non è tutto questo rose e fiori.
Dai dati che ho visto qualche tempo fa la crescita è molto forte.
cdimauro
25-08-2007, 20:03
Io da i grafici postati vedo test che snobbano 10 anni di innovazione in materia di compilatori. E la data dei test risale anche a periodi in cui i compilatori C++ è noto che non fossero gran che ottimali. Inoltre il flag -O2 è un'ottimizzazione generica quindi non è corretta. Le VM guardano al tipo di processore in uso quando eseguono codice e si regolano di conseguenza. Io avrei usato anche i flag -mtune e -march. E soprattutto vorrei vederlo adesso. Il flag -fvisibility=hidden ha portato nuovi livelli di performance nella rilocazione dei simboli in programmi C++.
Ma tu dimentichi gli enormi passi in avanti che sono stati fatti dai compilatori JIT per Java e .NET però. :p
E .NET è una piattaforma MOLTO giovane, tra l'altro. ;)
Non è forse un tipo di ottimizzazione che si fa anche in qualsiasi altro programma scritto sulla terra? In nessun programma degno di questo nome non si cerca di minimizzare allocazione/deallocazione ai minimi termini e solo quando serve. Questo non risolve il problema perchè queste considerazioni erano chiaramente incluse nel discorso, parliamo di applicazioni scritte comunque a regola d'arte. Il codice Java è sicuramente velocissimo (considerando il metodo di esecuzione) ma i tempi di start-up piu' le latenze del GC non sono trascurabili. E sinceramente si avverte. La questione del 5 al 20% di latenza media non l'ho misutato io ma è uno studio fatto da IBM con applicazioni un tantino piu' complesse di un benchmark.
Come dicevo prima, il tempo di CPU consumato dal GC (come pure quello del compilatore JIT) è incluso nel tempo totale di esecuzione dell'applicazione.
Rimane il tempo di startup, è vero, ma con .NET puoi anche decidere di compilare l'intera applicazione in un eseguibile nativo. ;)
cdimauro
25-08-2007, 20:05
Perchè, ti risulta difficile credere che il numero di API esistente in circolazione scritto in C/C++ supera di brutto quello fornito dal solo Win32? :confused:
Beh, qui però stiamo facendo confronti senza avere dati in mano.
cdimauro
25-08-2007, 20:10
Io a volte ho l'impressione di parlare con gente che risponde senza capire quello che uno sta dicendo... :mbe:
Ho parlato di nuove librerie che continuamente nascono native in C/C++ (sempre che un cane&porco possa scrivere una libreria che si possa definire tale) per rispondere a cdimauro del fatto che c'è sempre meno interesse in C/C++ e di come non ci sia tutto questo fiorire per quanto riguarda C#/.NET in generale. Mi rispondi con "aridaje" per poi parlare di "set piu' o meno ufficiali" e ancora non riesco a capire che cosa vuoi dire.
L'interesse non c'è soltanto per C# e .NET (e c'è, in continua crescita), ma per tanti altri linguaggi che si stanno rosicchiando non poche quote di mercato.
Parlo di Python per diversi tipi di applicazioni (anche scientifiche), ma anche Ruby che sta avendo un enorme boom nel settore web con Ruby on Rails.
E' ovvio che se linguaggi come questi conquistano quote di mercato, altri le perderanno. E non è affatto detto che sia Java a farne di spese.
cdimauro
25-08-2007, 20:13
Il mio avatar significa qualcos'altro. Forse si vede male ma c'è scritto "pojo". E' velatamente critico verso certe evoluzioni della piattaforma Java.
Nemmeno tanto velatamente ormai... :p
cdimauro
25-08-2007, 20:15
io lo sapevo che eri un Plain Old Java Object Warrior :sofico:
comunque a parte le baggianate che possiamo aver detto tutti.. sia ben chiaro che anche io considero il confronto tra questi due linguaggi inutile, come anche il confronto tra managed e non-managed.
non vedo per quale motivo uno dei due approcci dovrebbe essere superiore all'altro considerando che nessuno dei due domina l'altro (nel senso che è migliore sempre) e quindi continueranno ad avere senso di esistere entrambi
Migliore sempre non lo si può affermare, ma mediamente migliore (per gli ambienti managed) per applicazioni non specializzate (come quelle di cui s'è discusso finora) è opinione abbastanza consolidata.
Io, poi, oltre per gli ambienti managed aggiungo la mia preferenza per quelli basati su linguaggi dinamici. ;)
cdimauro
25-08-2007, 20:19
:confused:
Scusami un attimo è forse un reato non conoscere simili programmi o cosa? Ma state tutti surriscaldati quà dentro? :doh:
Beh, c'hai messo anche del tuo però, quando hai generalizzato dicendo che applicazioni Java di un certo spessore per ambienti desktop non se ne sono viste, a parte gli ambienti di sviluppo.
Da lì, a mio modesto avviso, i commenti di PGI-Bis e il fatto che ti meravigli se l'ambiente risulta surriscaldato.
Bhè, io personalmente non le conoscevo. Generalmente non guardo roba finanziaria. Non è la mia materia e non me ne interesso.
Allora è meglio non generalizzare troppo, non credi? ;)
Beh, qui però stiamo facendo confronti senza avere dati in mano.
Ma in questo caso i dati in mano non servono. E' come quando si fanno le prime lezioni di Inglese e si studiano i "countable" e gli "uncountable".
Le API a corredo di Windows sono countable, il complementare di questo insieme è uncountable. :asd:
Beh, c'hai messo anche del tuo però, quando hai generalizzato dicendo che applicazioni Java di un certo spessore per ambienti desktop non se ne sono viste, a parte gli ambienti di sviluppo.
Ok, correggo nel sostituire la frase "applicazioni desktop di un certo spessore" con la frase "applicazioni desktop per utenti comuni". Ora i conti tornano e quindi dovremmo togliere anche Netbeans e Eclipse, visto che sono comunque applicazioni specializzate tanto quelle finanziarie. Tolto LimeWire, Azureus, qualche futility quà e la, Sunflow e qualcos'altro che dimentico/non conosco, cosa c'è in Java (ma anche in C#) che faccia gridare alla ribalta dei linguaggi di programmazione? (parlo nel mondo desktop, perchè il mondo della telefonia cellulare Java domina avendo festeggiato il miliardo di installazioni complessive). Un'altro settore in cui Java è forte che mi viene in mente è il mondo legato ai servizi intranet aziendali. Per il resto? Abbiamo coperto il suo intero segmento secondo me.
Cominciamo gli elenchi e diamo il via alle evidenze sperimentali.
Da lì, a mio modesto avviso, i commenti di PGI-Bis e il fatto che ti meravigli se l'ambiente risulta surriscaldato.
Del surriscaldamento mi meraviglio comunque, perchè oltre a installare un buon condizionatore, si potrebbero iniziare le frasi con "no, guarda che ci stanno queste applicazioni: <elenco>".
Mi surriscaldo perchè sono sensibile alle rudezze sintattiche. Se Tizio chiede a Caio di fare dei nomi e dopo che Caio li ha fatti si vede rispondere con un "di cosa parli? Nomi mai sentiti", che Caio s'incazzi non è poi tanto strano.
Applicazioni desktop. ArtOfIllusion e ImageJ. Dico queste perchè sono quelle che uso normalmente. Però non è che le usi perchè sono scritte in Java. Le uso perchè fanno qualcosa che mi serve. "Serve" in senso lato, ovviamente.
Il suo intero segmento copre anche le applet che, contrariamente a quanto si immagina, sono tutt'altro che morte. BMW, ad esempio, ne ha una molto carina sul suo sito.
http://www.bmw.co.uk/bmwuk/ecom4/frameset
Personalmente ho sempre ritenuto assurdo che Java, come intera piattaforma, fosse più usato per i server che sui desktop. Le applicazioni desktop sono, a mio modestissimo avviso, proprio quelle in cui maggiore è il vantaggio della piattaforma. Pensiamo alla migrazione dai 32 ai 64 bit, o al passaggio da XP a Vista ma anche alla possibilità di creare applicazioni che siano poi distribuibili anche sugli Unix.
Io penso che la ragione dell'assurdo stia in due punti. Il primo è il know-how che le software house hanno sui sistemi precedenti. Parlare di linguaggi significa anche parlare dell'investimento che le aziende hanno fatto sull'addestramento del personale, sullo sviluppo di framework e metodologie interne legate a quei linguaggi. Il secondo è la naturale reversibilità del codice byte della piattaforma Java. Essendo nato in congiunzione con il linguaggio Java, esso mantiene una struttura che, per quanto offuscabile, permette comunque la ricostruzione degli elementi del programma. E nell'ambito desktop si fanno i salti mortali doppi e tripli per evitare che la gente possa curiosare dove dovrebbe poter fare.
Mi surriscaldo perchè sono sensibile alle rudezze sintattiche. Se Tizio chiede a Caio di fare dei nomi e dopo che Caio li ha fatti si vede rispondere con un "di cosa parli? Nomi mai sentiti", che Caio s'incazzi non è poi tanto strano.
Risolviamo le rudezze sintattiche (poco tempo a disposizione e comunque meglio rudezze sintattiche che risposte senza senso):
"Egregio sig. PGI-Bis, non avendo purtroppo mai sentito nomina dei programmi da lei gentilmente citati poc'anzi, le chiedo spiegazioni in merito alla tipologia dei suddetti software.
Come lei mi ha riferito, Netbeans ed Eclipse non sono propriamente ciò che potremmo definire una tipologia software estremamente complessa. Sarebbe così gentile, allora, da illustrarmi brevemente le mansioni principali dei suddetti software? Colgo inoltre occasione per ringraziarla anticipatamente della risposta che mi vorrà dare e le porgo i piu' cordiali e sentiti saluti."
Il conte mjordan da Sirmione.
P.S.: Vorrei poter utilizzare anche un sigillo in ceralacca rossa con lo stemma del mio casato ma qui purtroppo posso premere solo il bottone "Invia risposta".
Ora accendi il condizionatore e leggi i miei messaggi piu' rilassatamente perchè non avevo intenzione di aggredire nessuno. ;)
EDIT: Prima che ti incazzi di nuovo, ti premetto che sto scherzando :D (ho il condizionatore a +23°C :sofico: )
cdimauro
26-08-2007, 09:04
Ma in questo caso i dati in mano non servono. E' come quando si fanno le prime lezioni di Inglese e si studiano i "countable" e gli "uncountable".
Le API a corredo di Windows sono countable, il complementare di questo insieme è uncountable. :asd:
Allora è meglio non parlare di "conteggio delle API". ;)
Per inciso: come programmatore m'interessano le API che posso utilizzare direttamente. Con Python, ad esempio, se ho bisogno di cancellare file, creare cartelle, ecc. uso ciò che la libreria os.* mette a disposizione: sarà poi lei a "sbrogliare la matassa" in base al s.o. su cui gira.
cdimauro
26-08-2007, 09:13
Ok, correggo nel sostituire la frase "applicazioni desktop di un certo spessore" con la frase "applicazioni desktop per utenti comuni". Ora i conti tornano e quindi dovremmo togliere anche Netbeans e Eclipse, visto che sono comunque applicazioni specializzate tanto quelle finanziarie. Tolto LimeWire, Azureus, qualche futility quà e la, Sunflow e qualcos'altro che dimentico/non conosco, cosa c'è in Java (ma anche in C#) che faccia gridare alla ribalta dei linguaggi di programmazione? (parlo nel mondo desktop, perchè il mondo della telefonia cellulare Java domina avendo festeggiato il miliardo di installazioni complessive). Un'altro settore in cui Java è forte che mi viene in mente è il mondo legato ai servizi intranet aziendali. Per il resto? Abbiamo coperto il suo intero segmento secondo me.
Cominciamo gli elenchi e diamo il via alle evidenze sperimentali.
Per cominciare c'è questo http://www.java.com/en/desktop/ ;)
Ma ho la non vaga impressione che sia soltanto la punta dell'iceberg. :p
Del surriscaldamento mi meraviglio comunque, perchè oltre a installare un buon condizionatore, si potrebbero iniziare le frasi con "no, guarda che ci stanno queste applicazioni: <elenco>".
Comunque la tua entrata è stata un po' troppo da troll, eh!
Tempo fa m'è capitata la stessa cosa quando, parlando di Python, mi è stato detto che al più posso farci una partita a tresette. Capirai bene che, lavorandoci da quasi 3 anni, mi sono un po' incazzato.
Meglio, quindi, evitare di esprimere dei giudizi così secchi se non si conosce bene la realtà di cui si sta parlando. ;)
Che c'entra: vuoi dirmi che soltanto un s.o. è degno di essere "cronometrato"? Non esistono altre applicazioni che meritano lo stesso trattamento?
no intendevo dire che il fatto che i bench danno un risultato non significa che un software complesso quanto un SO dia lo stesso risultato
Ovviamente anche il s.o. ha il suo peso, sia chiaro, ma la "fetta più grossa" dei tempi di esecuzione è a carico dell'applicazione.
mah a me risulta che:
In alcune delle prime versioni "alpha" di Vista (a grandi linee le Milestone 4, build 4xxx) l'interfaccia utente era implementata utilizzando codice gestito .NET, in modo da garantire una maggiore sicurezza e protezione, ma era percepibile un notevole peggioramento delle prestazioni. Dalla beta 1, invece, tutta l'interfaccia è nuovamente scritta in codice nativo.
I linguaggi managed non sono sempre interpretati, ma tante volte compilati (spesso in tempo reale).
ho il vizio di usare la parola interprete per indicare tutte e due le categorie :p
Inoltre quando si fa un benchmark si calcola il tempo dall'inizio dell'applicazione alla sua fine, per cui il tempo speso da compilatore JIT e garbage collector è sempre INCLUSO nella computazione finale.
quello che non è incluso è l'uso della memoria e della CPU
Ormai si hanno ottime prestazioni anche a fronte di un core / framework portabile (e relative applicazioni): vedi il link che ha riportato Danilo.
però sarai daccordo con me che non si può avere la botte piena e la moglie ubriaca.. la portabilità porta inevitabilmente a un decadimento delle prestazioni. sta al programmatore valutare se questo è accettabile e in molti casi lo è effettivamente
Risulta anche a me, ma non all'hypervisor di una virtual machine. :p
a me l'hypervisor mi sta sullo stomaco :fagiano: e ti spiego anche perchè: mancanza di trasparenza da parte del SO, mancanza di controllo sul SO da parte dell'utente e altissima pericolosità di tale tecnologia.
non so se hai mai dato un'occhiata al blog Joanna Rutkowska negli ultimi anni... gli scenari che la virtualizzazione offre al malware sono a dir poco da preoccupanti
Un ambiente managed può, comunque, essere MOLTO utile su particolari architetture che, ad esempio, non sono dotate di protezione della memoria (e ti assicuro che ce ne sono tantissime. E' che noi siamo troppo ben abituati con x86).
guarda che qui c'è un equivoco :D io non sto dicendo che gli ambienti managed sono inutili, ma siete voi che dite che quelli non managed sono inutili. per quanto mi riguarda ci sono dei pro e dei contro per ognuno e a senconda di quello che bisogna fare conviene l'uno o l'altro.
ps. spesso si pensa che gli ambienti managed siano superiori soltanto per le caratteristiche dei linguaggi, ma questo non c'entra assolutamente niente. l'unica differenza è che il codice managed gira in una VM mentre quello non managed è nativo.
Dimentichi che con architetture particolarmente spinte sul fronte dell'esecuzione out-of-order (come gli x86 da un bel po' di anni a questa parte) ha poco senso ottimizzare a manina il codice in assembly: il compilatore di un linguaggio ad alto livello generalmente è capace di generare codice più efficiente.
si in genere è vero, ma a volte per fare cose di bassissimo livello è ancora più efficiente usare l'assembly direttamente (penso ad algoritmi in cui il know-how è alle stelle). se è un pezzo di codice critico può essere anche decisivo per le prestazioni
E' molto interessante, ma anche pochissimo usato. Peccato.
eh cosa vuoi.. è stato rilasciato a gennaio di quest'anno :cool:
comunque interessante questa statistica che lo vede in forte crescita http://www.tiobe.com/tpci.htm
poi si vede anche che python e ruby dopo lo scoppio iniziale stanno pian piano tornando nei ranghi.. penso che alla fine si ritaglieranno la loro fetta di mercato e lì ci rimarranno.
Io pure e ricordo diversamente. Come al mettiamo? Link please, così vediamo chi ha ragione.
ma non ci penso nemmeno! :Prrr: erano i tempi in cui skrivevo con le k e avevo i brufoli :sofico:
comunque mi fa piacere ricordare che oltre ad una marea di @zzate ho detto anche qualcosa che puntualmente si è avverato :O
ps. inoltre mi piacerebbe anche che fek sapesse che l'XP è stato argomento d'esame nella mia università (perchè lui sosteneva che le università sono sempre indietro e spiegano concetti obsoleti)
Dovresti provare l'ultima versione di Eclipse: l'ho vista girare su un PC con XP HE con soli 512MB ed era MOLTO, ma molto più reattivo di quella che avevo usato ai tempi dello sviluppo di Diamonds. A me e al mio collega sembra un'applicazione win32, poi siamo andati a vedere e c'erano i pacchetti Java... :p
l'ultima volta l'ho usato un paio di mesi fa.. è cambiato molto?
eh cosa vuoi.. è stato rilasciato a gennaio di quest'anno :cool:
:mbe: Mi risulta che sia disponibile da ben prima...
Il mio programmino in D preferito e' Gunroar (http://www.asahi-net.or.jp/~cs8k-cyu/windows/gr_e.html),
c'ha quel gusto un po' retro che piace tanto a chi come me e' cresciuto giocando al Bar :D
In effetti il primo documento sul D l'ho letto diversi annetti fa sul sito Digital Mars (ed era già disponibile il compilatore).
:mbe: Mi risulta che sia disponibile da ben prima...
la prima release stabile è del 2 gennaio 2007 ;)
la prima release stabile è del 2 gennaio 2007 ;)
Esiste anche un compilatore per Linux ?
Esiste anche un compilatore per Linux ?
si esiste sia il compilatore della digital mars (dmd) che quello basato su gcc (gdc).. io adesso sto usando gdc + code::blocks
ho trovato i pacchetti belli che compilati qui http://gdcgnu.sourceforge.net/ e poi ho installato code::blocks con tutti i plugins
l'unico difetto che posso lamentare è la mancanza di una documentazione completa (sul sito comunque c'è molta documentazione), ma ovviamente ci sarà tempo anche per quello
ps. ecco ad esempio il D è un linguaggio unmanaged che però fornisce un GC di default e tutti i costrutti che caratterizzano solitamente i linguaggi managed, anzi c'è pure di più ;)
ps. ecco ad esempio il D è un linguaggio unmanaged che però fornisce un GC di default e tutti i costrutti che caratterizzano solitamente i linguaggi managed, anzi c'è pure di più ;)
Difatti Remi Forax ha definito il D come un'incredibile raccolta di tutte le principali spazzature sintattiche create nell'ultimo decennio dai principali linguaggi di programmazione in un unico conveniente package :D
C'è proprio tutto e non so fino a che punto possa essere un vantaggio.
Sono pronto a scommettere che da qui a un anno avrà anche superpackages e closures.
Sono pronto a scommettere che da qui a un anno avrà anche superpackages e closures.
Cos'hai contro le closures ? :boxe: :D
Cos'hai contro le closures ? :boxe: :D
Nulla, si vanno solo ad aggiungere alla lista di caratteristiche sintattiche rindondanti. Fra un po' in Java ci saranno 10 modi diversi di fare la stessa identica cosa per ogni concetto esistente. :fagiano:
E poi quando si parla di leggibilità secondo me è anche molto soggettiva, la cosa. Per esempio, Neal Gafter fa l'esempio di come una classe locale anonima venga sostituita da una chiusura:
// Classe locale anonima
public class Client {
void doit(API api) {
api.doRun(new Runnable() {
public void run() {
snippetOfCode();
}
});
}
}
e questa la nuova versione secondo la proposta di Gosling e Gartner (e altri):
// Classe con chiusura
public class Client {
void doit(API api) {
api.doRun(runnable(() { snippetOfCode(); }));
}
}
Il secondo esempio è sicuramente piu' compatto ma a mio gusto molto meno leggibile del solito. Già le classi locali anonime richiedono abitudine e sintatticamente non è che siano poi tutto questo zucchero. Quì lo si considera un miglioramento a quella sintassi. Io personalmente lo considero un degrado ulteriore. Inoltre, poichè fra i nomi della proposta c'è scritto "James Gosling" allora possiamo tranquillamente considerare questa sintassi come definitiva e possiamo scartare tutte le altre proposte (tra cui la stessa di Forax) :asd:
Comunque non è tanto la sintassi in se, bisognerà vedere come ci ristruttureranno le API. Speriamo non ci facciano piangere. Tanto ormai che ad ogni versione di Java si debba reimparare da capo concetti noti ormai ci sono abituato... Una volta si imparava un linguaggio e poi si programmava, oggi si programma mentre si impara un linguaggio... :asd:
Dovresti provare l'ultima versione di Eclipse: l'ho vista girare su un PC con XP HE con soli 512MB ed era MOLTO, ma molto più reattivo di quella che avevo usato ai tempi dello sviluppo di Diamonds. A me e al mio collega sembra un'applicazione win32, poi siamo andati a vedere e c'erano i pacchetti Java... :p
Confermo che l'ultima versione di Eclipse è molto più stabile..mi ricordo che non mi teneva più di un paio d'ore e poi crashava...:D
E pur vero che molto spesso la colpa è dei plugin utilizzati..alcuni sono dei veri macigni (tipo l'Hibernate Console).
Anche quando sembra impallarsi un pò, non crasha, ma si riprende dopo qualche secondo!!
Vado abbastanza OT, ma ne approfitto per chiedervi se voi cambiate a manina i file di configurazione di eclipse per la gestione della RAM usata (minima e massima)
L'unica cosa scomoda che ho notato sulla versione 3.3 è che hanno tolto la possibilità di commentare più righe di codice nei file xml con la classica combinazione CTRL+SHIFT+/
E' da un pezzo che Java non è più il linguaggio del buon vecchio giovanni papero. Se siamo fortunati, forse non vedremo le chiusure nella versione 7.
Per esempio, Neal Gafter fa l'esempio di come una classe locale anonima venga sostituita da una chiusura:
E' difficile partire da un linguaggio "semplice", aggiungere funzionalita' ed ottenere la stessa eleganza che si otterrebbe pensandoci prima. Si aggiunge ogni volta poca funzionalita' e molta complessita'. Ancor piu' vero per Java che era nato volutamente semplice.
Se non altro consolati, se va come sembra con Java 8 o 9 potranno finalmente snellire il linguaggio ed eliminare "tutta quella roba OOP", bastera' il resto :D
^TiGeRShArK^
27-08-2007, 00:01
Confermo che l'ultima versione di Eclipse è molto più stabile..mi ricordo che non mi teneva più di un paio d'ore e poi crashava...:D
E pur vero che molto spesso la colpa è dei plugin utilizzati..alcuni sono dei veri macigni (tipo l'Hibernate Console).
Anche quando sembra impallarsi un pò, non crasha, ma si riprende dopo qualche secondo!!
Vado abbastanza OT, ma ne approfitto per chiedervi se voi cambiate a manina i file di configurazione di eclipse per la gestione della RAM usata (minima e massima)
L'unica cosa scomoda che ho notato sulla versione 3.3 è che hanno tolto la possibilità di commentare più righe di codice nei file xml con la classica combinazione CTRL+SHIFT+/
io ho sempre usato CTRL+SHIFT+C :fagiano:
per quanto riguarda la memoria a lavoro solitamente lo faccio partire con l'opzione -DXmx 768m.
Da riga di comando se non sbaglio si deve fare in questo modo:
eclipse -vmargs -DXmx 768m
ma non sono sicurissimo al 100% :p
domani se mi ricordo controllo :D
Java 1.1: (cioè l'originale ma con in più le classi interne). Ragazzi che linguaggio che era. Nu babbà.
Java 1.1: (cioè l'originale ma con in più le classi interne). Ragazzi che linguaggio che era. Nu babbà.
Bhè, nu babbà neanche tanto. Per fare cose elementari si dovevano fare certe grezzate...
E' da un pezzo che Java non è più il linguaggio del buon vecchio giovanni papero. Se siamo fortunati, forse non vedremo le chiusure nella versione 7.
La vacca vittoria la conoscevo ma Giovanni Papero chi è? :asd:
Difatti Remi Forax ha definito il D come un'incredibile raccolta di tutte le principali spazzature sintattiche create nell'ultimo decennio dai principali linguaggi di programmazione in un unico conveniente package :D
C'è proprio tutto e non so fino a che punto possa essere un vantaggio.
Sono pronto a scommettere che da qui a un anno avrà anche superpackages e closures.
una piuma rispetto a C++ e C# :O
poi qui urgono argomentazioni :D
James + Gosling.
Giovanni + Papero.
Ebbene sì, sono il figlio illegittimo di Walter Chiari :D.
James + Gosling.
Giovanni + Papero.
Ebbene sì, sono il figlio illegittimo di Walter Chiari :D.
Oh mamma :rotfl:
Non avevo minimamente associato la traduzione letterale..
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.