Naar aanleiding van dit artikel : http://www.webwereld.nl/nieuws/8404.phtml vraag ik me nou echt af waarom Java zo fantastisch is. Ik vind het persoonlijk een ontzettende trage bedoeling.
Verwijderd
dit hoor ik vaak ja "uitwisselbaarheid met meerdere platformen", als voordeel.
Zouden gameontwikkelaars ook overgaan op Java?
Half-Life is bijvoorbeeld C++
(Ik krijg dit jaar Java
)
Zouden gameontwikkelaars ook overgaan op Java?
Half-Life is bijvoorbeeld C++
(Ik krijg dit jaar Java
)
/u/1830/acm.png?f=community)
Trage bedoening misschien, maar het is niet traag bedoelt
Overigens vind ik het reuze meevallen, je moet alleen wel weten waar je mee bezig bent. En zeker niet zo "stom" zijn om voor "highperformance" of "realtime" zaken java te gebruiken.
En heb je java ooit met jdk1.3.1 gebruikt? Of alleen af en toe es met een of andere 1.1.x (traaaaag).
Het start inderdaad wat langzamer op en er zijn inderdaad puntjes waar C sneller is, maar er zijn ook programma's waar dat eigenlijk niks uitmaakt.
Er is regelmatig gezegd: Een goed geschreven java programma is ongeveer even snel als een slecht (en met jdk1.4 geldt zelfs "als een middelmatig") geschreven C programma.
Ik heb (gelukkig) nooit echt met C++ gewerkt maar de OO werking van/in Java bevalt me erg goed (zoals ik gisteren tegen Chem zei, omdat ik met Java OO heb leren gebruiken gebruik ik de php OO'ing niet omdat dat veel te veel beperkingen en ranzigheidjes heeft)
/u/1401/haroid_icon_60x60.png?f=community){kind=icon}
Java is met name mooi in de zin van OO ontwikkeling.
C++ blijft natuurlijk altijd sneller dan Java, maar Java is gewoon meer bedoeld voor programmeren op hoger niveau met NIET real-time performance eisen. Ideaal voor GUIs
C++ is meer geschikt voor performance applicaties met evt real-time eisen...
C++ blijft natuurlijk altijd sneller dan Java, maar Java is gewoon meer bedoeld voor programmeren op hoger niveau met NIET real-time performance eisen. Ideaal voor GUIs
C++ is meer geschikt voor performance applicaties met evt real-time eisen...
Ryzen9 5900X; 16GB DDR4-3200 ; RTX-4080S ; 7TB SSD
Als iedereen nou vanaf het begin ANSI C en OpenGL had gebruikt zou heel dat java niet nodig geweest zijn
Enige nadeel wat dan overblijft is dat je het dan op meerdere platformen moet compilen.Zie mijn post hiervoor, voor high performance dingen moet je in principe geen java gebruiken, alhoewel het met de JDK1.4 behoorlijk mee gaat vallen en Java3D ook niet langzaam schijnt te zijn ('t heeft wel wat moeite met Matrices van 768MBZouden gameontwikkelaars ook overgaan op Java?
Half-Life is bijvoorbeeld C++
(Ik krijg dit jaar Java
maar dat zal niet echt aan Java3D liggen ).Je gebruikt java inderdaad onder andere voor de platform onafhankelijkheid. Een op linux gecompileerd programma werkt gewoon op Linux/Sun/Windows/etc
Verwijderd
persoonlijk heb ik een giga hekel aan java, waarom? geen id. code-beeld bevalt me niet. erg oppervlakkig, ik weet, maar dat is toch waar ik t meeste naar kijk.
verder is java op de mac nog niet vooruit te branden(denk aan limewire) dat ding zet je halve machine in een halt, en crasht vervolgens...
verder is java op de mac nog niet vooruit te branden(denk aan limewire) dat ding zet je halve machine in een halt, en crasht vervolgens...
Ik denk niet dat limewire het allerbeste voorbeeld is
Maar inderdaad NIET alle app's zijn snel en al helemaal niet op non-windows/non-linux/non-solaris platformen.
En wat bevalt je niet aan het code-beeld??
En wat bevalt je dan juist WEL aan het code beeld van de talen die je wel prettig vind? Want bij mijn weten kan je java er net zo ranzig of fijn uit laten zien als jij wilt, aangezien het syntactisch vrijwel gelijk aan c++ is.
Behalve dat je niet van die lelijke ->'s in je code hebt
Verwijderd
Standaard vind ik java apps met gui al niet vooruit te branden. Als je het dan nog eens over een remote X-display draait dan begin je pas echt te huilenOp donderdag 30 augustus 2001 09:52 schreef GarBaGe het volgende:
.. Ideaal voor GUIs
.Qua GUI's blijf ik eigenlijk een enorme fan van TCL/TK (waarom zouden zoveel user interface libs features van TCL/TK jatten...). (maar dit terzijde)
Ander ding aan java, het is strikt object georienteerd, je kunt niet ff iets the oldfashioned imperatieve way doen. Wat je in C++ wel kan doen. Ergo je kunt niet te right tool in the right place approach toepassen.
Iets wat ik verder mis is templates. (Alhoewel die geloof ik in de nieuwe java versie schijnen te komen of een of ander soortgelijk mechanisme). Een gevolg van het ontbreken van templates is dat zodra je wat container dingen als vector gebruikt de typecasts niet van lucht zijn. (staat me uit een ver verleden iets bij dat java *het* ding zou zijn dat dat zou gaan oplossen
)C++ heeft diverse typecasts die van enigszins (of misschien zelfs niet vies) tot totaal vies gaan. Hierdoor kan de compiler ook weer wat meer vormen van fout gebruik zien.
Voordeel van java is wel dat je je memory management niet zelf hoeft te doen. Dit bespaart je een hele klasse subtiele fouten die je in C++ (zeker als beginner) kan maken. (Alhoewel dat in sommige gevallen ook weer een nadeel van java is
) In C++ kun je custom memory management aan bepaalde klassen hangen om performance e.d. op te schroeven (of zelfs te garbage collecten)
:strip_exif()/u/18993/logo.gif?f=community){kind=logo}
Gui's is en zal nog wel even het zwakke punt van java blijvenOp donderdag 30 augustus 2001 10:20 schreef izniegoed het volgende:
[..]
Standaard vind ik java apps met gui al niet vooruit te branden. Als je het dan nog eens over een remote X-display draait dan begin je pas echt te huilen
Qua GUI's blijf ik eigenlijk een enorme fan van TCL/TK (waarom zouden zoveel user interface libs features van TCL/TK jatten...). (maar dit terzijde)
Right tool right place gaat nog steeds: voor gui's pak je delphi voor de rest pak je Java
(kort door de bocht maar je begrijpt mijn punt)mbravenboer zal je wel de geparametizeerde typen uitleggen die nu in Beta zijn. Waarbij al het typecasten opgelost is...Iets wat ik verder mis is templates. (Alhoewel die geloof ik in de nieuwe java versie schijnen te komen of een of ander soortgelijk mechanisme). Een gevolg van het ontbreken van templates is dat zodra je wat container dingen als vector gebruikt de typecasts niet van lucht zijn. (staat me uit een ver verleden iets bij dat java *het* ding zou zijn dat dat zou gaan oplossen
Het ligt er over het algemeen aan wat je gewend bent.. En wat ik nog steeds het grootste pluspunten vind: de netheid van de taal, en het idee dat je 1 taal leert en overal toe kan passen..C++ heeft diverse typecasts die van enigszins (of misschien zelfs niet vies) tot totaal vies gaan. Hierdoor kan de compiler ook weer wat meer vormen van fout gebruik zien.
Voordeel van java is wel dat je je memory management niet zelf hoeft te doen. Dit bespaart je een hele klasse subtiele fouten die je in C++ (zeker als beginner) kan maken. (Alhoewel dat in sommige gevallen ook weer een nadeel van java is
Over de gameontwikkelaars: ik zit toevallig in het zelfde gebouw als de mensen die de yahoo games gebouwd hebben, en dat is allemaal Java
Verwijderd
ik doe nu voornamelijk C(++) maar dat zien er toch anders uit... en die -> zijn juist mooi!Op donderdag 30 augustus 2001 10:03 schreef ACM het volgende:
[..]
Ik denk niet dat limewire het allerbeste voorbeeld is
Maar inderdaad NIET alle app's zijn snel en al helemaal niet op non-windows/non-linux/non-solaris platformen.
En wat bevalt je niet aan het code-beeld??
En wat bevalt je dan juist WEL aan het code beeld van de talen die je wel prettig vind? Want bij mijn weten kan je java er net zo ranzig of fijn uit laten zien als jij wilt, aangezien het syntactisch vrijwel gelijk aan c++ is.
Behalve dat je niet van die lelijke ->'s in je code hebt
hmmzz. t is alweer lang geleden dat ik met java bezig ben geweest (in 98 ofzow ? pff maybe wel eerder) en toen was ik er niet echt ondersteboven van, en was t baggertraag...hmmzz i'll give it another try...... (some day)
Doe maarOp donderdag 30 augustus 2001 10:57 schreef Reflex het volgende:
[..]
ik doe nu voornamelijk C(++) maar dat zien er toch anders uit... en die -> zijn juist mooi!
hmmzz i'll give it another try...... (some day)
ik ben er dag in dag uit mee bezig en ik wil niets anders meer jdk 1.4 boekt dadelijk een grote snelheids winst.. C++ zal meestal sneller zijn. maar het is meestal niet de vraag of het snel is maar of het snel genoeg is...
* wasigh kent een veelgebruikt (script)taal die langzamer is dan java
/u/2046/pooh2.png?f=community)
Nee, Java is niet fantastisch. Java is op dit moment echter wel fantastisch vergeleken met de andere programmeeer frameworks/platformen die beschikbaar zijn. Ongetwijfeld zal er over 10 jaar een nog betere omgeving zijn dan het Java Platform.
Als ik op mijn fiets naar Oostenrijk ga fietsen vind ik dat ook een ontzettend trage bedoeling. Het punt is echter dat je dat ook niet moet doen (tenzij je dat fietsen voor je lol doet). Het is al zo vaak gezegd en ik heb dus weinig zin om er lang over te gaan zitten kletsen, maar elk platform heeft zo zijn beperkingen. Die beperkingen leveren nadelen op voor bepaalde typen van applicaties, maar leveren veel voordeel op voor andere typen applicaties.
Java heeft veel voordelen:
* Dynamic class loading
* Platform onafhankelijkheid
* Veiligheid
* Type-safety
* Reflectie
* Standaard bibliotheken
* Goede OO capaciteiten
* Garbage collection
Die allemaal direct worden mogelijk gemaakt door de architectuur van Java: bytecode die in een VM wordt uitgevoerd. Volledig native executie is in de toekomst kansloos (voor veel typen applicaties). Zaken als reflectie en dynamische toevoeging van code zijn elementen die je tegenwoordig niet meer kan missen.
Het voordeel van de interpretatie van Java in een VM is dat er at run-time optimalisaties kunnen worden toegepast. Deze optimalisaties zijn bij compilatie naar native code niet mogelijk. Er komt een tijd dat de technieken voor run-time optimalisatie zo ver zijn ontwikkeld dat de bepaalde typen applicaties waarover we het hadden sneller kunnen zijn dan vergelijkbare applicaties in C++ die naar native code zijn gecompileerd.
Verder nog even over de performance. Java 1.4 introduceert DirectBuffers. Met behulp van deze buffers kan er met astronomische snelheden met grote data-sets worden gewerkt. Dit belooft erg veel goeds voor 3D applicaties en games. Er is al een ondertussen beruchte demo geweest van een visualisatie van de Grand Canyon. Deze bestond uit een gigantische data-sets (wat niet te vergelijken is met een data-set in een game als half-life). Het blijk dat het Java Platform met behulp van DirectBuffers hier uitstekend mee om kon gaan.
Dan gebruik je vast nog niet de high-performance Java 2 VM in Mac OS X
. Op oude macs draait alleen een 1.1.x VM. Het is algemeen bekend dat die stuff achterhaald is. Mac OS X heeft op dit moment misschien wel de beste VM die er is.Dat klopt. In Java 1.5 zullen Generics opgenomen worden, ook wel geparameterizeerde typen genoemd. Je kan nu al de early-access compiler gebruiken (wat ik dus doe).
Nu dus niet meer
.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
ik gebruik geen OS X, nog, omdat t nog lang niet af is. ik weet dat de java support van OS X om te kwijlen zou moeten zijn. momenteel OS 9.2.1 gebruiken, geen id eigenlijk wel VM hierin zit, niet nagekeken.
ps. limewire onder OS X nog langzamer dan onder OS 9
maarja.. dat ook slecht geschreven
Ow? Welke dan?Op donderdag 30 augustus 2001 11:02 schreef wasigh het volgende:
* wasigh kent een veelgebruikt (script)taal die langzamer is dan java
Als je php bedoelt, gaan we wel een keertje jouw jsp kunsten tegen mijn php kunsten benchmarken.
Is dit ook te gebruiken als je veel en snelle array toegang wilt hebben op grote arrays, on commandline (eigenlijk JNI included
) tools?Waar kan ik die demo bekijken???
Interessant plan. Laten we dan wel Servlets nemenACM: Ow? Welke dan?
Als je php bedoelt, gaan we wel een keertje jouw jsp kunsten tegen mijn php kunsten benchmarken.
.Voor zover ik het begrepen heb wel ja. Het is vooral bedoeld om het gebruik van JNI (wat een performance probleem is en bovendien niet prettig werkt) te vermijden en te versnellen.Is dit ook te gebruiken als je veel en snelle array toegang wilt hebben op grote arrays, on commandline (eigenlijk JNI included
Ik zal ff link zoeken.Waar kan ik die demo bekijken???
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
/u/16515/crop618754fce4d81_cropped.png?f=community)
Verwijderd
Hangt ervan af wat je onder GAME ontwikkelen verstaat: de engine (is geen game) of de spellogica zelf (is wel game, geen engine). Unreal/Unreal Tournament en op de UT engine gebaseerde games, zijn bv geschreven in een taal, unreal script, wat sterke gelijkenis vertoont met Java. De engine zelf is geschreven in C++. Voor gamelogica leent Java zich wel, maar wat veelal 'java' genoemd wordt is de taal + platform. En bij games zoals Unreal is de engine het platform.
Nou dat is een misverstand
Halflife is als engine gebaseerd op de Quake en Quake2 engine en die zijn zo C als het maar kan. Ze zullen tegenwoordig wellicht wat meer in C++ doen, maar veel is echt gewoon platte C code. Zie bv ook hun modelrender routine.Nee, je krijgt 'hoe moet ik programmeren' onderwezen, aan de hand van Java. Dat is iets totaal anders. De TAAL die gebruikt wordt is niet belangrijk. WAT dmv de taal wordt onderwezen: nl. hoe moet ik programmeren, DAT is belangrijk. Staar je dus niet blind op de taal, maar op de theorie van het programmeren.(Ik krijg dit jaar Java
Verwijderd
'voordeel' is altijd tov iets anders. Als alle andere talen dezelfde voordelen hebben, is het geen voordeel meer. En waar heb je het over, over de taal of over het platform? Weinig punten hierboven zijn op de taal van toepassing.
Onzin. COM en CORBA tonen aan dat het prima kan met native compiled code. Als je goed kijkt naar de JVM van nu en die van in de toekomst, zie je dat er steeds meer naar binary objects toegegroeid wordt. Wat inhoudt dat niet zozeer de VM belangrijk is, maar de binary objects. Waar die ook in geschreven zijn.
Zie EPIC instructieset.
At runtime optimalisaties zijn in theorie beter, echter kosten ook tijd om uit te voeren. Hoe beter je wilt optimaliseren, hoe meer tijd het kost. En at runtime heb je die tijd niet. Kleine tight loops zijn in een VM wel sneller, maar de rest niet, wat resulteert in overall tragere code. En je mag hier tegenin gaan wat je wilt, ik voer deze discussie al jaren en niemand heeft nog kunnen aantonen, zowel met theorie als praktijkvoorbeelden, dat een groot programma in C++ trager is dan in Java.
En dan nu naar het meest hilarische stukje:
Weet je wel IETS van 3D programming af en bv scenegraphs? Als ik jouw marketingpoop hierboven zo lees dan krijg ik het gevoel dat ze de als stroop functionerende array-logic in Java hebben vervangen door native datablocks. Maar wat is daar nieuw aan? En wat maakt Java met deze unieke vondst (
) dan ineens erg snel, sneller dan bv C++ in het gebied van rendering van 3D scenes mbv een scenegraph met erg veel planes/primitives?Met een goede scenegraph kun je alles op lightspeed renderen. En als je weet hoe een scenegraph werkt dan is het fijn voor java dat ze nu een beetje snelle dataset browse code kunnen maken, maar bv voor C++ is die er al jaren. En DirectBuffers of niet, het blijft een door een VM gestuurde logical unit: de VM slokt altijd overhead op die je bij C++ niet hebt. Als DirectBuffers dan ZO snel is, sneller dan een C++ oplossing, waarom implementeer je dan die code ook niet in C++? Ben je weer sneller dan Java met zn VM, want die overhead moet je meenemen aan de java kant. Ergo: java is altijd trager. Het kan ALLEEN sneller zijn indien:
executietijd realtimeoptimizer + executietijd realtime optimized code < executietijd C++ written code
Nu mag jij als advocate vol blijven houden dat de realtime optimizer heel erg snel is, maar dat blijven holle woorden. Iedere compile van welke sourcecode dan ook bewijst al dat optimizing tijd kost. En die tijd heb je niet.
/u/2305/crop653618cca8542_cropped.png?f=community)
Ik vind Java qua platform echt prachtig. Het heeft zo een rijke bibliotheek voor alles en nog wat, leuke features (zie Mbravenboers posting), write-once-run-everwhere, etc.
Ik heb ergens in '96/'97 (wat was het..?) toen Java Applets erg in waren (en Netscape 2.0 nog vloog op mijn 486) wat Applets geprogrammeerd... en dat was regelrecht een ramp, die dingen waren zo brak als maar kon.. gelukkig is de taal veel volwassener geworden en begint de wereld door te hebben dat Java != Applet.
Ook zo mooi vind ik JSP en Servlets, alleen jammer dat er weinig ISP's zijn die dat ondersteunen
Maar wat mij echt dwarszit van de taal java is dat je af en toe van die absurde syntaxconstructies krijgt. Ik geef een voorbeeld zomaar uit het wilde weg gepakt uit "Java Examples In a Nutshell" (overigens een erg leuk boek voor programmeurs die snel Java op willen pikken, met dank aan Wasigh)
in tegenstelling tot..
Omdat alles persé OOP moet zijn, zijn er bepaalde zaken waar Java dan weer minder goed is. Zoals iznogoed al opmerkte:
izniegoed ...Ergo je kunt niet te right tool in the right place approach toepassen...
Java is veelal geschikt voor grote projecten waar je in teams > 3 man oid werkt. Wat is anders het punt van OOP als je de implementaties voorjezelf aan het hiden bent
Daarnaast vind ik het ook nog erg jammer dat Java geen gebruik maakt van Native compilen (dus geen 3d party dingen.. gewoon ondersteund door Sun zelf..), of dat Java kan linken met native libs zoals MFC/GTK..
Nu heb je met Java hetzelfde probleem als met Mozilla (hopen dat Arien dit niet leest): een heel goed produkt, helaas is de interface gewoon zo tergend langzaam.
Persoonlijke opmerking: ik vind Swing toch zo afschuwelijk lelijk he (dont flame me )
[on topic]
Ik vind dat artikel waar DimeBag naar linkt eigenlijk een beetje wazig... ze ondervragen 400 programmeurs en beweren dat Java C++ verslaat.. en ook nog even eraan toevoegen dat C# geen kans maakt.. hmm
Maar dat terzijde... mijn persoonlijke mening is dat dit in de praktijk helemaal niet zo waar zal hoeven te zijn. Mischien zal er in bedrijven die intern software ontwikkelen wel een grote overgang plaatsvinden (platformonafhankelijkheid is niet niks...) maar voor het over-over-grote deel software (dat uiteindelijk bij de thuisgebruiker beland!) - of het nou linux, windows, mac of whatever is - zal er nog altijd gebruik worden gemaakt van C/C++
En nu ga ik ontbijten
Ik heb ergens in '96/'97 (wat was het..?) toen Java Applets erg in waren (en Netscape 2.0 nog vloog op mijn 486
) wat Applets geprogrammeerd... en dat was regelrecht een ramp, die dingen waren zo brak als maar kon.. gelukkig is de taal veel volwassener geworden en begint de wereld door te hebben dat Java != Applet. Ook zo mooi vind ik JSP en Servlets, alleen jammer dat er weinig ISP's zijn die dat ondersteunen
Maar wat mij echt dwarszit van de taal java is dat je af en toe van die absurde syntaxconstructies krijgt. Ik geef een voorbeeld zomaar uit het wilde weg gepakt uit "Java Examples In a Nutshell" (overigens een erg leuk boek voor programmeurs die snel Java op willen pikken, met dank aan Wasigh
)code:
1
| BufferedReader in = new BufferedReader (new InputStreamReader (System.in)); |
in tegenstelling tot..
code:
1
2
| FILE* in; // c ifstream in; // c++ |
Omdat alles persé OOP moet zijn, zijn er bepaalde zaken waar Java dan weer minder goed is. Zoals iznogoed al opmerkte:
izniegoed ...Ergo je kunt niet te right tool in the right place approach toepassen...
Java is veelal geschikt voor grote projecten waar je in teams > 3 man oid werkt. Wat is anders het punt van OOP als je de implementaties voorjezelf aan het hiden bent
Daarnaast vind ik het ook nog erg jammer dat Java geen gebruik maakt van Native compilen (dus geen 3d party dingen.. gewoon ondersteund door Sun zelf..), of dat Java kan linken met native libs zoals MFC/GTK..
Nu heb je met Java hetzelfde probleem als met Mozilla (hopen dat Arien dit niet leest
): een heel goed produkt, helaas is de interface gewoon zo tergend langzaam.Persoonlijke opmerking: ik vind Swing toch zo afschuwelijk lelijk he
(dont flame me )[on topic]
Ik vind dat artikel waar DimeBag naar linkt eigenlijk een beetje wazig... ze ondervragen 400 programmeurs en beweren dat Java C++ verslaat.. en ook nog even eraan toevoegen dat C# geen kans maakt.. hmm
Maar dat terzijde... mijn persoonlijke mening is dat dit in de praktijk helemaal niet zo waar zal hoeven te zijn. Mischien zal er in bedrijven die intern software ontwikkelen wel een grote overgang plaatsvinden (platformonafhankelijkheid is niet niks...) maar voor het over-over-grote deel software (dat uiteindelijk bij de thuisgebruiker beland!) - of het nou linux, windows, mac of whatever is - zal er nog altijd gebruik worden gemaakt van C/C++
En nu ga ik ontbijten
Als alle talen het hebben is het inderdaad geen voordeel meer. Maar niet alle talen hebben het dus...
Java is een combinatie van taal en platform.. Je kunt java (nog niet) los zien van de jvm, etc..
Dat je deze discussie al jaren voert is geen argument. Dat zegt meer over het feit dat je mensen blijkbaar niet kunt overtuigen
Snelheid is relatief. Het gaat (vaak) niet om of het in 10 of in 5 ms kan, 20 ms is vaak al snel zat. Wanneer mensen niet voor java kiezen omdat het "te traag" is hebben ze vaak een bord voor hun kop..Omdat iemand een andere mening heeft weet ie blijkbaar niets af van een bepaald gebied?
stroop fucntionerende? benchmarks?
Waar is gezegd dat java sneller is als c++ op het gebied van rendering?Maar wat is daar nieuw aan? En wat maakt Java met deze unieke vondst
[...]
(
Het is heel erg snel in vergelijking met(wat je zelf in het begin ook aangaf, in die zin kunnen het dus geen holle woorden zijn. Je probeert met een overdaad een technische termen een stelling aan te vallen die helemaal niet gemaakt is. Er is niet gezegd dat java sneller is als c++, Maar de mening van veel mensen dat java veel te traag is zal na de release van 1.4 geen feitelijke onderbouwing meer hebben. Want er is bewezen dat door nieuwe technieken er veel snelheid winst geboekt word(zie 3d Demo).
Het feit is: dat er steeds meer mensen de schoonheid van Java inzien als taal en dat jij dat (nog) niet ziet of misschien nooit zal zien is erg jammer maar daar kan ik toch niets aan veranderen...
Verwijderd
Voor GUIs kun je ook heel goed C++ gebruiken.Op donderdag 30 augustus 2001 09:52 schreef GarBaGe het volgende:
Java is met name mooi in de zin van OO ontwikkeling.
C++ blijft natuurlijk altijd sneller dan Java, maar Java is gewoon meer bedoeld voor programmeren op hoger niveau met NIET real-time performance eisen. Ideaal voor GUIs
C++ is meer geschikt voor performance applicaties met evt real-time eisen...
Probeer C++ builder maar.
:strip_exif()/u/22119/ch.gif?f=community)
Amen.ACM:
Als iedereen nou vanaf het begin ANSI C en OpenGL had gebruikt zou heel dat java niet nodig geweest zijn
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Hoe goed draait die GUI dan op Linux / Solaris / Mac etc?
Bij Java (met swing, niet met awt) gaat dat in principe zonder enige aanpassingen aan de source werken.
offtopic:
Wasigh: ik moest van mijn collega, die zich hier naast me zit op te vreten van ergernis (), zeggen dat het "sneller dan" is. 
Wasigh: ik moest van mijn collega, die zich hier naast me zit op te vreten van ergernis (
), zeggen dat het "sneller dan" is. Verwijderd
Hmmm geen probleem in C/C++ als je weet wat je doet.
Maar geen versie onafhankelijkheid (dat heeft vrijwel niemand). Op het moment moet je in java net zo hard voor een minimale subset proggen waar je stuff op moet lopen. Heck.. ik mis gewoon de preprocessor voor een paar #ifdef JAVA_1_3 constructies
Bijna net zo erg als platform afhankelijkheid. Verder duiken er ook steeds meer java implementaties op en niemand maakt mij wijs dat die allemaal 100% hetzelfde doen (en dan heb ik het nog niet eens over de support libraries) Zolang der geen formele basis ligt aan een taal zul je dat ook nooit krijgen.Mijn gcc/g++ is ook erg veilig
(sorry kon het niet laten) Gein terzijde, veiligheid wordt in een applicatie veelal bepaald door het gebruik van hersens van de gup achter het toetsenbord. (programmeur dan wel user)Pas in 1.4 dus ?
Dat doet java inderdaad wel redelijk.. Maar ik hou mijn hart vast tussen diverse implementaties.
Ik herhaal mezelf maarja.. Alleen maar OO capaciteiten.
Kun je overal in hangen.
Mwoch niet alleen door de architectuur.
Hangt van je app af. Kansloos... hmmm korreltje zout. Je begint een beetje als een reclame folder te klinken (sorry dat ik het zeg
)Eerst zien dan geloven. Optimalisatie is iha erg duur, straks is je app meer zichzelf aan het optimizen dan bezig met wat ie moet doen.. Ik vermoed dat de optimalisaties na een run ook weer pleitten zijn?
Het zal mijn inziens erg van de applicatie afhangen hoeveel winst er is (maar dat zeg je ook al). (ben niet zo bekend met de materie) Verder als runtime optimalisatie het goed doet zal een chipbakker erg snel gaan kijken of het ook in zijn chipje past (voorzover het al niet gedaan wordt met branch prediction en stuff) Dus dit is best wel een kww (kiek'n wat word) opmerking.
Java is, bij mijn weten, backwards compatible. Forwards compatible is er niet, maar dat is ook veel lastiger te maken/ontwerpen aangezien je dan niet zoveel dingen kan veranderen/toevoegen.Op donderdag 30 augustus 2001 12:56 schreef izniegoed het volgende:
Maar geen versie onafhankelijkheid (dat heeft vrijwel niemand). Op het moment moet je in java net zo hard voor een minimale subset proggen waar je stuff op moet lopen. Heck.. ik mis gewoon de preprocessor voor een paar #ifdef JAVA_1_3 constructies
Een voor java1.1 geschreven tool compiled over het algemeen nog wel (aardig) in java 1.3, volgens mij.
compiled goed krijgt alleen een aantal deprecation warnings
offtopic:
* wasigh 's vriendin wordt lerares nl's dus ik hoor het al genoeg
* wasigh 's vriendin wordt lerares nl's dus ik hoor het al genoeg
Je begint een beetje als een anti-reclame folder te klinken.Op donderdag 30 augustus 2001 12:56 schreef izniegoed het volgende:
Verder duiken er ook steeds meer java implementaties op en niemand maakt mij wijs dat die allemaal 100% hetzelfde doen
[..]
Dat doet java inderdaad wel redelijk.. Maar ik hou mijn hart vast tussen diverse implementaties.
Elke implementatatie moet voordat ie java Virtual Machine mag heten door een strenge controle van sun. Dus reken maar dat alles het voor 99,999 % gelijk doet.. (het maakt dus echt niets uit, op welke jvm je je classes draait)
Ik krijg steeds meer het idee dat de spreekwoordelijk klepel maar niet kan vinden. Je hebt hier en daar iets gehoord en daar baseer je je mening op(lijkt het)
Misschien moet je je iets meer in java verdiepen?
Het zal goed zo zijn dat voor de programma's die jij maakt java geen optie is. Maar misschien moet je dan iets verder kijken als je neus lang is
Verwijderd
Deze discussie wordt vrij vervelend.
Er wordt continu door een paar advocates (zie usericons) de fout gemaakt door 'java' als TAAL en 'java' als PLATFORM als synoniem van elkaar te gebruiken. Java als 'taal' is vrij compleet en een leuke OO taal, net zoals er ook andere leuke OO talen zijn.
Java als 'platform' is iets anders. Wat ze in het platform stoppen voor 'features' zijn in de hedendaagse platforms als Win32 al lang terug te vinden.
Om nog even terug te komen op die vermeende 3D demo: als je niets snapt van 3D rendering, hou dat dan buiten je betoog. In VB kan ik ook met D3D8 3D scenes renderen en met een goede scenegraph als COM object lukt dat als een speer. Zegt ook niets over VB overigens.
Voor de mensen die van leuke applets houden, hier 2 links naar 2 applets die ik jaren geleden geschreven heb:
http://www.xs4all.nl/~perseus/alphablend
http://www.xs4all.nl/~perseus/bgdraw/bgdraw.html
http://www.xs4all.nl/~perseus/bgdraw/bgdraw.java (sourcecode)
Aan de advocates: discussieren met mensen die per se willen dat je het product gebruikt wat ze willen uitdragen is zinloos en vervelend. Open je ogen: het is maar software, niet een manier van leven. Tuurlijk is het leuk, en word je wellicht helemaal lyrisch en warm van binnen als je alleen al denkt aan de nieuwe Java API, maar dat KAN en MAG nooit een argument zijn in een onbevooroordeelde discussie over je favoriete product: andere mensen hebben andere criteria wellicht en dan valt jouw product volledig door de mand.
Hieronder een copy/paste van een nl.comp.programmeren posting van mij van 2 jaar terug. Deze is gepost in een thread over de snelheid van Java vs C++. Happy reading
original en thread
[...]
Ik ga hieronder een poging doen de hypothese
(A)
Een algorithme A in Java geimplementeerd, draaiend op een JVM kan
sneller zijn (kortere uitvoeringstijd hebben) dan hetzelfde algorithme A
geimplementeerd in C++ en gecompileerd naar de CPU waarop de JVM draait'
proberen te verwerpen door de hypothese
(
Een algorithme A in Java geimplementeerd, draaiend op een JVM kan
NOOIT sneller zijn (kortere uitvoeringstijd hebben) dan hetzelfde algorithme A
geimplementeerd in C++ en gecompileerd naar de CPU waarop de JVM draait'
te bewijzen.
Het is een theoretisch bewijs, daar door de aandragers van de hypothese (A)
nooit een theoretisch bewijs is geleverd voor hun hypothese, plus ik dat wel vaak
heb gevraagd.
'Een invitatie werd uitgereikt. Het stond er met rood omrande letters: 'toon maar
aan dat het niet zo is'. "Dit soort invitaties staan zo mooi op de bodem van de
prullenbak", dacht hij smalend. Maar toch broedde het. Hij kon ook gewoon ZIJN
theorie geven en afwachten wat voor zet de ander zou doen.'
Bewijs hypothese (B):
Aannames:
-Met java zoals besproken in dit artikel, behalve indien anders aangegeven, wordt
bedoeld: een taal die in gecompileerde vorm wordt uitgevoerd door een
software CPU die een onderdeel is van een Virtual Machine.
-Een computer met de bekende, van Von Neumann afgeleide architectuur: een CPU,
geheugen waarin data- en programmagegevens tezamen zijn opgeslagen, een of meerdere
bussen die CPU en het geheugen alsmede de CPU en andere apparaten verbinden, dient
als basis. De interne technologie van de CPU, dus multi-instructie prefetching of
pipelining van decoderingsprocessen, is niet belangrijk. Immers, de CPU dient als
basis voor beide te vergelijken platformen en beide kunnen hiervan gebruik maken,
wat de interne samenstelling van de CPU niet relevant maakt.
-De C++ compiler levert, net als de Java (JIT) compiler en de Virtual Machine,
ideale binaire codes op, die tezamen een stroom binaire codes vormen waar geen
verdere optimalisatie nodig is. Er is immers altijd een betere versie van of de
C++ compiler denkbaar of de JIT compiler, java compiler of Virtual Machine.
-Er wordt een algorithme gekozen wat in zowel Java als in C++ wordt geimplementeerd.
Welk algorithme dat is, is niet belangrijk, daar het resultaat altijd door dezelfde
CPU moet worden uitgevoerd, namelijk de hardware CPU.
De CPU bevat een aantal registers, waaronder de PC(program counter). Deze PC wijst
naar een geheugenadres waar de CPU de eerst volgende instructie kan vinden die moet
worden uitgevoerd. Deze instructie is binair en het resultaat van een compilatie
van een hogere orde taal. Deze hogere orde taal kan assembler zijn, een 3e generatie
taal of hoger, als uit de compilatie maar binaire code volgt die kan worden
uitgevoerd door de CPU. Assembler is in deze een hogere orde taal, daar we spreken
over binaire codes als huidig niveau.
Hoe wordt java uitgevoerd? Java draait op een virtual machine. De virtual machine is
in feite niets anders dan de representatie van een CPU incl memory, bussen en
randapparatuur, alleen dan in software. Deze virtual machine draait dan weer op
hardware, de CPU, memory, bussen en randapparatuur die we als uitgangspunt namen.
Zodoende kan platform onafhankelijk worden ontwikkeld, immers de virtuele computer is
naar buiten toe altijd gelijk.
Java wordt gecompileerd naar binaire code, net zoals dat gebeurt voor de hardware
CPU. Deze binaire code wordt door de software CPU in de virtual machine uitgevoerd.
Ook in de software CPU zit een PC.
Echter, de virtual machine loopt niet vanzelf. Aangezien deze virtual machine rust op
de hardware, en als zodanig wordt uitgevoerd als een normaal programma, net als
elk ander programma wat draait op de hardware CPU, bestaat de virtual machine uit
een stroom binaire codes die door de hardware CPU wordt geleid.
De binaire codes van de virtual machine noemen we SET1. de stroom van instructies
die tezamen de programflow vormen van het draaien van de virtual machine noemen we
StreamSET1. Deze StreamSET1 bestaat uit de instructies die moeten worden uitgevoerd
om de virtual machine uberhaupt te laten draaien, dus dat de software CPU bv de PC
ophoogt, binaire codes uit het memory haalt, decodeert en uitvoert. Indien we een
java programma draaien op de software CPU, zal deze instructies uitvoeren, welke
resulteren in binaire codes voor de hardware CPU. Deze stream van binaire codes
noemen we StreamSET2. StreamSET2 is per definitie langer dan StreamSET1, daar
StreamSET1, puur het werken van de Virtual Machine omvat en StreamSET2 ook de
werking van het javaprogramma bevat.
In StreamSET2 zit altijd een subset van binaire codes voor de hardware CPU die
puur bedoeld zijn om de software CPU te laten functioneren.
Een in C++ geschreven programma wordt gecompileerd naar binaire codes. Deze codes
zijn direct te lezen en uit te voeren door de hardware CPU. Een in C++ geschreven
programma wat is gecompileerd behoeft geen virtual machine met een software processor
die binaire codes bedoelt voor de software CPU uitvoert en voor die uitvoering
extra binaire codes toevoegt aan de stroom van binaire codes die door de hardware
CPU wordt geleid. Nu kan de hardware CPU meteen de stroom binaire codes uitvoeren
die het programma vormen. Elke binaire code die wordt uitgevoerd in de hardware
CPU is dan ook deel van het programma en is niet mogelijkerwijs deel van de
stroom binaire codes die nodig zijn om een virtuele machine met sofware CPU te
laten draaien. De stroom binaire codes die tezamen het gecompileerde C++ programma
vormen, noemen we StreamSET3.
Aangezien elk javaprogramma, hoe goed ook geimplementeerd, altijd in zijn
binaire stroom codes de binaire codes voor de Virtual Machine met zich mee torst,
is het altijd trager op dezelfde CPU dan een soortgelijk programma met dezelfde
algorithmen geimplementeerd in C++.
Om dit probleem zo klein mogelijk te maken, wordt gezocht naar een methode om de
executie van de java binaire codes door de software CPU in een zo kort mogelijke
tijd te laten plaatsvinden zodat de StreamSET2 ongeveer gelijk is aan StreamSET3.
Er zijn een aantal mogelijkheden om dit te doen:
a) Door het in java geschreven programma te compileren naar binaire codes voor de
hardware CPU ipv voor de software CPU.
b) Door het gebruik van een Just In Time Compiler (JIT-compiler)
ad a).
Dit levert voor de stelling op dat er geen verschil in snelheid mag bestaan, daar
beide talen naar dezelfde hardware CPU worden gecompileerd en dus de stroom
binaire codes voor die hardware CPU beide keren alleen zullen bestaan uit binaire
codes die behoren tot het programma, en dus niet tot een virtual machine. Echter
het neemt ook het platform onafhankelijke karakter weg van java. Deze optie valt
dan ook buiten de te bewijzen hypothese, daar het javaprogramma dan niet meer op
een virtual machine draait.
ad b).
De JIT techniek heeft tot aan vandaag geresulteerd in een verkorting van de
uitvoertijd van een javaprogramma door een virtual machine. In theorie is de
techniek gebasseerd op het feit dat de virtual machine naar buiten toe (naar het
javaprogramma toe) services moet aanbieden als een software cpu en aanverwante
zaken die in de virtual machine zijn gedefinieerd, echter de uitvoering van
het javaprogramma hoeft niet volgens de aloude methode te verlopen, ALS de stroom
binaire codes die door de hardware CPU wordt geleid maar resulteert in hetzelfde
resultaat als de uitvoering van StreamSET2.
De ultieme JIT-compiler is een compiler die een java programma bestaande uit binaire
codes voor de software CPU omzet naar binaire codes voor de hardware CPU, real time.
Immers, alleen dan is StreamSET2=StreamSET3 en is de set binaire codes voor de
hardware CPU die bedoeld zijn voor de Virtual Machine gelijk aan een lege set.
Deze ultieme JIT compiler is tegenwoordig nog niet snel genoeg, maar aangezien dat
wellicht in de toekomst kan veranderen, nemen we aan dat deze JIT-compiler 0 seconden
in beslag neemt van de uitvoertijd van het javaprogramma.
Wat we hebben is:
Javaprogramma -> compiler -> binaire codes -> ultimate JIT -> StreamSET3
C++programma -> compiler -> StreamSET3
Aangezien in StreamSET3 geen andere binaire codes zitten dan de binaire codes
waaruit het programma bestaat, kan StreamSET3 niet een superset zijn van een
tweetal of meerdere sets binaire codes zodat men een of meerdere van deze subsets
kan nemen, maar niet alle, zodat deze toch het volledige programma kunnen bevatten.
Concluderend: Java kan nooit sneller zijn dan C++.
SideNote:
Aangezien de ultieme JIT compiler tegenwoordig wel degelijk nog traag is en dus
voor andere mogelijke JIT technieken moet worden gekozen, worden DELEN van de
uit te voeren binaire codes voor de software CPU vertaalt naar binaire
codes voor de hardware CPU, en dus dat de uitvoering van de software CPU binaire
codes eigenlijk niet plaatsvind. Verder kan worden gekozen voor een andere aanpak,
door een library samen te stellen van veel gebruikte programma-constructies en
die al te vertalen naar binaire codes voor een hardware CPU, zodat de virtual
machine dmv de JIT compiler rechtstreeks de software CPU binaire codes kan uitvoeren,
zonder ook daadwerkelijk die software CPU te gebruiken. Deze techniek wordt ook
door andere op virtual machines gebasseerde talen gebruikt, zoals Visual Basic.
Men kan, in theorie, StreamSET3 benaderen, door heel veel delen te vertalen en
voor de overige delen de library van voorvertaalde delen te gebruiken.
Als de JIT-compiler die de delen vertaalt maar binaire codes aflevert die optimaal
zijn, plus dat de library optimaal moet zijn, zal het java programma bijna even
snel draaien als het C++ programma, gecompileerd naar optimale binaire codes voor
de hardware CPU. Beide zaken kunnen verschillen: de C++ compilatie hoeft niet
optimaal te zijn, en er kunnen onnodig veel binaire codes in de StreamSET3 zitten,
die de uitvoeringstijd van het C++ programma langer maken dan nodig, zelfs langer
dan het java programma wat gebruik maakt van wellicht wel een JIT compiler die
optimale code aflevert, plus een optimale library. Echter de StreamSET3 van het
C++ programma zal ZOVEEL extra, vertragende, code moeten bevatten dat de StreamSET1,
waartoe ook de instructies voor de JIT behoren, een kortere uitvoeringstijd
heeft.
Dit is ook de reden dat voorbeelden met betrekking tot dit onderwerp niet voldoende
zijn om enige concensus te bereiken.
[/...]
Er wordt continu door een paar advocates (zie usericons
) de fout gemaakt door 'java' als TAAL en 'java' als PLATFORM als synoniem van elkaar te gebruiken. Java als 'taal' is vrij compleet en een leuke OO taal, net zoals er ook andere leuke OO talen zijn. Java als 'platform' is iets anders. Wat ze in het platform stoppen voor 'features' zijn in de hedendaagse platforms als Win32 al lang terug te vinden.
Om nog even terug te komen op die vermeende 3D demo: als je niets snapt van 3D rendering, hou dat dan buiten je betoog. In VB kan ik ook met D3D8 3D scenes renderen en met een goede scenegraph als COM object lukt dat als een speer. Zegt ook niets over VB overigens.
Voor de mensen die van leuke applets houden, hier 2 links naar 2 applets die ik jaren geleden geschreven heb:
http://www.xs4all.nl/~perseus/alphablend
http://www.xs4all.nl/~perseus/bgdraw/bgdraw.html
http://www.xs4all.nl/~perseus/bgdraw/bgdraw.java (sourcecode)
Aan de advocates: discussieren met mensen die per se willen dat je het product gebruikt wat ze willen uitdragen is zinloos en vervelend. Open je ogen: het is maar software, niet een manier van leven. Tuurlijk is het leuk, en word je wellicht helemaal lyrisch en warm van binnen als je alleen al denkt aan de nieuwe Java API, maar dat KAN en MAG nooit een argument zijn in een onbevooroordeelde discussie over je favoriete product: andere mensen hebben andere criteria wellicht en dan valt jouw product volledig door de mand.
Hieronder een copy/paste van een nl.comp.programmeren posting van mij van 2 jaar terug. Deze is gepost in een thread over de snelheid van Java vs C++. Happy reading
original en thread
[...]
Ik ga hieronder een poging doen de hypothese
(A)
Een algorithme A in Java geimplementeerd, draaiend op een JVM kan
sneller zijn (kortere uitvoeringstijd hebben) dan hetzelfde algorithme A
geimplementeerd in C++ en gecompileerd naar de CPU waarop de JVM draait'
proberen te verwerpen door de hypothese
(
Een algorithme A in Java geimplementeerd, draaiend op een JVM kan
NOOIT sneller zijn (kortere uitvoeringstijd hebben) dan hetzelfde algorithme A
geimplementeerd in C++ en gecompileerd naar de CPU waarop de JVM draait'
te bewijzen.
Het is een theoretisch bewijs, daar door de aandragers van de hypothese (A)
nooit een theoretisch bewijs is geleverd voor hun hypothese, plus ik dat wel vaak
heb gevraagd.
'Een invitatie werd uitgereikt. Het stond er met rood omrande letters: 'toon maar
aan dat het niet zo is'. "Dit soort invitaties staan zo mooi op de bodem van de
prullenbak", dacht hij smalend. Maar toch broedde het. Hij kon ook gewoon ZIJN
theorie geven en afwachten wat voor zet de ander zou doen.'
Bewijs hypothese (B):
Aannames:
-Met java zoals besproken in dit artikel, behalve indien anders aangegeven, wordt
bedoeld: een taal die in gecompileerde vorm wordt uitgevoerd door een
software CPU die een onderdeel is van een Virtual Machine.
-Een computer met de bekende, van Von Neumann afgeleide architectuur: een CPU,
geheugen waarin data- en programmagegevens tezamen zijn opgeslagen, een of meerdere
bussen die CPU en het geheugen alsmede de CPU en andere apparaten verbinden, dient
als basis. De interne technologie van de CPU, dus multi-instructie prefetching of
pipelining van decoderingsprocessen, is niet belangrijk. Immers, de CPU dient als
basis voor beide te vergelijken platformen en beide kunnen hiervan gebruik maken,
wat de interne samenstelling van de CPU niet relevant maakt.
-De C++ compiler levert, net als de Java (JIT) compiler en de Virtual Machine,
ideale binaire codes op, die tezamen een stroom binaire codes vormen waar geen
verdere optimalisatie nodig is. Er is immers altijd een betere versie van of de
C++ compiler denkbaar of de JIT compiler, java compiler of Virtual Machine.
-Er wordt een algorithme gekozen wat in zowel Java als in C++ wordt geimplementeerd.
Welk algorithme dat is, is niet belangrijk, daar het resultaat altijd door dezelfde
CPU moet worden uitgevoerd, namelijk de hardware CPU.
De CPU bevat een aantal registers, waaronder de PC(program counter). Deze PC wijst
naar een geheugenadres waar de CPU de eerst volgende instructie kan vinden die moet
worden uitgevoerd. Deze instructie is binair en het resultaat van een compilatie
van een hogere orde taal. Deze hogere orde taal kan assembler zijn, een 3e generatie
taal of hoger, als uit de compilatie maar binaire code volgt die kan worden
uitgevoerd door de CPU. Assembler is in deze een hogere orde taal, daar we spreken
over binaire codes als huidig niveau.
Hoe wordt java uitgevoerd? Java draait op een virtual machine. De virtual machine is
in feite niets anders dan de representatie van een CPU incl memory, bussen en
randapparatuur, alleen dan in software. Deze virtual machine draait dan weer op
hardware, de CPU, memory, bussen en randapparatuur die we als uitgangspunt namen.
Zodoende kan platform onafhankelijk worden ontwikkeld, immers de virtuele computer is
naar buiten toe altijd gelijk.
Java wordt gecompileerd naar binaire code, net zoals dat gebeurt voor de hardware
CPU. Deze binaire code wordt door de software CPU in de virtual machine uitgevoerd.
Ook in de software CPU zit een PC.
Echter, de virtual machine loopt niet vanzelf. Aangezien deze virtual machine rust op
de hardware, en als zodanig wordt uitgevoerd als een normaal programma, net als
elk ander programma wat draait op de hardware CPU, bestaat de virtual machine uit
een stroom binaire codes die door de hardware CPU wordt geleid.
De binaire codes van de virtual machine noemen we SET1. de stroom van instructies
die tezamen de programflow vormen van het draaien van de virtual machine noemen we
StreamSET1. Deze StreamSET1 bestaat uit de instructies die moeten worden uitgevoerd
om de virtual machine uberhaupt te laten draaien, dus dat de software CPU bv de PC
ophoogt, binaire codes uit het memory haalt, decodeert en uitvoert. Indien we een
java programma draaien op de software CPU, zal deze instructies uitvoeren, welke
resulteren in binaire codes voor de hardware CPU. Deze stream van binaire codes
noemen we StreamSET2. StreamSET2 is per definitie langer dan StreamSET1, daar
StreamSET1, puur het werken van de Virtual Machine omvat en StreamSET2 ook de
werking van het javaprogramma bevat.
In StreamSET2 zit altijd een subset van binaire codes voor de hardware CPU die
puur bedoeld zijn om de software CPU te laten functioneren.
Een in C++ geschreven programma wordt gecompileerd naar binaire codes. Deze codes
zijn direct te lezen en uit te voeren door de hardware CPU. Een in C++ geschreven
programma wat is gecompileerd behoeft geen virtual machine met een software processor
die binaire codes bedoelt voor de software CPU uitvoert en voor die uitvoering
extra binaire codes toevoegt aan de stroom van binaire codes die door de hardware
CPU wordt geleid. Nu kan de hardware CPU meteen de stroom binaire codes uitvoeren
die het programma vormen. Elke binaire code die wordt uitgevoerd in de hardware
CPU is dan ook deel van het programma en is niet mogelijkerwijs deel van de
stroom binaire codes die nodig zijn om een virtuele machine met sofware CPU te
laten draaien. De stroom binaire codes die tezamen het gecompileerde C++ programma
vormen, noemen we StreamSET3.
Aangezien elk javaprogramma, hoe goed ook geimplementeerd, altijd in zijn
binaire stroom codes de binaire codes voor de Virtual Machine met zich mee torst,
is het altijd trager op dezelfde CPU dan een soortgelijk programma met dezelfde
algorithmen geimplementeerd in C++.
Om dit probleem zo klein mogelijk te maken, wordt gezocht naar een methode om de
executie van de java binaire codes door de software CPU in een zo kort mogelijke
tijd te laten plaatsvinden zodat de StreamSET2 ongeveer gelijk is aan StreamSET3.
Er zijn een aantal mogelijkheden om dit te doen:
a) Door het in java geschreven programma te compileren naar binaire codes voor de
hardware CPU ipv voor de software CPU.
b) Door het gebruik van een Just In Time Compiler (JIT-compiler)
ad a).
Dit levert voor de stelling op dat er geen verschil in snelheid mag bestaan, daar
beide talen naar dezelfde hardware CPU worden gecompileerd en dus de stroom
binaire codes voor die hardware CPU beide keren alleen zullen bestaan uit binaire
codes die behoren tot het programma, en dus niet tot een virtual machine. Echter
het neemt ook het platform onafhankelijke karakter weg van java. Deze optie valt
dan ook buiten de te bewijzen hypothese, daar het javaprogramma dan niet meer op
een virtual machine draait.
ad b).
De JIT techniek heeft tot aan vandaag geresulteerd in een verkorting van de
uitvoertijd van een javaprogramma door een virtual machine. In theorie is de
techniek gebasseerd op het feit dat de virtual machine naar buiten toe (naar het
javaprogramma toe) services moet aanbieden als een software cpu en aanverwante
zaken die in de virtual machine zijn gedefinieerd, echter de uitvoering van
het javaprogramma hoeft niet volgens de aloude methode te verlopen, ALS de stroom
binaire codes die door de hardware CPU wordt geleid maar resulteert in hetzelfde
resultaat als de uitvoering van StreamSET2.
De ultieme JIT-compiler is een compiler die een java programma bestaande uit binaire
codes voor de software CPU omzet naar binaire codes voor de hardware CPU, real time.
Immers, alleen dan is StreamSET2=StreamSET3 en is de set binaire codes voor de
hardware CPU die bedoeld zijn voor de Virtual Machine gelijk aan een lege set.
Deze ultieme JIT compiler is tegenwoordig nog niet snel genoeg, maar aangezien dat
wellicht in de toekomst kan veranderen, nemen we aan dat deze JIT-compiler 0 seconden
in beslag neemt van de uitvoertijd van het javaprogramma.
Wat we hebben is:
Javaprogramma -> compiler -> binaire codes -> ultimate JIT -> StreamSET3
C++programma -> compiler -> StreamSET3
Aangezien in StreamSET3 geen andere binaire codes zitten dan de binaire codes
waaruit het programma bestaat, kan StreamSET3 niet een superset zijn van een
tweetal of meerdere sets binaire codes zodat men een of meerdere van deze subsets
kan nemen, maar niet alle, zodat deze toch het volledige programma kunnen bevatten.
Concluderend: Java kan nooit sneller zijn dan C++.
SideNote:
Aangezien de ultieme JIT compiler tegenwoordig wel degelijk nog traag is en dus
voor andere mogelijke JIT technieken moet worden gekozen, worden DELEN van de
uit te voeren binaire codes voor de software CPU vertaalt naar binaire
codes voor de hardware CPU, en dus dat de uitvoering van de software CPU binaire
codes eigenlijk niet plaatsvind. Verder kan worden gekozen voor een andere aanpak,
door een library samen te stellen van veel gebruikte programma-constructies en
die al te vertalen naar binaire codes voor een hardware CPU, zodat de virtual
machine dmv de JIT compiler rechtstreeks de software CPU binaire codes kan uitvoeren,
zonder ook daadwerkelijk die software CPU te gebruiken. Deze techniek wordt ook
door andere op virtual machines gebasseerde talen gebruikt, zoals Visual Basic.
Men kan, in theorie, StreamSET3 benaderen, door heel veel delen te vertalen en
voor de overige delen de library van voorvertaalde delen te gebruiken.
Als de JIT-compiler die de delen vertaalt maar binaire codes aflevert die optimaal
zijn, plus dat de library optimaal moet zijn, zal het java programma bijna even
snel draaien als het C++ programma, gecompileerd naar optimale binaire codes voor
de hardware CPU. Beide zaken kunnen verschillen: de C++ compilatie hoeft niet
optimaal te zijn, en er kunnen onnodig veel binaire codes in de StreamSET3 zitten,
die de uitvoeringstijd van het C++ programma langer maken dan nodig, zelfs langer
dan het java programma wat gebruik maakt van wellicht wel een JIT compiler die
optimale code aflevert, plus een optimale library. Echter de StreamSET3 van het
C++ programma zal ZOVEEL extra, vertragende, code moeten bevatten dat de StreamSET1,
waartoe ook de instructies voor de JIT behoren, een kortere uitvoeringstijd
heeft.
Dit is ook de reden dat voorbeelden met betrekking tot dit onderwerp niet voldoende
zijn om enige concensus te bereiken.
[/...]
Verwijderd
Touché
Zal denk ik wel gelden, zit alleen in een beetje formele hoek te werken, dus dan wordt je een beetje paranoide over 'informele' specificaties. Ik neem aan dat Sun een behoorlijke groffe test bench op een kandidaat loslaat. In mijn omgeving is men echter niet van iets overtuigd totdat het met enige pagina's formules heeft bewezen (daar zit je dan tussen als enige 'praktische' jongen). Ik ben veel voorzichter geworden in het accepteren van opmerkingen van "dit doet hetzelfde als dat" zonder formeel bewijs. Te veel leuke voorbeelden gezien waar het toch subtiel mis ging. Mensen maken gewoon fouten.
Ik baseer mijn eerst zien dan geloven mening grotendeels op wat projectjes die ik in het verleden gedaan heb met swing stuff erin.
Tegenwoordig alleen bezig met support op een console app, waar ik tegen vrijwel niks opgewandeld ben. (alleen een 64K limiet op de groote van method in sommige jdk-1.3 versies, wat voor gegenereerde (java) code irritant is)
Zie boven oa. Inderdaad ik ben geen java specialist, daarvoor gebruik ik het te weinig. Breid echter wel mijn kennis ervan uit as I go. Ik ben alleen een beetje kritisch t.o.v. de 'hosanna java is de oplossing voor alles' toon die je soms (vaak) hoort, terwijl er nog best wel probleempjes zijn met het geheel.
Je hoort mij zeker niet zeggen dat java slecht is. Java is best goed. Ik bekijk zaken alleen graag praktisch. Java is leuk in sommige situaties in andere niet. Idem ditto voor C of C++. Op het moment zie ik zelf C++ als meest flexibele taal van de twee (maar ook als eentje waarin je moet weten wat je doet. (de pistolen en voeten discussie zeg maar)).
Verwijderd
Het staat jou vrij om een tegenbewijs te leveren, het is tenslotte een poging tot een bewijs voor een hypothese. Als jij kunt bewijzen dat de HYPOTHESE dat Java best in doorsnee applicaties sneller kan zijn dan C++ (dus de app in java geschreven vs de app in C++ geschreven), dan kun je dat toch doen? Al wat je nu doet is piepen dat mijn bewijs kreupel is. Maar meer dan die opmerking komt er niet uit, dus ik zou zeggen: proof me wrong. Zo werkt het nu eenmaal: het is waar totdat het tegendeel bewezen is. Dat jij mijn bewijs 'kreupel' vindt, zie ik niet aangetoond door jouw 'het is kreupel' bewering. En als je met een goed bewijs komt dan ben ik de eerste om toe te geven dat je gelijk hebt.
Als je mn betoog goed leest zul je zien dat de reden waarom Java altijd trager is, is het feit dat je tijd kwijt bent aan de realtime optimizer (de JIT) om de VM executietijd te compenseren (immers die heb je niet in C++). De oplossing, zoals al eerder opgevoerd, is het verhuizen van de JIT+VM van de main processor die EN de jit EN de VM EN de code die daar uit komt moet draaien naar naar een HW oplossing. Zodoende hou je 100% tijd over op je main CPU voor de executie van de uiteindelijke code zoals ook bij C++ het geval is. (en wat bv in de crusoe gebeurt).
Verder is het gebruikelijk dat bij een 'bewijs' de aannames worden verwoord. Elk wetenschappelijk bewijs heeft deze.
Java zou dus geholpen zijn met een extra proc, speciaal voor de VM/JIT. Of dan het verkoop argument nog opgaat dat write once run everywhere==true, valt te betwijfelen, maar je hebt dan wel een java execution environment die sneller is dan C++.
Als je mn betoog goed leest zul je zien dat de reden waarom Java altijd trager is, is het feit dat je tijd kwijt bent aan de realtime optimizer (de JIT) om de VM executietijd te compenseren (immers die heb je niet in C++). De oplossing, zoals al eerder opgevoerd, is het verhuizen van de JIT+VM van de main processor die EN de jit EN de VM EN de code die daar uit komt moet draaien naar naar een HW oplossing. Zodoende hou je 100% tijd over op je main CPU voor de executie van de uiteindelijke code zoals ook bij C++ het geval is. (en wat bv in de crusoe gebeurt).
Verder is het gebruikelijk dat bij een 'bewijs' de aannames worden verwoord. Elk wetenschappelijk bewijs heeft deze.
Java zou dus geholpen zijn met een extra proc, speciaal voor de VM/JIT. Of dan het verkoop argument nog opgaat dat write once run everywhere==true, valt te betwijfelen, maar je hebt dan wel een java execution environment die sneller is dan C++.
Kort samengevat:
Je kunt nooit zeggen java is beter dan(?) c++. java kan alleen beter zijn dan c++ voor een bepaald probleem. Maar dat is ook niet waar dit verhaal om gaat.
Java verslaat c++ met het aantal programmeurs. Er zijn dadelijk meer mensen die in java proggen dan er mensen zijn die in c++ proggen(dat is de conclusie van het onderzoek)
Ik zie heel duidelijk in dat java niet "het geschenk uit de programmeerhemel" is. Maar om java alleen af te serveren op de snelheid in desktop app's is erg kort door de bocht, oneerlijk en onrealistisch.
[drogredenering]
Als microsoft er een kloon van gaat maken, dan moet het toch wel een interressante technologie zijn (in die zien promoot microsoft java
[/drogredenering]
Java is een mooie oplossing voor mensen die de uitgebreide mogelijkheden van c++ niet nodig hebben en daar niet lastig gevallen mee willen worden. Wil jij dat wel: heel goed houden zo! geen probleem.
Punt.
Je kunt nooit zeggen java is beter dan(?) c++. java kan alleen beter zijn dan c++ voor een bepaald probleem. Maar dat is ook niet waar dit verhaal om gaat.
Java verslaat c++ met het aantal programmeurs. Er zijn dadelijk meer mensen die in java proggen dan er mensen zijn die in c++ proggen(dat is de conclusie van het onderzoek)
Ik zie heel duidelijk in dat java niet "het geschenk uit de programmeerhemel" is. Maar om java alleen af te serveren op de snelheid in desktop app's is erg kort door de bocht, oneerlijk en onrealistisch.
[drogredenering]
Als microsoft er een kloon van gaat maken, dan moet het toch wel een interressante technologie zijn (in die zien promoot microsoft java
[/drogredenering]
Java is een mooie oplossing voor mensen die de uitgebreide mogelijkheden van c++ niet nodig hebben en daar niet lastig gevallen mee willen worden. Wil jij dat wel: heel goed houden zo! geen probleem.
Punt.
Dat is inderdaad een vervelend punt. Java is ook nog teveel in ontwikkeling. In de toekomst zal Java als standaard platform meer stabiliseren. Wat niet wegneemt dat versie management een zwaar onderschat punt is in Java. Er lopen ook enkele RFEs om hier een goede oplossing voor te verzinnen. Het is echter een onoplosbaar probleem.
De uitwisseling tussen de IBM/Sun/Apple VMs verloopt vrij goed. Sun heeft een uitgebreidde test-suite, waarmee de correctheid van implementaties getest kan worden. Maar uiteraard is het wel een probleem.Verder duiken er ook steeds meer java implementaties op en niemand maakt mij wijs dat die allemaal 100% hetzelfde doen
Native code is nooit veilig. Met veiligheid doel ik op de mate waarop je als gebruiker de code die je runt kan vertrouwen. Het Java Platform heeft security als uitgangspunt gekozen en levert dit op een manier zodat je veilig Applets en Java Webstart applicaties kunt draaien op je client.
Java is altijd al type-safe geweest. Er is een onderscheid tussen de type-safety die at compile time gegarandeerd kan worden en de dynamische type-safety, die gegarandeerd wordt door de VM. De oude collections waren ook type-safe, maar dan at run-time. Type safety betekent namelijk alleen maar dat er geen illegale operaties op een data type kunnen worden uitgevoerd. De geparameterizeerde typen zorgen ervoor dat er at compile-time al meer checks kunnen worden uitgevoerd, maar daarmee houdt het ook op.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Idd, en deze reply maakt het er niet minder vervelend op...
Wat wil je daarmee zeggen? dat sun iets niet toe mag voegen omdat het al in win32 zit? Dat het achterhaald is?Er wordt continu door een paar advocates (zie usericons
Java als 'platform' is iets anders. Wat ze in het platform stoppen voor 'features' zijn in de hedendaagse platforms als Win32 al lang terug te vinden.
Wat is je punt hier? Die demo gaat erover dat java dit door de nieuwe technologie van jdk1.4 nu kan op snelheid
Ik zou precies hetzelfde tegen jou kunnen vertellen
Begrijp eens dat snelheid niet het belangrijkste is in elke applicatie...
Dat ligt aan de manier waarop hij wordt gevoerd. Als jij een discussie vervelend vind omdat je niet gelijk krijgt is dat vooral jouw probleem
.Ik werk al jaren in Java en ben bijna afgestudeerd in de software technologie (niet dat dat iets zegt trouwens). Ik tracht al jaren aan mensen uit te leggen wat het verschil is tussen de taal Java en het Java Platform (Ik probeer ook vrij precies te zijn in deze naamgeving). Het verschil tussen de twee beheers ik daarom vrij goed. ACM en Wasigh idem dito.Er wordt continu door een paar advocates (zie usericons
Klopt, maar het is vrijwel nergens terug te vinden op de manier zoals het Java Platform deze features biedt: platform onafhankelijk. Ik ken jouw beroemde uitspraak "Lunix boeit mij niet want ik werk op MS Windows". Nou, sommige mensen boeit Linux, Solaris, Mac OS X en andere operating systems dus wel.
Java 3D maakt transparant gebruik van DirectX en OpenGL. Maar dat zegt uiteraard niks.
Discussieren met mensen die percee een platform willen verbannen is ook zinloos en vervelend. Zelf werk ik ook zeer regelmatig met .NET en C#. Ik vind C# en Java allebei interessante en goede talen (er zijn betere). Dat ik het Java Platform goed vind werken, zegt niets over mijn mening over andere platformen. Daar hebben we het namelijk niet over.
Sorry hoor, maar het is misschien heel leerzaam om zelf even door te lezen wat voor verstandige woorden je nu plaats op GoT.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
Vind ik bijzonder jammer dat je dat zegt. Dat is het namelijk wel. De meest-gehoorde kreet richting computers is hedentendage niet voor niets "schiet dat g*dv*rg*t*n h**r*nding nou nog eens op??" en "sloom k*tkr*ng!".
Om maar niet te spreken over mijn ervaringen op school waar we geen linux mogen installeren met windows NT4, office XP en internet exploder 6 op een pentium-200 ofzo die nu ongeveer permanent ratelt
Neeeeeeeeeeeeeeee, snelheid is echt niet belangrijk.... Slechts bijzonder irritant als het er niet is, en daarmee absoluut een major point of attention. Slome applicaties verkopen niet (ook al bewijst microsoft keer op keer het tegendeel...)!
Verwijderd
Heb je gelijk in - ik vrees alleen dat dat voor grafische applicaties vaak helaas niet het geval is - en juist aan die kant staat en is java zo sterk. Wat dat betreft is het imho dus in die gevallen weer wel belangrijk dat het proggie zo snel mogelijk is, omdat je dan over veel grotere timespans praat.
5 ms/20 ms is vrees ik niet echt van toepassing op grote grafische applicaties..... (helaas niet
)
Verwijderd
Bravenboer: hoe kom je erbij dat ik niet van java gecharmeerd ben? Lees eens terug, ik zeg duidelijk dat ik de taal leuk vind. Het platform is veel minder, en vind ik in veel gevallen overhead, ik heb al een CPU en een platform op mn PC, daar hoef ik geen extra layer overheen.
Wasigh en jij zijn imho echte 'advocates': veel spervuur van hoe goed het allemaal is. Erg fijn allemaal, maar je vergeet dat er ook een praktijk is, en die leert dat het heel anders is. In 1995 toen ik met java begon was het allemaal nieuw, en rijkten de gouden bergen tot in de hemel. Nu, anno 2001, weet men wel beter. En denk niet dat ik de enige ben die gedesillusioneerd is. Ik ken developers die naast veel geld ook erg veel tijd hebben gestoken in het zich specialiseren in Java development en daar nu van terugkomen.
Het heeft zeker zn plaats, en de taal is er zeker een die C++ vervangen kan (ik programmeer er wel in, maar C++ is IMHO veel te cryptisch qua syntax), maar het platform is Dead. Op de server, voor servlets, verliest het het steeds meer van PHP, en op win32 is het binnen een paar jaar totaal verdwenen. De embedded markt daargelaten. (applets op smartcards, gedownload via het internet is een leuke toepassing).
Maar kunnen jullie eens ophouden met het blinde gepreek? Zodra het woord 'java' valt kun je bijkans geen negatieve opmerking er over maken, of je moet je CV gaan trekken en aantonen dat je er wat vanaf weet. Dat bedoelde ik met 'deze discussie begint vervelend te worden'. Ik bedoel: die 3D demo met 'DirectBuffers'. Dat java snel in sommige gevallen hoef je mij niet te vertellen. Maar hoe je het bracht, sorry, maar ik dacht even terug aan die Sun decipel die jaren terug Java kwam aanprijzen. Nu moet ik respect opbrengen voor jou als 'vakgenoot' (sinds wanneer zijn wij vakgenoten, sorry hoor) terwijl je JOUW lezer niet in staat acht te oordelen over de snelheid van Java en hoe die snelheid tot stand komt, wat er aan verbetert kan worden etc.
Real time optimizing is een interessant vakgebied, tezamen met compilerbouw en codeoptimizing. Dat realtime optimizing zeker belangrijk is is een feit (zie bv ook hoe SQLserver en andere databases compiled code 'tunen' aan de hand van statistics). Dat java echter nog een lange weg te gaan heeft met het platform (niet de taal) is echter ook realiteit. En een 3D demo met weet ik hoeveel faces/sec helpt daar echt niet bij.
Wat je verder aanroerde mbt 'java hoeft niet altijd snel te zijn, snelheid is niet altijd een vereiste', klopt zeker. In business logic components die veelvuldig met databases praten wordt er meer executietijd doorgebracht in de RDBMS dan in de business logic (althans, als je het goed doet). Daarom merk je bv ook niet 1 2 3 snelheidswinst als je je in VB geschreven BL components vervangt door in C++ geschreven BL components.
Echter, dat beschouwende, wat blijft er dan over als selling argument voor Java? Been there, done that, dus ik weet wat er te koop is, en wat ik bv als no. 1 topic vond op de lijst van irritante zaken is het eiland waarop je applicatie draait. Dit is tegenwoordig niet meer zo met native java support in bv Oracle, maar in veel applicaties ben je wel aangewezen op dat eiland. Veel gemakkelijker is het om terug te vallen op tools als VB, Delphi en C++, en ga daar je programmatuur in schrijven. VB is nl wel in staat om bv met win32 com components te communiceren, java niet. Althans, niet direct. Dan valt al veel af, dat zeg ik je bij voorbaat.
Nogmaals: de taal is leuk, maar voor snelheid hoef je het niet te nemen (er zijn snellere alternatieven zoals C++, trust me), en voor het gemak ook niet, want je bent aangewezen op wat Sun aanlevert aan libs, en aan 3rd party gateways die je de mogelijkheid geven toch met native 3rd party tools/components te communiceren buiten de VM om.
Tja, klinkt mij als 'niche' in de oren hoor, hoe je het ook wend of keert. Wat je er persoonlijk van vindt, by all means, het zal me wat. Maar zodra je op de preekstoel gaat staan en gaat verkondigen dat het heel wat is, kun je tegengas verwachten. Ga dan niet piepen als je dat ook daadwerkelijk krijgt.
Wasigh en jij zijn imho echte 'advocates': veel spervuur van hoe goed het allemaal is. Erg fijn allemaal, maar je vergeet dat er ook een praktijk is, en die leert dat het heel anders is. In 1995 toen ik met java begon was het allemaal nieuw, en rijkten de gouden bergen tot in de hemel. Nu, anno 2001, weet men wel beter. En denk niet dat ik de enige ben die gedesillusioneerd is. Ik ken developers die naast veel geld ook erg veel tijd hebben gestoken in het zich specialiseren in Java development en daar nu van terugkomen.
Het heeft zeker zn plaats, en de taal is er zeker een die C++ vervangen kan (ik programmeer er wel in, maar C++ is IMHO veel te cryptisch qua syntax), maar het platform is Dead. Op de server, voor servlets, verliest het het steeds meer van PHP, en op win32 is het binnen een paar jaar totaal verdwenen. De embedded markt daargelaten. (applets op smartcards, gedownload via het internet is een leuke toepassing).
Maar kunnen jullie eens ophouden met het blinde gepreek? Zodra het woord 'java' valt kun je bijkans geen negatieve opmerking er over maken, of je moet je CV gaan trekken en aantonen dat je er wat vanaf weet. Dat bedoelde ik met 'deze discussie begint vervelend te worden'. Ik bedoel: die 3D demo met 'DirectBuffers'. Dat java snel in sommige gevallen hoef je mij niet te vertellen. Maar hoe je het bracht, sorry, maar ik dacht even terug aan die Sun decipel die jaren terug Java kwam aanprijzen.
Nu moet ik respect opbrengen voor jou als 'vakgenoot' (sinds wanneer zijn wij vakgenoten, sorry hoor) terwijl je JOUW lezer niet in staat acht te oordelen over de snelheid van Java en hoe die snelheid tot stand komt, wat er aan verbetert kan worden etc. Real time optimizing is een interessant vakgebied, tezamen met compilerbouw en codeoptimizing. Dat realtime optimizing zeker belangrijk is is een feit (zie bv ook hoe SQLserver en andere databases compiled code 'tunen' aan de hand van statistics). Dat java echter nog een lange weg te gaan heeft met het platform (niet de taal) is echter ook realiteit. En een 3D demo met weet ik hoeveel faces/sec helpt daar echt niet bij.
Wat je verder aanroerde mbt 'java hoeft niet altijd snel te zijn, snelheid is niet altijd een vereiste', klopt zeker. In business logic components die veelvuldig met databases praten wordt er meer executietijd doorgebracht in de RDBMS dan in de business logic (althans, als je het goed doet
). Daarom merk je bv ook niet 1 2 3 snelheidswinst als je je in VB geschreven BL components vervangt door in C++ geschreven BL components. Echter, dat beschouwende, wat blijft er dan over als selling argument voor Java? Been there, done that, dus ik weet wat er te koop is, en wat ik bv als no. 1 topic vond op de lijst van irritante zaken is het eiland waarop je applicatie draait. Dit is tegenwoordig niet meer zo met native java support in bv Oracle, maar in veel applicaties ben je wel aangewezen op dat eiland. Veel gemakkelijker is het om terug te vallen op tools als VB, Delphi en C++, en ga daar je programmatuur in schrijven. VB is nl wel in staat om bv met win32 com components te communiceren, java niet. Althans, niet direct. Dan valt al veel af, dat zeg ik je bij voorbaat.
Nogmaals: de taal is leuk, maar voor snelheid hoef je het niet te nemen (er zijn snellere alternatieven zoals C++, trust me), en voor het gemak ook niet, want je bent aangewezen op wat Sun aanlevert aan libs, en aan 3rd party gateways die je de mogelijkheid geven toch met native 3rd party tools/components te communiceren buiten de VM om.
Tja, klinkt mij als 'niche' in de oren hoor, hoe je het ook wend of keert. Wat je er persoonlijk van vindt, by all means, het zal me wat. Maar zodra je op de preekstoel gaat staan en gaat verkondigen dat het heel wat is, kun je tegengas verwachten. Ga dan niet piepen als je dat ook daadwerkelijk krijgt.
Ik pik er even de voor mij relevante stukken uit:
) naar mijn idee beginnen steeds meer mensen java juist op zijn waarde te schatten. Ok desktop applicaties zijn niet de sterkste kant (geef ik toe!) zonder gein: het zijn ontwikkelingen die java-programmeurs vrolijk stemmen dat mag toch?
het enige echte nadeel van java wat je aandraagd is de snelheid. en daar wordt aan gewerkt. da's toch mooi??
Mij leert de praktijk dat de "gouden jaren" nog niet zijn aangebroken. Wat de praktijk leert is dus subjectief.
Als ik eerlijk ben geloof ik niet dat servlets het verliezen van php (cijfers?) ik heb met php en met jsp gewerkt. En je krijgt me voor geen goud meer aan de php(nou bij wijze van spreke dan
) naar mijn idee beginnen steeds meer mensen java juist op zijn waarde te schatten. Ok desktop applicaties zijn niet de sterkste kant (geef ik toe!)Je moet het met me eens zijn dat "de massa" roept "java is traag" zonder er uberhaupt mee gewerkt te hebben of in verdiept te hebben. het enige waar we onze opinie over jouw kennis naar kunnen vormen zijn je posts. En het enige wat je gedaan hebt in je posts(correct me if i'm wrong) is java in snelheid vergelijken met C++.
tss je bent een javahova of nietDat bedoelde ik met 'deze discussie begint vervelend te worden'. Ik bedoel: die 3D demo met 'DirectBuffers'. Dat java snel in sommige gevallen hoef je mij niet te vertellen. Maar hoe je het bracht, sorry, maar ik dacht even terug aan die Sun decipel die jaren terug Java kwam aanprijzen.
zonder gein: het zijn ontwikkelingen die java-programmeurs vrolijk stemmen dat mag toch?Respect voor mede programmeurs is niet zo vreemd, en het is een feit dat mbravenboer een gerespecteerd lid is van /14. Je bent mij teveel op snelheid gefocust terwijl het daar volgens mij niet over ging..
Er valt veel af voor jou, je kan niet voor iemand anders oordelen
yep, ik denk dat we dat allemaal weten en zullen beamen. Maar dat c++ sneller is maakt java niet traag.
Jouw mening
tegengas is leuk in een discussie, maar zoals je zelf eerder al aanhaalde. blind gaan schreeuwen heeft geen zin.
het enige echte nadeel van java wat je aandraagd is de snelheid. en daar wordt aan gewerkt. da's toch mooi??
:strip_exif()/u/25166/new-ico.gif?f=community)
Jij zult zeker vervelende ervaringen hebben met Java en ik geloof ook zeker dat meer mensen die zullen hebben.
LOL
. Heel erg fijn dat je jouw persoonlijke visie als feiten verspreid. Java Servlets bieden toch wel een wat andere omgeving dan PHP. Bovendien zie ik geen bewijzen dat Java server-side steeds minder in gebruik zijn. Wil je serieus beweren dat een taal zonder multi-threading, goede object-orientatie, polymorphisme in diverse vormen een serieuze vervanger is voor Java .Verder is je opmerking dat Java op win32 binnen een paar jaar verdwenen is helemaal een persoonlijke visie van jou. Java is helemaal niet gerelateerd aan wat voor platform dan ook. In de opkomende markt van desktop operating systems kan Java wellicht een belangrijke rol spelen.
Het punt is dat jij niets anders doet dan negatieve opmerkingen maken. Je maakt onjuiste vergelijkingen, presenteert ongeldige bewijzen die veel lijken op middeleeuwse bewijzen dat God bestaat. Ik weet genoeg negatieve aspecten van Java te noemen. Java is niet perfect. Het idee achter Java is wel perfect.
De manier waarop jij discussieerde is zeer onaangenaam. Jij probeert voortdurend argumenten te maken door te zeggen dat je mede discussie genoten er niets vanaf weten. Dat ik daarbij noem dat ik een degelijk opleiding heb genoten is niet meer dan logisch.
Ik bezit behoorlijk wat kennis van Java en het Java Platform. In discussies zet ik die kennis in om dingen uit te leggen over de punten die ter discussie komen. Mag dat? Toevallig zijn er erg veel mensen geinteresseerd in deze ontwikkelingen.
Ik spreek wat betreft de run-time optimalisaties ook voortdurend over de toekomst. Ik vermoed dat deze in de toekomst na een lange ontwikkeling een pluspunt kunnen zijn. Ik noemde de 3D demo omdat dit aantoont dat de nieuwe ontwikkelingen toepassingen met grote data-sets mogelijk maakt. Mag dat niet?
Dit is weer zo'n stelling-name: ik ben beter dan jullie. Ik weet alles, waar jullie mee bezig zijn, ben ik allang overheen. Beste Otis, zo voer je geen discussie. Ik word er ook een beetje moe van om je daar steeds op te moeten wijzen, dus ik zal het vanaf nu niet meer doen.
Naast Sun zijn er nog veel andere grote Java supporters. Heb je weleens op de site van IBM gekeken? Ben je weleens bij alle uitermate interessante projecten van Apache geweest? Weleens gekeken naar JBoss? Ik noem zo maar een paar zaken uit mijn hoofd.
Het punt is dat jij jouw persoonlijk mening ziet als de volledige waarheid. Denk er eens bij na dat ik jouw posts op dezelfde manier kan zien als jij mijn posts.
Je gaat op veel van mijn concretere antwoorden geeneens in. Vind je het dan niet interessant meer? Als ik geen antwoord krijg op mijn reacties op jouw stellingen ga ik er van uit dat ik gelijk heb.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Wow. Java discussie, dus mbravenboer en wasigh verkondigen het grote J woord weer! Dat mag ook wel met al die heidenen die er blijkbaar niet zo veel vanaf weten hehehe... Hoe heette God in het Hebreeuws ook al weer, Jahwe ofzo? Komt al best in de buurt toch lol
Anyway Java is cool, Java is flexibel, en Java is langzaam. Als je toch duffe business logic maakt dan kun je dat het beste in java doen denk ik, dan snap je het over 2 maanden nog, dat is in c++ wel anders. Maarre, Doom 3, dat gaat dus nevernooit op java draaien.
Conclusie: als je lekker object georienteerd, snel gemakkelijk, uitbreidbaar en platformonafhankelijk je programma's in elkaar wilt zetten, dan pak je java, want die forceert dat allemaal, altijd goed dus. En als het echt real time moet, spelletjes en hartbewaking enzo, of een kritische memory management, dan pak je c++. Een echte bikkel kan het toch allebei, enne, een echte loser kan niet zonder COM components hahaha wat een non argumenten allemaal zeg.
Zo lekker vaag maar het is al vroeg
Dat mag ook wel met al die heidenen die er blijkbaar niet zo veel vanaf weten hehehe... Hoe heette God in het Hebreeuws ook al weer, Jahwe ofzo? Komt al best in de buurt toch lol Anyway Java is cool, Java is flexibel, en Java is langzaam. Als je toch duffe business logic maakt dan kun je dat het beste in java doen denk ik, dan snap je het over 2 maanden nog, dat is in c++ wel anders. Maarre, Doom 3, dat gaat dus nevernooit op java draaien.
Conclusie: als je lekker object georienteerd, snel gemakkelijk, uitbreidbaar en platformonafhankelijk je programma's in elkaar wilt zetten, dan pak je java, want die forceert dat allemaal, altijd goed dus. En als het echt real time moet, spelletjes en hartbewaking enzo, of een kritische memory management, dan pak je c++. Een echte bikkel kan het toch allebei, enne, een echte loser kan niet zonder COM components hahaha wat een non argumenten allemaal zeg.
Zo lekker vaag maar het is al vroeg
Verwijderd
En over wie had je wat te piepen?
Ik heb erg veel tekst gepost in deze thread, om nu dat te herkauwen in kleine beetjes als antwoorden op jouw antwoorden lijkt me wat onnodig. Ik blijf erbij dat zodra 'java' valt en je iets negatiefs zegt daarover, je door de advocates onder de zoden wordt gestopt. Lees dan je eigen posting hierboven eens na! Ik heb je en anderen gewezen op discussies zoals die al 2 jaar geleden zijn gevoerd in nl.comp.programmeren, waar ik een deel hier vanpostte, die over exact hetzelfde gingen. Puur als aanvulling. Tja.
Als ik dan 'alleen maar negatief' ben, so be it. Als ik negatief over java wil zijn dan doe ik dat, tenslotte heb ik kennis genoeg over de materie. Jij kennelijk ook en je hebt een ander oordeel.
En je mag van mij gelijk hebben hoor.
Advocates krijgen van mij altijd gelijk als de discussie op het punt beland van "als ik geen antwoord krijg op mijn 1500 regelig repliek heb ik gelijk" haha . Of je ook gelijk HEBT, is wat anders. Maar daarvoor verwijs ik graag terug naar een van mijn 1000 regelige postings in deze thread.Wat me wel stoort is het feit dat ik geprobeerd heb de discussie naar een wat meer analytisch niveau te tillen dan het niveau van "het is sneller welles/nietes want mijn app blabla". Enfin, dat was een vergissing. Veel plezier nog in deze 'discussie'.
.
Over jouOtis: En over wie had je wat te piepen?
. Ik ben heel concreet ingegaan op jouw argumenten tegen mijn opsomming van de voordelen van java en het Java Platform. Op geeneen ben je serieus ingegaan. Heb ik je nog of dynamic class loading, COM en Corba gehoord?Ik probeer de discussie naar een technische analyse van Java en het Java Platform te leiden zonder vage uitspraken te doen. Dat lukt ook niet
.HeheEnfin, dat was een vergissing. Veel plezier nog in deze 'discussie'.
. Hier stond net iets over vakgenoot. Wat dacht je? Oops, I did it again?
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Otis, lees ff je eigen reacties door en kijk eens in de spiegel.
Het is nl nogal een pot verwijt de ketel verhaal.
Voor de laatste keer: verder voor de 100* _daar ging dit topic niet over_
Het is nl nogal een pot verwijt de ketel verhaal.
Voor de laatste keer:
Onder de zoden gestopt? Mbravenboer en ik zijn de 1-sten die toegeven dat Java ook negatieve kanten heeft (ja echt waar staat in dit topic!) verder is wat jij doet meer een poging tot onder de zoden stoppen dan een poging tot een discussie. Als je discussie begint zonder open te staan voor andere ideeen, wat je duidelijk niet doet. begin dan ook niet aan een discussie.
Die gingen niet over exact hetzelfde
Kijk dat is nog eens een intelligent inzicht
mmm, heb je het nu over jezelf? als er iemand is die veel blaat zonder wol ben jij het tot nu toe geweest. Je hebt meningen als feiten gepresenteerd en als het al feiten waren dan miste elke bewijs.En je mag van mij gelijk hebben hoor.
Je bedoelt die posting over dat c++ altijd sneller als java, daar is volgens mij al genoeg kritiek op geweest. Als ze dadelijk een java chip uitbrengen hangt je hele hypothese
verder voor de 100* _daar ging dit topic niet over_imo heb je alleen je gelijk proberen te halen door tehcnische termen aan te halen. Misschien moet je eens leren open te staan voor andere denkwijzenWat me wel stoort is het feit dat ik geprobeerd heb de discussie naar een wat meer analytisch niveau te tillen dan het niveau van "het is sneller welles/nietes want mijn app blabla". Enfin, dat was een vergissing. Veel plezier nog, 'vakgenoot'
Einde zinloze discussie. Laten we het eens op een objectieve, technische en duidelijke manier over Java en het Java Platform hebben. Voor de liefhebbers wil ik graag nog even wat grote nadelen van het Java en het Java Platform vermelden . Ik hoop dat hieruit een zinvolle en interessante discussie kan ontstaan .
Allereerst over de taal Java:
* Java maakt onderscheid tussen primitieven en objecten. Hierdoor kan je geen ints gebruiken in generieke code zoals verzamelingen. De int moet hiervoor geconverteerd worden naar een Integer object om hem in een verzameling te kunnen stoppen.
* Generics (ook wel geparameterizeerde typen genoemd) zullen pas komen in een latere versie van Java. Dit was voor versie 1 eigenlijk een onmisbare functie geweest. Nu moeten er enorm veel concessies gedaan worden om de code compatible te houden met oudere Java VMs. Dit zorgt ervoor dat generics niet op een fraaie manier geimplementeerd zijn (maar ondanks dat wel op een fraaie manier gebruikt kunnen worden).
* De reflectie implementatie is in feite een hack. Dit is een grote vergissing geweest en het had zeker een onderdeel moeten zijn van de eerste Java specificaties.
* Java heeft geen ondersteuning voor constanten, tenzij via een verwarrende syntax gedeclareerd. Vooral de mogelijkheid om final variabelen in een klasse op te nemen en ze daarna in de constructor een waarde te geven is verwarrend. Uberhaupt is het verwarrend dat je klasse variabelen zowel in de constructor als in de declaratie een waarde kunt geven.
* Java heeft geen ondersteuning voor contravariante argument type, waar theoretisch absoluut geen bezwaar tegen te maken is.
* Java heeft geen ondersteuning van enumeraties. Op zich is dat geen probleem omdat het op een fraaie object-georienteerde manier valt te realizeren, maar feit is dat dit niet gebeurt. De Java API zelf wemelt van de constante integers om zogenaamd als enumeratie vervangen te dienen. Ik weet niet of je weleens bent begonnen met tellen bij 0 totdat je moe was, maar ik kan je garanderen dat dat een behoorlijke enumeratie is!
* Java's systeem van constructor overerving is ongelukkig. Vaak bieden klassen veel constructor varianten. Als je deze klasse extend, moet je voor al deze gevallen opnieuw een constructor aanmaken. Daar word je niet blij van.
* Java heeft geen override aanduiding, waardoor het onduidelijk kan zijn of je daadwerkelijk iets override of niet. Zeker kan de compiler dit niet voor je controleren.
* java.lang.Object bevat wat merkwaardige methoden die daar naar mijn mening niet thuis horen. Allereerst is er een standaard equals methode. Dat vind ik niet prettig, want sommige objecten zijn gewoon niet vergelijkbaar. Bovendien is er geen mogelijkheid om af te dwingen dat een klasse een goede implementatie van een equals methode heeft. Eigenlijk zou de equals eruit moeten en vervangen moeten woorden door een interface. Hetzelfde verhaal geldt in feite voor hashCode en clone. Verder vind ik die methoden voor multi-threading in java.lang.Object niet fraai. Ook hiervoor zou eigenlijk een apart systeem gemaakt moeten worden, zodat niet alles een lock is. Laten we het maar helemaal niet gaan hebben op de uitermate obscure manier van serializatie via de Serializable interface.
* public static void main(String[] ps) is antiek. Java is OO, laten we dan ook applicaties op een OO manier starten. Het volgende idee:
Weg magie. Weg onduidelijkheid.
Dat was een aardig lijstje niet? Ik weet zeker dat ik nog ergernissen ben vergeten, maar helaas kan ik ook niet door blijven denken. Ik ga even over op Java als Platform. Ik ga niet in op de massa design fouten in de Java bibliotheken, want dan zou ik een perpetuum mobile moeten zijn.
* Java bytecode is veel te veel Java bytecode. Java bytecode is duidelijk opgezet als bytecode voor gecompileerde Java. Dat is een ongelukkige beslissing, want Java staat al behoorlijk op een eiland doordat het in een VM draait. JNI is ook nogal een gevaarte, wat niet erg prettig werkt. Java bytecode zou een grotere instructieset moeten hebben, waardoor andere talen makkelijker naar Java bytecode kunnen worden gecompileerd. In feite komt het er op neer dat wanneer een taal op het Java Platform wil draaien, hij gecompileerd moet kunnen worden naar de taal Java.
* De Java VM is nogal vaak bezig met het opnieuw uitvinden van het wiel. Allereerst wordt elke applicatie in een aparte VM gedraaid (nog). Dit is uitermate ongelukkig. Ten tweede wordt code die naar native code gecompileerd is niet opgeslagen. Dit is begrijpelijk omdat dit zeer veel complicaties zou veroorzaken, maar het zou misschien wel mogelijk moeten zijn als je dit zelf expliciet aangeeft.
* Doordat Java zo enorm afhankelijk is van het Java Platform gaan er in de toekomst grote problemen komen. Als Java vervangen gaat worden door een beter alternatief en de implementaties van Virtual Machines langzaam stopt, wat gebeurt er dan met al je Java code? Een groot deel van de software die nu draait is nog steeds in Cobol geschreven. Hoe zal Java functioneren als verouderde taal?
* Een Java Virtual Machine zou eigenlijk verschillende modussen moeten hebben voor andere versies van Java (bijvoorbeeld 1 versus 2). Ooit komt er een tijd dat methodens en klassen die deprecated zijn, ook daadwerkelijk verwijderd gaan worden. Wat gebeurt er met alle bestaande applicaties die daar nog steeds gebruik van maken? Die werken gewoon niet meer.
Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd . Ondanks alles is Java als taal en Java als Platform voor mij nog steeds een goede keuze. Ik kijk uit naar een omgeving die Java perfectioneert. Misschien wordt het in de toekomst tijd voor een grondige herziening van Java en het Java Platform, om de lessen van de afgelopen jaren te verwerken. Hierbij zou absoluut geen rekening gehouden moeten worden met oudere Java versies. Je zult zeggen, wel daar is .NET, maar daar ben ik het dan weer niet helemaal mee eens.
Voordat een grondige herziening moet plaatsvinden zijn we echter nog wel 5 - 7 jaar verder. Eerst moet het Java Platform stabiliseren. Dit zal zeker nog 2 a 3 jaar duren naar mijn mening.
. Ik hoop dat hieruit een zinvolle en interessante discussie kan ontstaan .Allereerst over de taal Java:
* Java maakt onderscheid tussen primitieven en objecten. Hierdoor kan je geen ints gebruiken in generieke code zoals verzamelingen. De int moet hiervoor geconverteerd worden naar een Integer object om hem in een verzameling te kunnen stoppen.
* Generics (ook wel geparameterizeerde typen genoemd) zullen pas komen in een latere versie van Java. Dit was voor versie 1 eigenlijk een onmisbare functie geweest. Nu moeten er enorm veel concessies gedaan worden om de code compatible te houden met oudere Java VMs. Dit zorgt ervoor dat generics niet op een fraaie manier geimplementeerd zijn (maar ondanks dat wel op een fraaie manier gebruikt kunnen worden).
* De reflectie implementatie is in feite een hack. Dit is een grote vergissing geweest en het had zeker een onderdeel moeten zijn van de eerste Java specificaties.
* Java heeft geen ondersteuning voor constanten, tenzij via een verwarrende syntax gedeclareerd. Vooral de mogelijkheid om final variabelen in een klasse op te nemen en ze daarna in de constructor een waarde te geven is verwarrend. Uberhaupt is het verwarrend dat je klasse variabelen zowel in de constructor als in de declaratie een waarde kunt geven.
* Java heeft geen ondersteuning voor contravariante argument type, waar theoretisch absoluut geen bezwaar tegen te maken is.
* Java heeft geen ondersteuning van enumeraties. Op zich is dat geen probleem omdat het op een fraaie object-georienteerde manier valt te realizeren, maar feit is dat dit niet gebeurt. De Java API zelf wemelt van de constante integers om zogenaamd als enumeratie vervangen te dienen. Ik weet niet of je weleens bent begonnen met tellen bij 0 totdat je moe was, maar ik kan je garanderen dat dat een behoorlijke enumeratie is!
* Java's systeem van constructor overerving is ongelukkig. Vaak bieden klassen veel constructor varianten. Als je deze klasse extend, moet je voor al deze gevallen opnieuw een constructor aanmaken. Daar word je niet blij van.
* Java heeft geen override aanduiding, waardoor het onduidelijk kan zijn of je daadwerkelijk iets override of niet. Zeker kan de compiler dit niet voor je controleren.
* java.lang.Object bevat wat merkwaardige methoden die daar naar mijn mening niet thuis horen. Allereerst is er een standaard equals methode. Dat vind ik niet prettig, want sommige objecten zijn gewoon niet vergelijkbaar. Bovendien is er geen mogelijkheid om af te dwingen dat een klasse een goede implementatie van een equals methode heeft. Eigenlijk zou de equals eruit moeten en vervangen moeten woorden door een interface. Hetzelfde verhaal geldt in feite voor hashCode en clone. Verder vind ik die methoden voor multi-threading in java.lang.Object niet fraai. Ook hiervoor zou eigenlijk een apart systeem gemaakt moeten worden, zodat niet alles een lock is. Laten we het maar helemaal niet gaan hebben op de uitermate obscure manier van serializatie via de Serializable interface.
* public static void main(String[] ps) is antiek. Java is OO, laten we dan ook applicaties op een OO manier starten. Het volgende idee:
code:
1
2
3
4
| public interface Application
{
public void start(List<String> parameters);
} |
Weg magie. Weg onduidelijkheid.
Dat was een aardig lijstje niet? Ik weet zeker dat ik nog ergernissen ben vergeten, maar helaas kan ik ook niet door blijven denken. Ik ga even over op Java als Platform. Ik ga niet in op de massa design fouten in de Java bibliotheken, want dan zou ik een perpetuum mobile moeten zijn.
* Java bytecode is veel te veel Java bytecode. Java bytecode is duidelijk opgezet als bytecode voor gecompileerde Java. Dat is een ongelukkige beslissing, want Java staat al behoorlijk op een eiland doordat het in een VM draait. JNI is ook nogal een gevaarte, wat niet erg prettig werkt. Java bytecode zou een grotere instructieset moeten hebben, waardoor andere talen makkelijker naar Java bytecode kunnen worden gecompileerd. In feite komt het er op neer dat wanneer een taal op het Java Platform wil draaien, hij gecompileerd moet kunnen worden naar de taal Java.
* De Java VM is nogal vaak bezig met het opnieuw uitvinden van het wiel. Allereerst wordt elke applicatie in een aparte VM gedraaid (nog). Dit is uitermate ongelukkig. Ten tweede wordt code die naar native code gecompileerd is niet opgeslagen. Dit is begrijpelijk omdat dit zeer veel complicaties zou veroorzaken, maar het zou misschien wel mogelijk moeten zijn als je dit zelf expliciet aangeeft.
* Doordat Java zo enorm afhankelijk is van het Java Platform gaan er in de toekomst grote problemen komen. Als Java vervangen gaat worden door een beter alternatief en de implementaties van Virtual Machines langzaam stopt, wat gebeurt er dan met al je Java code? Een groot deel van de software die nu draait is nog steeds in Cobol geschreven. Hoe zal Java functioneren als verouderde taal?
* Een Java Virtual Machine zou eigenlijk verschillende modussen moeten hebben voor andere versies van Java (bijvoorbeeld 1 versus 2). Ooit komt er een tijd dat methodens en klassen die deprecated zijn, ook daadwerkelijk verwijderd gaan worden. Wat gebeurt er met alle bestaande applicaties die daar nog steeds gebruik van maken? Die werken gewoon niet meer.
Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd
. Ondanks alles is Java als taal en Java als Platform voor mij nog steeds een goede keuze. Ik kijk uit naar een omgeving die Java perfectioneert. Misschien wordt het in de toekomst tijd voor een grondige herziening van Java en het Java Platform, om de lessen van de afgelopen jaren te verwerken. Hierbij zou absoluut geen rekening gehouden moeten worden met oudere Java versies. Je zult zeggen, wel daar is .NET, maar daar ben ik het dan weer niet helemaal mee eens. Voordat een grondige herziening moet plaatsvinden zijn we echter nog wel 5 - 7 jaar verder. Eerst moet het Java Platform stabiliseren. Dit zal zeker nog 2 a 3 jaar duren naar mijn mening.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
Wat verwijt ik de pot dan, als ketel zijnde? beetje ongenuanceerde opmerking.
Erm... ik ben veelal negatief geweest over java. Nu mag je jezelf op de borst slaan dat juist JIJ negatief bent over java, go ahead, maar wat is dan je probleem mbt mijn postings? Zijn ze te positief oid? En welke andere ideeen moet in omarmen? Die open deuren die ik al jaren zie in allerlei java publicaties? Die beloftes dat de 'volgende' JVM wel alles veel sneller zal doen e.d.? Als iemand mij oud nieuws vertelt, waarom moet ik daar dan nog op in gaan? omdat het voor jou NIEUW nieuws is? Dat is toch niet mijn probleem?
Mja, dat jij niet snapt wat ik bedoel met mn theoretische onderbouwing is niet mijn probleem hoor. Dat ik blaat zonder wol (?) is jouw constatering. Als iemand aankomt met zo'n verhaal over 3D rendering en ik zet daar mn vraagtekens bij, tja. Dat jij dat dan niet trekt, dat is OOK jouw probleem. Ik wil best daar ook een theoretische onderbouwing voor neerleggen maar ik denk dat dat verspilde moeite is. Sorry hoor, maar je gepiep hierboven is pure flamebait: AL mn meningen zijn als feiten gedeponeerd ZONDER ENIG bewijs. Tja:
Jehova: God bestaat!
Atheist: God bestaat NIET!
Jehova: Je levert geen enkel bewijs!
Welke kritiek? in de newsgroup bedoel je of hier? Het is een beschrijving van een theoretische situatie. En ja als de javachip er OOIT komt dan is het overbodige kost. Net zoals het niet opgaat als je java naar native code compileert en draait buiten de JVM om.[..]
Je bedoelt die posting over dat c++ altijd sneller als java, daar is volgens mij al genoeg kritiek op geweest. Als ze dadelijk een java chip uitbrengen hangt je hele hypothese
[..]
Tja... als je iets zegt wat niet waar is en ik toon aan dat dat niet waar is, en jij begint dan dat ik iets roep zonder enig bewijs, houdt het voor mij op hoor. Als jij denkt dat ik van niets weet en pas kom kijken heb je het mis. Ik hoor al jaren allerlei denkwijzen over het topic 'java', sommigen hebben gelijk, anderen niet. Het is maar een tool, een taal EEN platform. Niets meer. Daar lyrisch over doen is het meer ophemelen dan wat het feitelijk waard is. Dat is mn doel geweest in deze thread. Dat jij dat als aanval ziet op jouzelf is niet mijn probleem, ik heb helemaal niets tegen jou of jouw denkwijze. Wat me alleen stoort is dat ik geen negatief beeld mag schetsen van Java zonder dingen als:imo heb je alleen je gelijk proberen te halen door tehcnische termen aan te halen. Misschien moet je eens leren open te staan voor andere denkwijzen
naar mn kop te krijgen. En dan ga JIJ mij verwijten dat ik niet open sta voor andermans denkwijze. Laser toch op!
Verwijderd
Ik hoop dat ze genoeg diskspace hebben gereserveerd voor GoTOp vrijdag 31 augustus 2001 01:52 schreef mbravenboer het volgende:
Einde zinloze discussie. Laten we het eens op een objectieve, technische en duidelijke manier over Java en het Java Platform hebben. Voor de liefhebbers wil ik graag nog even wat grote nadelen van het Java en het Java Platform vermelden
Vaak gehoord als nadeel en OO-fetisjisten zeuren hier al jaren over: Java is niet puur OO want sommige basistypes zijn geen objects. Het is ook een lapmiddel geweest, om de JVM sneller te maken bij aritmetic operaties. Echter er valt wel wat voor te zeggen: als je gaat definieren wat een object is, dan kun je beredeneren dat (bv) een integer een vastomlijnd iets is, waar je, ookal creeer je derived classes, geen karakterwijzigingen aan kunt doen. In feite dus een base-class. Immers, je zou wel kunnen denken aan: baseclass number -> class integer, maar dan?
Dit is het aloude verhaal: "in C++ kun je wel X doen, in Java niet... Java sux". Generics lijken me hetzelfde toe als templates in C++. Op zich een krachtig instrument om taaltechnisch je expressiekracht te verhogen, echter noodzakelijk zijn ze geensinds. De theorie van OO/inheritance/polymorphism vereist geen generic types/templates. De enige reden dat templates/generic types er zijn / komen is het feit dat men middels taaltechnische truuks de hoeveelheid typewerk wil verkleinen. (want templates verlagen de hoeveelheid typewerk enorm, maar je kunt altijd om ze heen). Echter, als je kijkt naar hoe je je OO structuur ontwerpt, bv middels een NIAM/ER-model methodiek, dan is al wat rest die te implementeren en zodra je iets wijzigt, doe je dat eerst in het model, daarna genereer je de class definities opnieuw en DAARNA wijzig je de implementatie. Dat kun je doen met java 1.0. Daar heb je geen geparametriseerde types voor nodig.
Templates in C++ verlagen overigens drastisch de leesbaarheid van je code, daar code gegenereerd wordt middels de waarden van parameters. Een mens is erg slecht in het interpreteren van computertaal en heeft gem. gezien moeite met het interpreteren van dit soort constructies: wat is de class die wordt gegenereerd, bij inputparameters van deze en deze waarden?
Op zich is het niet raar dat er geen constantes in zitten. C++ heeft die ook niet. #define is in theorie een obsolete keyword, men wordt geacht enums te gebruiken. De reden hiervoor is is dat enums een type hebben en constants niet. Constants op zich zijn ook niet meer dan een taaltruuk: ipv '10' schrijf je "MAX_INTEGER_FOR_THIS_PURPOSE" oid. Als je nu variables gebruikt ipv de constante, ben je ook typesafe bezig. Vandaar dat final int MYMAXVALUE=3; op zich een betere keuze is dan #define MYMAXVALUE 3.
Dat de declaratie en de constructor variabele waarden toekenning toelaten is iets van C++ denk ik. Ik heb ook nooit begrepen waarom mensen in C++ bv in .h files allerlei dingen gaan verwoorden die in de .cpp thuis horen en vice versa.
Enums zijn in theorie alleen nodig indien je non-typesafe constantes toelaat, C++ doet dat dus wel, want #define mag bv. Java heeft al final type var=value dus op zich hoeft enum niet. Tuurlijk is het handig dat je een rijtje kunt genereren, maar als je goed kijkt naar wat een enum is, dan is het niets anders dan een class met het type van het enum met daarin de final variables.
Ikzelf gebruik enums nauwelijks, alleen in mn DemoGL scriptparser, in de lexical analyser tables. Maar je kunt goed zonder is mn ervaring.
Dit is denk ik het resultaat van de single inheritance: er is geen taalelement noodzakelijk om aan te geven dat je een bepaalde baseclass parent wilt instantieren, zoals bij C++ het geval is. Kennelijk heeft java de filosofie dat je altijd de uiterste leaf van een inheritance-hierarchie wil instantiaten (wat logisch klinkt
), ipv een class in het midden. Roep je een constructor aan van een baseclass van een zekere class, wat voor object krijg je dan? de baseclass of de zekere class?main is toch gewoon een default method van je .class of snap ik iets niet? je applicatie is toch het object, dus mag je een method daarin hebben die alles start, of je dat nu doet door een interface te implementeren of niet, is niet zo belangrijk. Als je nl. het via een interface doet, geef je daarmee aan dat er andere interfaces zijn die wellicht ook mogen. Waardoor executielogica extra complex wordt.
* filename.class moet hetzelfde zijn als de classname. Ik vind hoe het is opgelost in .NET een stuk fraaier en flexibeler.
Bytecode is een ouder idee hoe je VM's maakt. Per definitie ging men er van uit dat je dan bytecode behappende VM's moest maken en dat als target moest nemen voor je taal/compiler. Dat de java bytecode aan de taal is vastgeklonken is niet vreemd: java is gepositioneerd jaren terug als alternatief platform voor windows, op thin clients. Dat is ook de reden geweest dat Sun tegen MS is gaan procederen mbt MS' truukje in J++ 6 dat java-p (platform) van java-t (taal) is losgesneden: java-t werd gebruikt om COM objects (elegante manier overigens, echt intens jammer dat dat niet meer kan) te bouwen en naar native x86 te compileren...
De filosofie was: java-t is de toegang tot java-p. Dus promoot java-t en omdat java-p nodig is, wordt java-p wijdverspreid, wat de bedoeling was. Ga je java-p open stellen voor andere talen, is java-t overbodig en mis je je drive voor java-p (want waarom een vm targeten als je ook native kunt compileren met die taal?) en java-t naar andere platforms laten vertalen levert niet de gewenste verspreiding van java-p op.
aparte VM's is een security issue, de 'sandbox', en is een overblijfsel van de applet-crap. Applets leken de initiator tot de java-overwinning maar werden de uiteindelijke ondergang op de desktop. Overigens is het gebruikelijk dat VM's in aparte sandboxes draaien. de MSDos VM die in NT/win2k zit draait ook alles in aparte processes. De JIT output opslaan zou nuttig kunnen zijn, mar dan alleen als je veelvuldig dezelfde handelingen doet. Maar aangezien je alles toch realtime optimized is opslaan overbodig.
Niet. Java is een 3rd generation language. Op den duur gaan die er allemaal uit. Hoe het gaat worden wordt een beetje aangegeven door bv Bizztalk server en Office XP developer: dmv diagrammen teken je de flow en de events in je programmatuur, of beter: je tekent de functionaliteit in de vorm van flow control en events. Dan implementeer je NU nog die events in 3rd generation language (office xp developer) maar in bizztalk server bv genereert de server zelf de XML parameters voor de engine. Programmeren hoeft niet meer.
Alles inkloppen is in feite een raar iets: kost erg veel tijd, levert erg veel fouten op en is erg complex. De komende jaren zal er een verschuiving plaatsvinden naar talen die expressief veel beter zijn. En face it: Cobol is erg goed in het kort opschrijven van wat er gedaan moet worden. Wil je dat doen in 3GL's dan ben je meer tijd kwijt. Het is het lot van elke 3GL op den duur, het hangt af van de grootte van de groep fetisjisten hoelang een taal het nog uithoudt. Tenslotte zijn er nog steeds mensen die het fijn vinden om in assembler te programmeren.
Klopt. Maar dat is de tand des tijds. Software heeft net als elk product een lifecycle. Is die ten einde dan is het einde verhaal, vervangen. Tuurlijk zijn er mensen die vast blijven houden aan oude spullen, net zoals er mensen zullen blijven die de DOS versie van Exact blijven gebruiken zullen er mensen blijven die in oude auto's rond rijden. Maar het blijven uitzonderingen. En deprecated is niet ambigu: 'it's dead, get over it': pas aan of blijf met oude troep werken.
De les die .NET en de CLR leert is dat Java-p en java-t niet verbonden KUNNEN blijven. En Rational Rose, die de java-t compiler voor .NET gaat maken bewijst ook dat het beter is die 2 zaken los te laten. Sun echter houdt vast aan de koppeling want het is de enige manier om macht te houden over de gebruiker van java-t, maar ironisch genoeg is het ook de enige levensader van java-t: zodra java-t losgelaten wordt van java-p is java-t dead, en java-p al helemaal. Het wordt dan 'just another 3GL language', en daar zijn er al zoveel van (python, VB, C++, Pascal/delphi etc etc).Goed, dat was nogal een lijst he? Ik kan nog wel even doorgaan, maar helaas heb ik ook geen nachten de tijd
Als je de .NET documentatie doorneemt, zie je ook dat er een erg open architectuur is mbt native api/platform calling, het werken met win32 components etc. Java heeft dat niet, althans niet zo open.
Ik denk dat java-t in .NET wel succesvol zal zijn en dat (IMHO) zal blijken dat java-t mbv .NET beter zal functioneren (lees: naar de developer toe krachtiger zal zijn) dan met een native JVM.
over 5 a 7 jaar hoop ik toch echt niet dat men nog 3GL's gebruikt voor het schrijven van software
Wellicht voor low level zaken, maar zeker niet voor de bulk. Dat zal lijmcode worden, veelal gegenereerd door tools, die objects aan elkaar knoopt. Lijm + objects functioneren weer als object, en voila Generatoren van code, daar gaan we naar toe. Zitten we nu mbv compilers (generatoren van assembler) in 3GL die generatoren te sturen, ik denk dat binnen een aantal jaren de generatoren voor 3GL's meer en meer de overhand krijgen. Immers: het blijft implementeren van functionaliteit en wat een developer doet is een afbeelding maken van de functionaliteit op de computer, zodat de computer begrijpt hoe de functionaliteit werkt. Wat je wilt is een zo makkelijk mogelijke manier om die afbeelding te maken. Het ultieme in die situatie is je functionele beschrijving in leesbare taal gebruiken, dus een generator die dat begrijpt is wat je uiteindelijk wilt. Als je daar naar kijkt zijn 3GL's inmens primitief en cryptisch en is er niet 1 2 3 een verband te zien tussen code en functionaliteit. Slimmere generatoren die omschrijvingen van de functionaliteit die dichter bij de oorspronkelijke leesbare tekst staan, kunnen behappen zijn de toekomst. Hoe naar dat wellicht ook klinkt
Das beter . . Als ik de lengte van jouw post zie belooft dat niet veel goeds .
Ik was trouwens nog 1 belangrijk punt vergeten waar vast veel mensen over vallen:
* Methode parameters zouden standaard final moeten zijn (Gelukkig kent Java uberhaupt al geen out parameters).
De rest van je reacties over het Java Platform komt later. Ik moet eerst ff weg .
.Hehe
. Als ik de lengte van jouw post zie belooft dat niet veel goeds .Ik zie het punt niet helemaal waarom dit een argument voor een andere benadering van primitieve typen zou moeten zijn. Er zijn al klassen in java.lang die precies doen wat jij zegt. Door de klassen Integer, Long, Double, Float etc final te verklaren kunnen ze niet meer uitgebreid worden. Probleem opgelost. Helaas worden deze klassen dus niet gebruikt vanwege performance redenen (wat waarschijnlijk dus maar goed is ook) maar toch is het uitermate onprettig. Auto-boxing van C# vind ik eerlijk gezegd ook geen goed alternatief, dan doe ik het nog liever zelf. Dit auto-boxing zou wel eens hele ondoorzichtige performance problemen op kunnen gaan leveren.
Qua functionaliteit inderdaad wel, qua implementatie absoluut niet. Er wordt geen code gegeneerd voor elk type parameter, het zijn dus geen 'templates'.
Mee eens, maar ze dragen wel zeer sterk bij aan de prettige werking van de taal. Als er geen generics zijn moet je voortdurend kiezen tussen twee alternatieven die je eigenlijk allebei niet wilt: generieke klassen met casts of voor elk type een andere verzameling. Samen met het ontbreken van covariante return typen was dit werkelijk een nacht-merrie.
Mee eens, het punt is echter dat door de zeer drastische inperking van de hoeveelheid typewerk generics enorm bijdragen aan het ontwikkelen van generieke code. Vroeger offerde ik regelmatig vele regels op om casts te vermijden. Dat is nu niet meer nodig. Uiteraard levert dit theoretisch geen verrijking op, maar fijn is het wel.
Dit is ook 1 van de redenen geweest waarom de JSR een andere aanpak heeft gekozen. Als ik het goed begrepen heb is het de bedoeling dat C# vrijwel hetzelfde systeem gaat bevatten.
Maar dragen wel sterk bij aan de onderhoudbaarheid van de code.
Enigszins mee eens, maar toch ook weer niet helemaal. Uiteraard zouden constanten allereerst type-safe moeten zijn, maar het hoofdpunt is dat je op deze manier taal-technisch aan kunt duiden wat het doel is van de variabele. Final variabelen zijn niet per definitie bedoeld als constanten (wel, dat ligt er uiteraard aan wat je onder een constante verstaat).
Ik was trouwens nog 1 belangrijk punt vergeten waar vast veel mensen over vallen:
* Methode parameters zouden standaard final moeten zijn (Gelukkig kent Java uberhaupt al geen out parameters).
Uiteraard, zo implementeer ik enums ook altijd. Het punt is echter dat het gros van de programmeurs dit niet doet (naar voorbeeld van de Java API). Wellicht dat het daarom een onverstandige keuze is geweest om er geen aparte taal-constructie voor te maken. Uiteraard is die taal-technisch gezien absoluut overbodig en misschien zelfs lelijk. In de praktijk kan het misschien net de stap zijn waardoor mensen 'int enums' gaat vermijden.
Hoezo? Ik zie niet in waarom Java deze filosofie zou moeten hebben?
Als je vanuit een sub class de super constructor aanroept krijgt 'this' een instantie van de klasse van de subclass. In de super klasse is 'this' ook altijd van het type van de subklasse. Als je gewoon vanuit een methode de constructor van een klasse aanroept die ook nog extenties heeft, is dat geen enkel punt. Je krijgt dan gewoon een instatie van die klasse.
Ik vind dat een programma voldoet aan een bepaald type. Hij kan namelijk opgestart worden. Dit gebeurt nu door een static main methode, wat een conventie is. Door de main methode geef je aan dat deze klasse gestart kan worden als een applicatie. Voor dergelijke aanduidingen zijn nu echter juist interfaces uitgevonden! Via een interface (en de nodige methoden daarin) kan je op een standaard OO manier aangeven dat iets een applicatie is. Dat vind ik persoonlijk een stuk mooier.
Dat hoeft niet percee. Er kan gewoon in java.lang een interface Application opgenomen worden. Deze interface moet geimplementeerd worden door een applicatie. Dit komt in feite op hetzelfe systeem neer als bij Applets en Servlets.
De rest van je reacties over het Java Platform komt later. Ik moet eerst ff weg
.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
is die gare discussie van jullie nou nog niet afgelopen? kom op heej, wat moet de t.net server wel niet denken van al die gigantische teksten
.edit: oh ik zie dat jullie al het punt hebben bereikt waarop jullie elkaar niet meer 'uitschelden'
.edit: oh ik zie dat jullie al het punt hebben bereikt waarop jullie elkaar niet meer 'uitschelden'
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
zie het als een got benchmark
De discussie begint pas net interressant te worden op naar de 300 reactie's
De discussie begint pas net interressant te worden
op naar de 300 reactie's
code:
1
2
3
4
5
6
7
| idletime t.net servers normaal: 70% discussie*: 1% *) de discussie in kwestie gaat tussen mbravenboer en otis, over de plus en minpunten van Java (en C) |
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het is gewwon onzinnig om ellenlang te discussieren over programmeertalen, elke taal heeft zijn voor- en nadelen! Java is bijv. heel mooi voor os-onafhankelijke niet of nauwelijks GUI georienteerde programma's of applets, terwijl C++ en Delphi bijvoorbeeld veel krachtiger zijn m.b.t. GUI-ontwerp en performance. Dan hebben we nog functionele programeertalen die m.b.t. AI ver boven Java, C++ en Delphi uitsteken. Aan de andere kant hebben die functionele talen (zoals Prolog) ook hun beperkingen m.b.t. GUI, complexiteit etc.Op vrijdag 31 augustus 2001 16:20 schreef OiSyN het volgende:
code:
DE ideale taal en development environment die voor alle soorten toepassingen geschikt is bestaat eenvoudig niet... Het is onzin dat Java C++ verslaat, beide zullen naast elkaar blijven bestaan, hooguit de vorm van een van beide of beide zal veranderen...
Cogito Ergo Credo
Mag ik even?!
Paar puntjes
• Java is een veel nettere taal dan C++. De standaard C++ is verdwenen, er zijn te veel "toevoegingen" in de syntax gekomen in de loop der tijden (denk bijv. aan namespaces) wat de portabiliteit niet ten goede komt.
• De syntax van C++ is in opzet compacter (vind ik persoonlijk mooier).
• De OO van C++ is verder doorgevoerd. (denk bijv. aan multiple inheritance) Dat soort functionaliteit mis je in Java echter niet als je C++ niet gewend ben.
• De snelheid van Java zal alleen maar toenemen, de toekomst zal het leren of het voor real-time applicaties geschikt gaat worden
• Tot nog toe is C++ een taal die in elke laag van een PC-systeem tot zijn recht kan komen,
• Deze discussie is een welles-nietes verhaal geworden Laten we daar maar dus mee ophouden
Daarmee bedoel ik vooral mbravenboer, Otis en wasigh (alfabetische volgorde, expres).
Het komt er op neer dat iedereen zijn eigen voorkeur heeft. Je kunt ook een discussie gaan voeren of een Ferrari beter is dan een Lamborghini. Dat is allemaal zo betrekkelijk dat de discussie een smaak-discussie wordt, en over smaak valt niet te twisten zoals wij allemaal donders goed weten
Mijn voorstel is
kiss and make up
Paar puntjes
• Java is een veel nettere taal dan C++. De standaard C++ is verdwenen, er zijn te veel "toevoegingen" in de syntax gekomen in de loop der tijden (denk bijv. aan namespaces) wat de portabiliteit niet ten goede komt.
• De syntax van C++ is in opzet compacter (vind ik persoonlijk mooier).
• De OO van C++ is verder doorgevoerd. (denk bijv. aan multiple inheritance) Dat soort functionaliteit mis je in Java echter niet als je C++ niet gewend ben.
• De snelheid van Java zal alleen maar toenemen, de toekomst zal het leren of het voor real-time applicaties geschikt gaat worden
• Tot nog toe is C++ een taal die in elke laag van een PC-systeem tot zijn recht kan komen,
• Deze discussie is een welles-nietes verhaal geworden Laten we daar maar dus mee ophouden
Daarmee bedoel ik vooral mbravenboer, Otis en wasigh (alfabetische volgorde, expres).
Het komt er op neer dat iedereen zijn eigen voorkeur heeft. Je kunt ook een discussie gaan voeren of een Ferrari beter is dan een Lamborghini. Dat is allemaal zo betrekkelijk dat de discussie een smaak-discussie wordt, en over smaak valt niet te twisten zoals wij allemaal donders goed weten
Mijn voorstel is
kiss and make up
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Verwijderd
/me heeft nog geen FOX in de discussie langs zien komen....
De ulitmate gui-toolkit al zeg ik het zelf...
www.fox-toolkit.org
De ulitmate gui-toolkit al zeg ik het zelf...
www.fox-toolkit.org
/u/3106/crop601874b34ff83_cropped.png?f=community)
Verwijderd
Beetje oftopic-ish... maar een paar kleine correcties Heb je het const voorvoegsel gemist? C++ heeft wel constanten. Kan gerust const int whatever = 1 zeggen. #define is AFAIK niet obsolete. Is deel van de preprocessor die van C is meegenomen. Compleet met #ifdef stuff etc.
#define is inderdaad niet 'the way' voor constanten.
That aside. Enum is verder ook leuk omdat de betere compilers ook warnings kunnen geven als je niet de hele enum range behandeld in een switch.
Discussie loopt wel leuk afgezien van de occasional welles/nietes geemmer
Vind ik eigenlijk niet. Hangt er een beetje vanaf hoe je dermee omgaat. Door op de juiste punten typedefs toe te passen hou je het geheel lekker overzichtelijk. En een andere container gebruiken is daarna helemaal peanuts.
Uhm??
Heb je het const voorvoegsel gemist? C++ heeft wel constanten. Kan gerust const int whatever = 1 zeggen. #define is AFAIK niet obsolete. Is deel van de preprocessor die van C is meegenomen. Compleet met #ifdef stuff etc.#define is inderdaad niet 'the way' voor constanten.
That aside. Enum is verder ook leuk omdat de betere compilers ook warnings kunnen geven als je niet de hele enum range behandeld in een switch.
Deel programming style, deel luiheid (gok ik) en het kan noodzakelijk zijn voor inlining.
Ik niet volg niet? Zou het eerder omgekeerd doen. Enums zijn leuk voor typesafe constanten en variabelen die alleen waarden uit de enum mogen hebben. Laat ik hier wel bij zeggen dat sommige compilers hier niet zo netjes mee omspringen.
Je kunt inderdaad zonder. Maar in sommige situaties zijn ze iets handiger (vind ik) zie ook mijn opmerking hierboven. Verder is het minder typen dan tig #defines's of const int's.
Discussie loopt wel leuk afgezien van de occasional welles/nietes geemmer
Ondertussen gaat de discussie meer over technische, vrij principiele voor of nadelen van Java. Het is absoluut geen krachtmeting tussen twee talen.
Volwassen he?
.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Uiteraard, altijd leuk als mensen meedoen.
</li>
Dit valt onder "mag ik mijn mening even verkondigen"
. Ik ben het wel met je eens, maar dat doet er niet toe.Dat vind ik wel een leuke opinie. Ik vraag me af of ik het daar mee eens moet zijn. Ik denk het niet eigenlijk
. Multiple inheritance van klassen is een zeer discutabel punt waar iedereen een andere mening over heeft. Feit is echter wel dat het complexiteit veroorzaakt. Java heeft multiple inheritance van interfaces. C# heeft precies dezelfde keuze gemaakt en dat geeft denk ik toch minstens aan dat de ontwikkelaars van die taal de gemaakte keuzes bij Java ondersteunen.Vind ik wel meevallen. Na mijn verhaal over de negatieve aspecten van Java, is Otis daar goed op in gegaan. Daar heb ik weer op gereageerd zonder dat dit een welles nietes discussie is geworden. Het is een interessante discussie over de keuzes die bij Java genomen zijn.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Verwijderd
typedefs mogen strict genomen van straustrupp ook nietOp vrijdag 31 augustus 2001 17:12 schreef izniegoed het volgende:
Beetje oftopic-ish... maar een paar kleine correcties
[templates suck volgens otis]
Vind ik eigenlijk niet. Hangt er een beetje vanaf hoe je dermee omgaat. Door op de juiste punten typedefs toe te passen hou je het geheel lekker overzichtelijk. En een andere container gebruiken is daarna helemaal peanuts.
Maar waar ik op doelde was: templates genereren code, maar welke is pas duidelijk zodra je de templates doorneemt. Dat kan lastig zijn (idem voor operator overloads). Te pas en te onpas gebruiken kan leesbaarheid verlagend zijn.
*oef*[voor constantes gebruik je enums in C++]
Uhm??
#define is inderdaad niet 'the way' voor constanten.
inderdaad.
ik zat te slapen. #define is volgens straustrupp wel obsolete overigens, daar het bv macro's in de hand werkt (yuck) en constante definities op z'n 'C'-s.Als je typesafe constantes toelaat heb je geen enums nodig, want alle constante's hebben al een type. Enums zijn dan alleen 'handig' voor rijtjes. Meer niet.
Verwijderd
Hieruit concludeer ik dat jij de discussie wilt stoppen, puur en alleen omdat jij er geen nut inziet en omdat jij het niet interessant vindt.
This proves my point.
Ik kan nu alle FAQs wel voor je opnoemen maar daar zit niemand op te wachten. In short: als jij de discussie niet interessant vindt dan doe je och gewoon niet mee? Sim-pel.
rot op man, een Lamborghini heeft dus echt wel meer PK'tjes dan zo'n zielig ferraritje, bovendien zijn ze nog mooier ook
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Over het algemeen is het gebrek aan ervarenheid en kennis die de zogenaamde nadelen van een platform veroorzaken. Met behulp van de juist bibliotheken kan je in C++ prachtige OS-onafhankelijke GUIs schrijven. Met behulp van voldoende kennis en ervaring kan je met Swing zeer goede userinterfaces schrijven in Java. Dat vrijwel alle userinterfaces in Java brak zijn wordt veroorzaakt door:
1. Gebruik van AWT
2. Onvoldoende kennis bij gebruik van Swing.
Diegene waarop je reageert deed helemaal geen uitspraak over voor en nadelen van talen. Hij beweerde dat C++ en Java voor een groot deel in het dezelfde ontwikel-domein voorkomen. Misschien heeft hij daar wel gelijk in.
Ik begrijp niet dat de geachte lezers dit nog als een dom welles nietes verhaal ervaren. In het begin is er nogal een oninteressant gezeur ontstaan tussen Otis/Wasigh/mij maar daarna zijn er enkele reacties geweest waarin een duidelijke technische bespreking van Java is geweest. Dat jij die niet interessant vind, vind ik weer niet interessant
.Ik denk overigens dat je niemand in deze thread hebt horen beweren dat of C++ of Java de ultieme taal is zonder voor- of nadelen. De opmerkingen die je daarom maakt over kortzichtigheid vallen daarom volgens mij een beetje in de categorie 'standaard wijze mannen opmerkingen', zoals je die ook vaak tegenkomt op de front-page van Tweakers.net.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment