DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
C++
Maar Java schijnt technisch wat beter in elkaar te zitten, of zoiets dergelijks.
Geen idee, zei mijn vader.
Maar Java schijnt technisch wat beter in elkaar te zitten, of zoiets dergelijks.
Geen idee, zei mijn vader.
Waarom zet je er bij C# nog een Console.Readline() achter?quote:Op maandag 29 mei 2006 02:21 schreef wipes66 het volgende:
Java
[ code verwijderd ]
c++
[ code verwijderd ]
c#
[ code verwijderd ]
Pascal
[ code verwijderd ]
php
[ code verwijderd ]
Ik ben alleen bekend met php, maar zo op het eerste gezicht lijkt java toch nog het meeste op php
Op zondag 28 oktober 2007 01:07 schreef clumsy_clown het volgende:
Jump daarentegen, is wáy minder braaf en lief dan hij lijkt
«shmoop|dingen» jawel, jij bent Superjump
Jump daarentegen, is wáy minder braaf en lief dan hij lijkt
«shmoop|dingen» jawel, jij bent Superjump
Wel eens van het Mono project gehoord..? http://www.mono-project.com/Main_Pagequote:Op zondag 28 mei 2006 18:30 schreef Jump het volgende:
C# heeft het nadeel dat je het framework moet geïnstalleerd hebben. Eenmaal Vista uit is, zal dat geen probleem zijn, daar zal het standaard aanwezig zijn. Het voordeel, vind ik dan, is dat het makkelijk aan te leren is. Makkelijker als C++ ofzo.
En een boek is een must, vind je vaak meer uitleg in dan online. En sneller de juiste uitleg.
Ajax heeft vaak een server-side component, dit kan prima in J2EEquote:Op maandag 29 mei 2006 12:06 schreef Nietmachine het volgende:
[..]
Java en Ajax hebben niets met elkaar te maken. Ajax maakt gebruik van Javascript, wat iets anders is dan Java.
Dat is niet de reden dat een JiT compiler sneller kan zijn dan native code. De compile slag zorgt nl. altijd voor vertraging. De reden dat een JiT-compiler (in theorie( sneller kan zijn, is dat de meeste native gecompileerde code niet geoptimaliseerd is voor de processor die je gebruik, omdat het op een hele reeks machines moet draaien. Veel code is b.v. nog gecompileerd voor een 386. Een JiT-compiler kan wel optimaliseren voor de specifieke CPU waar op dat moment op gedraait wordt, omdat deze native code toch alleen door die ene machine hoeft te worden uitgevoerd.quote:In theorie ja, Microsoft beweert dat ze met hun .NET framework sneller zijn dan normale programma's daar code pas gecompiled wordt als het echt nodig is.
Bovendien kan een virtual-machine een draaiende applicatie analyseren en runtime optimalisaties uitvoeren.
Klok, klepel.quote:Java taal en dan compilen naar native code gaat niet werken. Java moet een VM hebben vanwege b.v. de garbage collection. Dat Java traag is komt omdat Java dan weer niet gebruikt wordt waar het echt voor bedoelt wordt en waar z'n krachten liggen, namelijk bij server side applicaties.
Voor GC heb je echt geen VM nodig, GC is een feature van de runtime. Zo komt er b.v. in Objective-C voor volgende versie van OSX ook support voor GC. En er zijn gewoon garbage collectors beschikbaar voor C en C++.
It is impossible to live a pleasant life without living wisely and well and justly.
And it is impossible to live wisely and well and justly without living a pleasant life.
And it is impossible to live wisely and well and justly without living a pleasant life.
Klopt. Ik ging meer uit dat de poster bedoelde dat je Java gebruikt in AJAX, wat dus niet het geval is daar je Javascript gebruikt. En een aardig aantal mensen denkt nog altijd Java == Javascript . Hoewel niet echt aanwezig in dit topic denk ik .quote:Op maandag 29 mei 2006 12:57 schreef Aaargh! het volgende:
[..]
Ajax heeft vaak een server-side component, dit kan prima in J2EE
Klopt klopt. Maar zover ik het me herinner wat ik toen gelezen heb zegt MS dat .NET sneller is / kan zijn vooral komt door wat ik in m'n eerdere post zei. Daar komt dit natuurlijk nog bij.quote:[..]
Dat is niet de reden dat een JiT compiler sneller kan zijn dan native code. De compile slag zorgt nl. altijd voor vertraging. De reden dat een JiT-compiler (in theorie( sneller kan zijn, is dat de meeste native gecompileerde code niet geoptimaliseerd is voor de processor die je gebruik, omdat het op een hele reeks machines moet draaien. Veel code is b.v. nog gecompileerd voor een 386. Een JiT-compiler kan wel optimaliseren voor de specifieke CPU waar op dat moment op gedraait wordt, omdat deze native code toch alleen door die ene machine hoeft te worden uitgevoerd.
Bovendien kan een virtual-machine een draaiende applicatie analyseren en runtime optimalisaties uitvoeren.
Klopt, klepel verhaal valt wel mee .quote:[..]
Klok, klepel.
Voor GC heb je echt geen VM nodig, GC is een feature van de runtime. Zo komt er b.v. in Objective-C voor volgende versie van OSX ook support voor GC. En er zijn gewoon garbage collectors beschikbaar voor C en C++.
Ik wist niet echt dat je Java wel degelijk echt naar x86 code kunt compilen. Maar dan nog vraag ik me af wat het voor nut heeft. GC heb je dan niet meer, of je moet er alsnog weer wat bij gaan draaien zodat dat de GC verzorgt of je moet het zelf gaan regelen in je programma's. En ik weet niet of dat kan? Goede "destructors" heeft Java iig al niet echt.
Daarnaast smijt je een GC weg die meer doet dan alleen oude objecten wegsmijten, hij optimaliseerd b.v. ook het spul wat nog in het geheugen blijft.
GC's voor C en C++ snap ik ook niet, daar zijn deze talen niet voor bedoeld geweest in 1e instantie en als je je niet druk wilt maken om geheugen management moet je in Java of .NET gaan coden imo .
Over die GC's in C en C++ en het compilen van Java naar nativa x86 code weet ik verder te weinig om nog wat zinnigs over te zeggen wat ik ook zeker weet .
Een dag niet gelachen is een dag niet geleefd.
Ik zou gewoon voor Java gaan, goed te leren, en is in principe gewoon C++ maar zonder die ellende van geheugenmanagement.
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Je hebt altijd GC nodig, er is geen manier om dit handmatig te doen voor Java objecten. (Java objecten die een wrapper vormen om JNI objecten hebben vaak wel een dispose() methode oid, maar die is alleen om het native object op te ruimen, niet de java wrapper class)quote:Op maandag 29 mei 2006 14:05 schreef Nietmachine het volgende:
Klopt, klepel verhaal valt wel mee .
Ik wist niet echt dat je Java wel degelijk echt naar x86 code kunt compilen. Maar dan nog vraag ik me af wat het voor nut heeft. GC heb je dan niet meer, of je moet er alsnog weer wat bij gaan draaien zodat dat de GC verzorgt of je moet het zelf gaan regelen in je programma's. En ik weet niet of dat kan? Goede "destructors" heeft Java iig al niet echt.
Als je naar native compiled moet er altijd een runtime onder die de GC doet. Maar er moet zowieso een runtime library bij die een heleboel andere dingen afhandeld.
Die functionaliteit zit dan ook in de native runtimequote:Daarnaast smijt je een GC weg die meer doet dan alleen oude objecten wegsmijten, hij optimaliseerd b.v. ook het spul wat nog in het geheugen blijft.
Hoezo ? Vind ik een vreemde redenatie, er zijn een heleboel redenen om in C/C++/ObjC te programmeren, het feit dat je zelf geheugenbeheer mag/moet doen is maar in een HEEL klein deel v/d gevallen een reden om voor C/C++ te kiezen. Meestal is dit alleen maar lastig, de kans op bugs is erg groot. Het is alleen zinvol als je precies controle wilt hebben over het moment waarop je geheugen vrijgegeven word, en dat is eigenlijk alleen in realtime toepassingen.quote:GC's voor C en C++ snap ik ook niet, daar zijn deze talen niet voor bedoeld geweest in 1e instantie en als je je niet druk wilt maken om geheugen management moet je in Java of .NET gaan coden imo .
It is impossible to live a pleasant life without living wisely and well and justly.
And it is impossible to live wisely and well and justly without living a pleasant life.
And it is impossible to live wisely and well and justly without living a pleasant life.
waarom gaat TS gewoon niet assembler doen
Het nationaal product is hetzelfde als een taart waar uiteraard iedereen recht op heeft, als overheden met geld smijten heet het investeren en als bedrijven investeren heet het een sprinkhanenplaag. McCarthy
hehe assembler, dat vindt ik toch een stuk moeilijker dan c..quote:Op maandag 29 mei 2006 17:12 schreef McCarthy het volgende:
waarom gaat TS gewoon niet assembler doen
add, move etc
Java is C++ met een condoom, zei iemand laatst tegen mij in de kroeg.quote:Op maandag 29 mei 2006 12:23 schreef vintrax het volgende:
C++
Maar Java schijnt technisch wat beter in elkaar te zitten, of zoiets dergelijks.
Geen idee, zei mijn vader.
Zodat het venster niet onmiddelijk verdwijntquote:Op maandag 29 mei 2006 12:25 schreef Jump het volgende:
[..]
Waarom zet je er bij C# nog een Console.Readline() achter?
dead
Over programmeren praten in de kroegquote:Op maandag 29 mei 2006 20:58 schreef thabit het volgende:
[..]
Java is C++ met een condoom, zei iemand laatst tegen mij in de kroeg.
This message is intended for the addressee shown. It contains information that is confidential and protected from disclosure. The contents of this message do not necessarily represent the views or policies of myself.
Praten over programmeren met bier erbij is beter dan praten over programmeren zonder bier erbij.quote:Op donderdag 1 juni 2006 19:45 schreef existenz het volgende:
[..]
Over programmeren praten in de kroeg
PHP -> Perl -> C -> C++ -> Java
Done...
Maar na stap 3, als je er gevoel voor hebt, kan je programmeren, taal doet er dan niet meer toe, alleen de paar weken om er bekend mee te worden...
Maar eigenlijk is dit de verkeerde kant op... PHP, Perl, C++ zijn hogere talen, als je ECHT wil weten wat je doet kan je beter lager beginnen...
Mijn verloop: Pascal/ASM -> C/ASM -> c++ -> Perl/PHP/Java
Done...
Maar na stap 3, als je er gevoel voor hebt, kan je programmeren, taal doet er dan niet meer toe, alleen de paar weken om er bekend mee te worden...
Maar eigenlijk is dit de verkeerde kant op... PHP, Perl, C++ zijn hogere talen, als je ECHT wil weten wat je doet kan je beter lager beginnen...
Mijn verloop: Pascal/ASM -> C/ASM -> c++ -> Perl/PHP/Java
"I contend that we are both atheists. I just believe in one fewer god than you do.
When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours."
[Stephen Roberts]
When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours."
[Stephen Roberts]
Over programmeren praten wil je inderdaad niet doen terwijl je nuchter bent.quote:Op donderdag 1 juni 2006 19:56 schreef Tijn het volgende:
[..]
Praten over programmeren met bier erbij is beter dan praten over programmeren zonder bier erbij.
Het is niet 'een soort' Object Pascal. Object Pascal was de naam van de programmeertaal die Delphi gebruikt. In de nieuwere versies heet de taal ook gewoon Delphi (is nog steeds dezelfde programmeertaal).quote:Op maandag 29 mei 2006 01:27 schreef McCarthy het volgende:
ik denk minder dicht op de hardware
ken het ook niet zo goed
is een soort object pascal is ik het goed begrijp
Het idee achter Delphi was een overzichtelijke programmeertaal maken. De syntaxis is echt duidelijk, de datatypen zijn minder strikt en je hoeft geen honderden #include's te doen voordat je kan beginnen met schrijven.
Anders wat vaak door C-programmeurs wordt beweerd is Delphi een complete programmeertaal. Er is niks wat wel in C en niet in Delphi kan. In Delphi is het over het algemeen zelfs makkelijker door de overzichtelijke syntaxis.
Voordeel van Delphi over Java is dat de executables die Delphi genereert veel minder cpu-intensief zijn dan Java apps.
Heeft Fok! verlaten, jeweetoch.
gaat ook een stuk makkelijker enzoquote:Op donderdag 1 juni 2006 19:56 schreef Tijn het volgende:
[..]
Praten over programmeren met bier erbij is beter dan praten over programmeren zonder bier erbij.
- Als een wijs man een goede reden heeft het woord te voeren houdt hij moeiteloos een goed betoog.
- You can say that again
- You can say that again
Men ik wil het ook leren, maar dat kost zoveel tijd. Lectuur genoeg in de kast...
- Als een wijs man een goede reden heeft het woord te voeren houdt hij moeiteloos een goed betoog.
- You can say that again
- You can say that again
|
|
