:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
:strip_exif()/u/19853/Goku1.gif?f=community)
Ik zie programmeren als een functionerende applicatie ontwikkelen, en ben het dan ook niet met jou eens.
Als iemand een programma wil hebben wat een mooie 7segmenten output (even voor microcontrollers op een wekker, embedded systems, meer mijn richting), dan kan ik dat ontwikkelen met
if(x=0) { seg_A = true; seg_B = true; }
if(x=1) { seg_A = false; seg_B = true; }
Ik kan dat echter ook met een switch/case doen, veel netter. En als ik echt wil klooien met algoritmes, dan kan ik dat zelfs doen met een karnaugh-diagram en vervolgens
seg_B = !(x&0x02)
Dat laatste vind ik een algoritme, maximale performance eruit halen. Maar is dat altijd nodig? Nee. Iedereen die een ledje kan laten knipperen (electronica's Hello World), kan het goed genoeg maken. Bitfucken, switch/case of desnoods een if/else, ze krijgen het werkend.
Voor programmeertechnieken geld hetzelfde. Ik vind bitfucken erg leuk, maar je *hoeft* het niet te gebruiken. Met if, while en de juiste library functies aanroepen kun je het meeste wel implementeren. Tuurlijk is het handig om classes te gebruiken, overerving e.d. te gebruiken, maar niet altijd, en zonder dat kun je ook prima programmeren. Afhankelijk van je applicatie is dat een marteling, maar dat is nu even niet het punt
Computersystemen? Vooruit, maar daarvoor heb je niet veel meer dan basiskennis nodig. Als je iets wil opslaan, dan kun je dat in een file doen. Nouja, je moet dan weten wat een file is. Tegenwoordig weten teveel mensen niet eens meer wat een pointer is en hoe ze die kunnen gebruiken. Ja, je moet er wel wat van weten, nee, niet alles. Basiskennis is voldoende.
Programmeertalen? Wat bedoel je daar precies mee? Ik moet kennis hebben van andere programmeertalen voordat ik iets ontwikkel? Je hebt daarin gedeeltelijk gelijk, omdat voor sommige applicaties het makkelijker is om een specifieke programmeertaal te gebruiken. Maar dat maakt het niet noodzakelijk om een andere programmeertaal te kennen. Ikzelf heb pas sinds kort fatsoenlijk met VB leren programmeren, maar met C/C++ kan ik, ongeacht de (on)gebruiksvriendelijkheid van de compiler, toch nog sneller programmeren. Maar daar weet ik van dat het aan mij ligt
Wiskunde? Ik nodig je graag uit om bij sommige HBO-opleidingen te komen kijken. Wiskunde wordt, tot mijn grote ergenis overigens, niet standaard meer op fatsoenlijk niveau gegeven op de opleiding. Het heeft nadelen als je met beeldvorming werkt (2d, 3d, audio, externe inputs bij embedded, etc). Maar als je een CMS wil opzetten boeit het totaal niks. Niet veel meer dan if while in ieder geval.
Ik ben het er mee eens dat kennis van de punten die je noemt weldegelijk erg handig is, maar het is geen harde eis zoals jij aangeeft. Zonder dat kun je ook programmeren. Goed? Nouja, je kunt een functionerend programma opzetten binnen reeele tijd. Als ik kijk naar de lichting die van mijn opleiding & jaar af gaan komen, kun je daar al best tevreden mee zijn
Mijn kritieke mening is, onder andere over Java, dat het teveel library's heeft die de leercurve van het programmeren wegnemen. PHP is in dat opzicht, wat mij betreft, nog een stapje erger: je leert er geen algoritmes (meer) mee. Ik vind dat zelf een van de interessantere dingen aan programmeren. Niet hard noodzakelijk, maar soms is het toch verdomd handig als je library je in de steek laat.
En zoals roy-t in "Is java de grootste vloek in de informat..." aangeeft: Memory leak is een bug die je moet fixen, niet afvangen. Voor mijn gevoel (ik programmeer niet in Java), leren mensen niet meer hoe noodzakelijk het is om naar geheugen te kijken.
In zo'n topic even voor de volledigheid, dit is puur zoals ik het ervaar. Ik heb net 5 jaar programmeerervaring op opleiding(en), maar geen echt interessante programmeerervaring buiten mijn huidige stage.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
/u/112490/crop5821eafeac2b9_cropped.png?f=community)
Ik ben afgestudeerd als licentiaat informatica vorig jaar (= master tegenwoordig). En hoewel de focus lag op java, hebben wij op zijn minst de volgende talen gezien:
Java
C
C#
C++
NesC
Pascall
Smalltalk
Visual basic
Perl
Haskell
een taal die lijkt op haskell maar waar de naam mij van ontschiet, Logo of zoiets...
Eiffel
Cobol
..
Ik vergeet er ongetwijfeld nog enkele. En dan natuurlijk nog XML, html, ...
Zou ik een probleem oplossen in java ipv C? Hangt beetje van het probleem af, maar ja waarschijnlijk. Als dat ding zelf garbage collecting doet en ik geen zorgen moet maken over pointers, waarom niet. Ken ik er daarom niets van? Fout. Geef mij een nieuwe taal en ik ben er ook in 2 dagen mee weg, gewoon omdat we de concepten kennen. Ken ik alle bovenstaande talen in detail? Neen natuurlijk niet, maar ik ken de gebruikte concepten, van de meesten nog wat syntax etc...
Java is goed als programmeertaal qua concepten, goede compilers en omdat je nog niet zo moet bezig zijn met pointers. Eens je dat kent kan je verder gaan.
De achteruitgang van de studenten (in informatica maar ook wel algemeen) ligt eerder in de luiheid van jongeren (ikzelf was zeker geen voorbeel van ijverigheid maar ik leerde mezelf dan wel programmeertalen die ik niet kende, voor school werken was iets anders
).En java is inderdaad niet altijd de optimale taal om dingen in te maken, door zijn traagheid soms. Zoals al vaak gezegd in dit topic. Java is niet de beste taal en ook niet de slechtste. Er is geen beste taal, dat hangt af waar je goed in bent en wat je moet schrijven.
Het artikel gelinked in de openingspost is een zoveelste rant uit de miljarden die op internet te vinden zijn. Constructieve posts maken daarentegen ...
:strip_icc():strip_exif()/u/106218/wc-backbone.jpg?f=community)
:strip_icc():strip_exif()/u/126096/crop580e4f8566fec_cropped.jpeg?f=community)
Sinds .Net3/3.5 loopt .Net toch echt erg voor op java in mijn ogen, ik denk dan vooral vanuit C# maar C# heeft niet eens alle functionaliteiten die IL (*de onderliggende taal van .NET) ondersteund.
Ik heb bij java nog nooit delegates, closures,[unsafe] code blokken met pointers en alles, of props gezien, ook handige toevoegingen als threadpools (ok die kun je ook zelf maken) mis ik. Ik twijfel er nu ook over of ik eigenlijk wel structs in java ken, en ik weet vrij zeker dat je in java niet de layoutkind van je struct kan setten, en zelf kunt aan geven hoe qua geheugen locaties structs worden opgebrouwd. Ook heb ik nog nooit projecten gezien waarbij een deel van het programma hielp met zichzelf compilen. (denk aan apparte compile-projecten en content managers). Ook lijkt .Net wat betreft services veel uitgebreider en zijn er voor Threads veel mooiere contructies dan in Java waar je alleen op een parameterloze manier threads kunt starten waardoor je weer properties moet setten van te voren.
Nu krijg ik waarschijnlijk het argument 'dat kun je zelf maken' wat waarschijnlijk ook wel valide is, aangezien het uiteindelijk allemaal x86 code wordt (of nouja vaak) maar .NET loopt zover ik weet gewoon nu een stuk voor op Java. In java is het veel moeilijker om dichter bij de compiler/computer te komen (dnek aan de handige compiler statements in [] in C#) Misschien dat het met Java7 weer dichter bij elkaar komt.
(verder vind ik C#/.Net over het algemeen wat consistenter dan java, en is de MSDN in mijn ogen beduidend beter dan sun's java documentatie).
@blackangel
Je hebt helemaal gelijk, op de RuG krijgen we iig het eerste jaar absoluut geen informatie over wat een pointer uberhaupt is. Dit komt waarschijnlijk ook mede doordat je in Java geen unsafe code kunt maken (zover ik weet). Imho zou C# een stuk geschikter zijn maar somehow hebben ze op de RuG een soort van Microsoft haat wat er ook echt flink in getrapt wordt hier, (en waar ik ondertussen als ms fanboy een grondige hekel aan begin te krijgen) elke leraar heeft wel weer wat te zeuren op MS, (hoewel vele wel toegeven dat ze liever C# dan Java hadden gegeven
).Ik zou het absoluut niet jammer vinden als ze op de Uni's en HBO's weer Java schrappen en terug gaan naar C++ waar je toch echt veel mee zult moeten werken later (hoewel C++ natuurlijk ook absoluut een rotzooitje is de laatste tijd
) Misschien wordt het is tijd voor een nieuwe high-performance unsafe taal die lekker opgeschoond is (ik weet dat er iets als D++ is maar dat loopt allemaal nog niet zonder industry support.Ons wordt zoals eerder verteld wel memory management geleerd dmv assembly.
Note: waarom is er geen speciaal vak waar je leert debuggen!!! Als je iets vaak doet als programmeur is het wel debuggen, ik durf bijna te zeggen dat je vaker achter de debugger zit dan dat je echt code aan het schrijven bent, dat is mooi te combineren met unit testing wat bij ons nu verstopt wordt in 1 college over OO.
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
C++09, next year in a compiler suite near you!:
(hoewel C++ natuurlijk ook absoluut een rotzooitje is de laatste tijd
[ Voor 4% gewijzigd door .oisyn op 18-12-2008 17:31 ]
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.
Een vak debuggen zou geen kwaad kunnen, hoe vaak ik dat aan iemand heb moeten uitleggen is niet normaal meer 
Java ontwikkelen in Eclipse met printf-debugging, iemand van een jaar of 40 met 10 jaar java-ervaring 
Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
Java ontwikkelen in Eclipse met printf-debugging, iemand van een jaar of 40 met 10 jaar java-ervaring Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
/u/81985/crop566b00b43645a.png?f=community)
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Je weet wel dat dat het probleem is, maar je weet het ook niet zeker?
1.1 en 2.0 zijn idd grote verschillen, maar 3.5 is niets anders dan een extensie op 3.0 die weer een extensie is op 2.0 ...
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
/u/105842/Homer_60x60.png?f=community)
Dat brengt voor de RuG veel gelazer met zich mee; die draaien volledig op Debian Linux.:
[...]
@blackangel
Je hebt helemaal gelijk, op de RuG krijgen we iig het eerste jaar absoluut geen informatie over wat een pointer uberhaupt is. Dit komt waarschijnlijk ook mede doordat je in Java geen unsafe code kunt maken (zover ik weet). Imho zou C# een stuk geschikter zijn maar somehow hebben ze op de RuG een soort van Microsoft haat wat er ook echt flink in getrapt wordt hier, (en waar ik ondertussen als ms fanboy een grondige hekel aan begin te krijgen) elke leraar heeft wel weer wat te zeuren op MS, (hoewel vele wel toegeven dat ze liever C# dan Java hadden gegeven
Read the code, write the code, be the code!
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
Blijkbaar hebben we nog een communicatie-geschil:
Je hebt wizzkids en prutsers, maar ook die 'normale' mensen. Ik vond het alleen nogal raar klinken; alsof de andere 2 groepen niet normaal zijn. Dus op dat vlak zitten we ook op 1 lijn.
Ik zat aan Hogent, III kun je trouwens enkel daar doen. Er zaten echter ook studenten (SV'ers doel ik dan op) die van Brussel, Brugge, etc. kwamen.zolang de bedrijven mij graag zien komen waar ik solliciteer en het een pluspunt vinden dat ik Toegepaste informatica gedaan heb ben ik blij. En ik ben heeeel blij
BTW waar heb jij je studie gedaan, want dat verschilt ook nogal eens per regio.. Ik heb namelijk genoeg diepgang gehad in de meeste vakken imho.
ASSUME makes an ASS out of U and ME
Dat JFileChooser traag was in veel (maar niet alle!) situaties is/was een bekende bug die voor zover ik weet sinds Java 6 Update 10 pas echt verholpen is (met wat verbeteringen in de afgelopen paar jaar). Het ging - als ik mij goed herinner - vooral mis als de start-folder veel zip-bestanden bevatte oid, en dan hoofdzakelijk onder Windows omdat Sun een bepaalde Win32-API op de verkeerde wijze gebruikte.:
[...]
Geen idee wat het nu allemaal is. Ik heb mijn eindwerk met het leuke Java Swing gemaakt en een gewone filechooser dialog tonen (standaard stuff) duurde de eerste keer 5-15 seconden op álle pc's. 4-5 jaar geleden. Sindsdien nog nauwelijks java/swing aangeraakt na deze traumatische ervaring haha
Natuurlijk doet java het goed op supercomputers (cern/ebay) maar (vroeger) toch niet op desktop clientpc's (met swing gui dus, en laat dat nu het meest gebruikte zijn)...
Dat er zoveel mensen denken dat 'java' traag is, zal wel niet zomaar uit de lucht gegrepen zijn...
@oisyn ik heb nergens gezegd dat java traag is, enkel dat de gui traag is (dus swing of whatever)
Overigens heb ik een paar (kleine) tooltjes gemaakt met Swing, en in mijn ervaring doen zich de meeste problemen met trage UI voor als je zaken afhandelt op de event-thread in plaats van via een SwingWorker of een losse Thread ed.
Daarnaast is het natuurlijk een feit dat Sun gewoon een vreemde beslissing heeft genomen door de systeem look- en feel te emuleren ipv de systeem-eigen widgets te gebruiken (zoals SWT bijvoorbeeld doet), die emulatie zorgt voor vertraging (ook omdat het veelal niet via de 2D accelarator gaat, pas sinds Java 6 Update 10).
In tegenstelling tot eerdere posts is Swing NIET deprecated (Sun heeft in Java 6 Update 10 zelfs een nieuwe platformonafhankelijke look-en feel geïntroduceerd.
ik somde een paar feiten op: lambda-calculus-concepten worden ook wel functioneel programmeren genoemd wanneer je dat toepast in programma's (functies zijn 'first-class citizens'). De eerste talen die dit concept ondersteunden waren dynamische programmeertalen. Nu pak ik weer je originele reactie erbij:
Lambda expressions zijn iets heel kenmerkends voor dynamische talen. Zo ongeveer alle dynamische talen ondersteunen lambda-expressies, terwijl het een concept is wat tot voor kort niet voorkwam in statische programmeertalen. Dus jouw opmerking vond ik echt nergens op slaan.
Waarom C# en Java trouwens geen dynamische programmeertalen zouden zijn zou ik niet weten: met reflection enzo kan je run-time de uitgevoerde code veranderen, waarmee het een dynamische programmeertaal is.
offtopic:
The reflections are all wrong
The reflections are all wrong
:strip_icc():strip_exif()/u/85602/ElvisSpace_112.jpg?f=community)
De grootste vloek in de informatica was toch goto? 
Ontopic:
Volgens mij verwordt deze discussie nu voornamelijk een Java vs .net verhaal. Terwijl deze talen imho toch een hele hoop zaken gemeen hebben, en deels met dezelfde ideeën in het achterhoofd zijn ontwikkeld: een heldere object georiënteerde taal, middels bytecode draaiende in een virtual machine met garbage collection, het aanbieden van een uitgebreide collectie libraries voor datastructuren, netwerken, etc etc om direct een multifunctionele taal neer te zetten, het aanpakken van de nadelen van C/C++.
Waar de platformen enigszins in verschillen zijn de nadrukken op platformonafhankelijkheid, het toch kunnen gebruiken van unsafe code en het aantal taalvarianten. Inmiddels zou je ook het licentiemodel als verschil kunnen aanmerken.
Maar goed, er was dus een tijd dat de insteek van deze twee talen helemaal de toekomst leek. (En omdat Java eerder op de markt verscheen is het misschien daardoor in het onderwijs inmiddels meer omarmd dan .net).
Dus. Moeten we de oorzaak van de gevreesde teloorgang misschien meer zoeken in het idee dat informatici begin jaren negentig de verkeerde toekomstvisie hadden?
Edit: En dan bedoel ik dus te zeggen dat het volgens mij niet zozeer om de implementatie gaat, maar om de concepten. Het doel was volgens mij om sneller software te kunnen maken, met minder fouten.
Ontopic:
Volgens mij verwordt deze discussie nu voornamelijk een Java vs .net verhaal. Terwijl deze talen imho toch een hele hoop zaken gemeen hebben, en deels met dezelfde ideeën in het achterhoofd zijn ontwikkeld: een heldere object georiënteerde taal, middels bytecode draaiende in een virtual machine met garbage collection, het aanbieden van een uitgebreide collectie libraries voor datastructuren, netwerken, etc etc om direct een multifunctionele taal neer te zetten, het aanpakken van de nadelen van C/C++.
Waar de platformen enigszins in verschillen zijn de nadrukken op platformonafhankelijkheid, het toch kunnen gebruiken van unsafe code en het aantal taalvarianten. Inmiddels zou je ook het licentiemodel als verschil kunnen aanmerken.
Maar goed, er was dus een tijd dat de insteek van deze twee talen helemaal de toekomst leek. (En omdat Java eerder op de markt verscheen is het misschien daardoor in het onderwijs inmiddels meer omarmd dan .net).
Dus. Moeten we de oorzaak van de gevreesde teloorgang misschien meer zoeken in het idee dat informatici begin jaren negentig de verkeerde toekomstvisie hadden?
Edit: En dan bedoel ik dus te zeggen dat het volgens mij niet zozeer om de implementatie gaat, maar om de concepten. Het doel was volgens mij om sneller software te kunnen maken, met minder fouten.
[ Voor 7% gewijzigd door zwippie op 18-12-2008 20:44 ]
How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.
offtopic:
De grootste vloek is Cobol. "It's not dead yet, it just smells funny." Zal ik morgen even een snippet copy/pasten? Dan wil iedereen direct weer Java programmeren
De grootste vloek is Cobol. "It's not dead yet, it just smells funny." Zal ik morgen even een snippet copy/pasten? Dan wil iedereen direct weer Java programmeren
Ik denk dat een paar pagina's terug de juiste opmerking is gemaakt: we willen dat meer mensen kunnen programmeren (in 1998 werd je met alleen VWO nog aangenomen als programmeur
), dat betekent dat je niet al te selectief kan zijn. En dat betekent weer dat je ook mindere goden moet accepteren als informaticus. De Nederlandse cultuur dat we allemaal manager moeten worden als promotie helpt daar niet bij. Een van de tools die het mogelijk maakte om relatief eenvoudig complexe programma's te schrijven was Java, die hier het zondebok lijkt te worden.
Dus nee, ik denk niet dat de toekomstvisie verkeerd was. Eerder de ambities te hoog. Het echte probleem zat namelijk niet in de techniek, maar in de praktijk van te weinig testen en structuur.
[ Voor 24% gewijzigd door MBV op 18-12-2008 20:52 ]
:strip_icc():strip_exif()/u/7307/images.jpg?f=community)
Roy-t, waarom zou C# volgens jou een geschikter platform zijn om studenten te leren programmeren? Je komt met allemaal argumenten (unsafe code blokken, geheugenindeling van structs, dichter bij de compiler komen) die het leren programmeren alleen maar moeilijker maken in het begin.
Hoe vaak heb je al gesolliciteerd? Zoveel wordt er niet meer gedaan in C++ voorzover ik weet.
offtopic:
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
Onvoorstelbaar!
Als je C, C++ en nog een taal hebt geleerd kan je de meeste imperatieve talen heel snel onder de knie krijgen. Ik heb laatst ook wat gedaan in C#, en met een beetje googlen kom je er wel. En of je nu een diploma hebt met 0 ervaring en een schoolprojectje in C++, of 0 ervaring en een schoolprojectje in Java, dat zal de meeste bedrijven een worst wezen. Zeker uit het HBO ga je direct op cursus, en leren ze je in 3 maanden opnieuw programmeren (bij de grote bedrijven):
Roy-t, waarom zou C# volgens jou een geschikter platform zijn om studenten te leren programmeren? Je komt met allemaal argumenten (unsafe code blokken, geheugenindeling van structs, dichter bij de compiler komen) die het leren programmeren alleen maar moeilijker maken in het begin.
[...]
Hoe vaak heb je al gesolliciteerd? Zoveel wordt er niet meer gedaan in C++ voorzover ik weet.
offtopic:
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
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.
:strip_exif()/u/21687/aaron.gif?f=community)
Algortimes zijn een systematische manier om een bepaald probleem op te lossen. Dat laatste statement kan net zo goed onderdeel zijn van een algoritme als dat eerste stuk. Daarbij gaat je argument imho mank. Kennis gaat niet alleen over toepassingen. Ander begrip van kennis veroorzaakt ook spraakverwarringen. Wij hebben blijkbaar een ander begrip van de term algoritme.
Om deze afwegingen te maken moet je de programmeertechnieken op zijn minst kennen en kunnen toepassen. Als je een brede kennis hebt op dit gebied, dan kun je goed bepalen wanneer je welke techniek toepast. Waardoor je inderdaad martelgangen voorkomt. Ik ben het compleet met je eens wat hierboven staat, maar het is geen argument tegen wat ik stelde.Voor programmeertechnieken geld hetzelfde. Ik vind bitfucken erg leuk, maar je *hoeft* het niet te gebruiken. Met if, while en de juiste library functies aanroepen kun je het meeste wel implementeren. Tuurlijk is het handig om classes te gebruiken, overerving e.d. te gebruiken, maar niet altijd, en zonder dat kun je ook prima programmeren. Afhankelijk van je applicatie is dat een marteling, maar dat is nu even niet het punt
Als je goed wilt kunnen programmeren, moet je mijns inziens de beperkingen van systemen kennen. Dat kan zijn de bandbreedte van een databus of netwerkverbinding. Het begrip van geheugen allocatie en lowlevel dingen die achter de schermen gebeuren, kunnen een hoop problemen verklaren die men vaak tegen komt. Ik ben het met je eens dat het allemaal niet noodzakelijk is, maar het is beter om deze kennis wel te hebben. Je wilt immers dat jouw product van de hoogste kwaliteit is.
Je moet toch de syntax en standaard structuren van een programmeertaal kennen om deze te kunnen gebruiken? Dit bedoel ik letterlijk, lijkt me volkomen terecht.Programmeertalen? Wat bedoel je daar precies mee? Ik moet kennis hebben van andere programmeertalen voordat ik iets ontwikkel? Je hebt daarin gedeeltelijk gelijk, omdat voor sommige applicaties het makkelijker is om een specifieke programmeertaal te gebruiken. Maar dat maakt het niet noodzakelijk om een andere programmeertaal te kennen. Ikzelf heb pas sinds kort fatsoenlijk met VB leren programmeren, maar met C/C++ kan ik, ongeacht de (on)gebruiksvriendelijkheid van de compiler, toch nog sneller programmeren. Maar daar weet ik van dat het aan mij ligt
Mja, komen we weer uit op hetzelfde punt als de kennis over computersystemen. Kennis van wiskunde helpt je complexe problemen sneller oplossen. Als je minder kennis hebt, zul je in de praktijk vaak langer doen over complexe problemen.
Het waren ook geen harde eisen hoorIk ben het er mee eens dat kennis van de punten die je noemt weldegelijk erg handig is, maar het is geen harde eis zoals jij aangeeft. Zonder dat kun je ook programmeren. Goed? Nouja, je kunt een functionerend programma opzetten binnen reeele tijd. Als ik kijk naar de lichting die van mijn opleiding & jaar af gaan komen, kun je daar al best tevreden mee zijn
Gewoon mijn mening en het waarom achter die mening. Ik denk dat we het op veel punten eens zijn.Java is erg uitgebreid, zonder enige andere kennis kun je inderdaad erg eenvoudig de weg kwijt raken. Je hoeft die libraries niet te gebruiken. Java kan een goede tool zijn, maar het wordt nu eenvoudigweg teveel gebruikt om te leren.
Jouw ervaring kan anders zijn dan mijn mening. Ik wil benadrukken: het blijft subjectief
Grofweg gezien wel. Hoe meer verstand je hebt van die punten, hoe beter. Dat betekend wat mij betreft niet dat je zonder die punten ook een functionerende applicatie neer kunt zetten, alleen wordt het uiteindelijk een marteling. Voordat ik C++ kende (wel classes, geen overerving:
[...]
Het waren ook geen harde eisen hoor
), heb ik mijzelf vaak genoeg gepijnigd inderdaad. Maar dat betekend niet dat ik het niet functionerend neer kon zetten.En ik zie dat we een aantal verschillen in begripdefinities hebben. Als ik die van jouw zo lees, heb jij in die punten zeker gelijk
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
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.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
:strip_icc():strip_exif()/u/25814/camus_small.jpg?f=community)
Je draait nogsteeds code in een VM, het vm vangt alles af, je hoeft dus alleen te weten of het .Net vm big of little endian is, het VM zelf zorgt er wel voor dat het goed vertaald wordt naar de computer! (.Net draait bijvoorbeeld ook op de Xbox360 en op de Zune, ik dacht dat de 360 een powerpc achtige processor had en de zune heeft iig geen x86 processor:
Een vak debuggen zou geen kwaad kunnen, hoe vaak ik dat aan iemand heb moeten uitleggen is niet normaal meer
Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
. Het heeft dus zeker wel nut, .Net is dan ook net zo platform afhankelijk als Java! Verder zie ik niet hoe closures en delegates ooit platform afhankelijk kunnen zijn .Verschilt misschien per faculteit maar op de informatica faculteit zijn ale systemen dual-boot Wingtips(Windows+Novel)/Linux (dacht suse of ubuntu).
@ Oisyn, ah C++09, ik zit er echt op te wachten! Maar wat duurt het lang voordat het komt, de nieuwste versie is toch al 6 jaar oud?
@Janoz: alles in hogere programmeer talen is syntaxtische suiker voor machine-code expressies, dat gaf ik ook al aan in mijn eerste post. Hoe je het nu implementeerd of maakt of bouwt in C++/C#/Java, met of zonder VM, het wordt uiteindelijk uitgevoerd als machine code. Dit is dan ook niet een erg sterk argument. Vooral ook omdat callback interfaces toch net even iets anders zijn dan delegates. (ok je kunt er dezelfde functionaliteit mee bouwen, maar het is geen foreach loop vs een for loop
.
[ Voor 10% gewijzigd door roy-t op 19-12-2008 17:39 ]
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.
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
De Zune en XBox360 draaien het compact framework, dus ik weet niet of die alle leuke gimmicks die eerder zijn opgenoemd daarin draaien. O.a. delegates werken niet, de rest kan ik zo 1-2-3 niet vinden.:
[...]
Je draait nogsteeds code in een VM, het vm vangt alles af, je hoeft dus alleen te weten of het .Net vm big of little endian is, het VM zelf zorgt er wel voor dat het goed vertaald wordt naar de computer! (.Net draait bijvoorbeeld ook op de Xbox360 en op de Zune, ik dacht dat de 360 een powerpc achtige processor had en de zune heeft iig geen x86 processor
:strip_icc():strip_exif()/u/83088/icon%25203.jpg?f=community)
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.
Wat is het nut van een OS? Precies, het vormen van een abstractielaag voor de applicaties die voor dat OS draaien. Een VM is niet veel anders, behalve dat tussen de VM en de hardware meer lagen zit.
Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.
De reden is misschien dat mensen soms van wat meer abstractie houden zodat ze op een hoger niveau kunnen werken?
Een JVM kan (en doet dat ook) on-the-fly compilen. Het verschil zit dus in abstractie.
Ik ben wel blij als een door mij geschreven programma zonder moeite op een ander systeem draait.
Ik ken jouw code niet, dus daar kan ik geen uitspraken over doen. Toch valt het me op dat ik als Windows gebruiker vaak genoeg code tegenkom die ik niet werkende krijg. In de gevallen dat ik het werkende kreeg, moest ik vaak door veel hoepels springen.
Security is iets wat meerdere lagen beslaat. Je OS regelt de security voor alle OS-gerelateerde zaken (diensten), maar het lijkt me best moeilijk voor een OS om te bepalen wat "secure" is in de hogere lagen.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Verwijderd
Inderdaad. Je zou ook een microcode ISA kunnen maken die de Java VM implementeert. Het maakt weinig uit waar je de abstractielaag zet, behalve dat je misschien minder hardware nodig hebt als je de x86-laag er tussenuit haalt. Als Java zo populair zou zijn dat je eigenlijk nog maar weinig x86 code draait, zou je x86 kunnen implementeren bovenop de JVM.:
[...]
Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.
Voordeel van zulke goocheltrucs is dat je pijnloos kan switchen naar betere hardware-architecturen, maar de noodzaak moet natuurlijk wel aanwezig zijn.
C++ code draait ook op elk systeem waar de compiler back-end op draait. Of je nou een back-end moet implementeren of een VM, weinig verschil.
Dat betwijfel ik. Ik denk dat een C++ compiler het beter zou moeten kunnen ivm een context op hoger niveau; in ieder geval niet minder goed.
Native code kan niet buiten je process komen, daar is protected mode voor. Dat is een kwestie van een goed OS, wat er tegenwoordig wel is.
Maar het lijkt me een overbodig abstractie niveau. Er is weinig verschil tussen een compiler back-end en een VM, en back-ends waren er al voor vrijal alle systemen.:
Wat is het nut van een OS? Precies, het vormen van een abstractielaag voor de applicaties die voor dat OS draaien. Een VM is niet veel anders, behalve dat tussen de VM en de hardware meer lagen zit.
[...]
Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.
[...]
De reden is misschien dat mensen soms van wat meer abstractie houden zodat ze op een hoger niveau kunnen werken?
Ja, dus je gaat eerst een abstractie maken, en dan ga je alsnog compilen omdat het te traag loopt anders. Nodeloos ingewikkeld?
Eerlijk gezegd heb ik nooit problemen meer tegenwoordig. Alles compiled en draait moeiteloos op meerdere systemen. Tenzij je echt iets op laag niveau met de hardware doet. Maar daar loop je met een VM helemaal meteen vast.Ik ben wel blij als een door mij geschreven programma zonder moeite op een ander systeem draait.
Ik ken jouw code niet, dus daar kan ik geen uitspraken over doen. Toch valt het me op dat ik als Windows gebruiker vaak genoeg code tegenkom die ik niet werkende krijg. In de gevallen dat ik het werkende kreeg, moest ik vaak door veel hoepels springen.
Het is wel handig dat je security model platform onafhankelijk is, maar het niet iets dat je niet in een OS zou kunnen stoppen per process.
Ik zie het idd als een extra laag, die traag is en weinig toevoegt voor het merendeel van de applicaties. Het enige nuttige dat ik nog steeds zie is het draaien van remote code, zoals in een browser. Dat was volgens mij ook het hele doel aan het begin, totdat iedereen er ineens volledige applicaties in ging schrijven.
Dat klinkt allemaal leuk in theorie, maar in de praktijk is er vaak geen efficiente mapping naar een andere architectuur.
Overigens vind ik niks mis met java hoor, nu het er is. Op het moment dat je het kan compilen naar native code EN er is een VM aanwezig, dan is dat natuurlijk strict beter dan alleen een compiler. Ook vind ik de multi-threading support in java goed. Ik vond het alleen altijd vervelend om in te programmeren; de taal is zo... langdradig. Ook vind ik de argumenten om java te gebruiken vaak slecht. Uiteindelijk is het een keuze, en het maakt niet zo veel meer uit wat je kiest.
[ Voor 10% gewijzigd door Zoijar op 20-12-2008 05:47 ]
Ok, ik dacht er verkeerd over na idd. In dat geval zal het niet veel uitmaken, Java en C++ zijn eigenlijk allebei compiled languages nu, maar java wrapped de compiler in de executable als het ware. Dynamische optimalisaties kunnen sneller zijn, maar er hangt natuurlijk wel een cost aan... dus in de praktijk wisselt het. Beetje flauwe discussie dan eigenlijk. Ik heb de java ontwikkelingen niet zo bijgehouden. Laatste keer dat ik het gebruikte was in 1999. Dus helaas ben ik denk ik schuldig aan het uit m'n nek lullen op basis van oude informatie
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Ja: veel bedrijven willen geen sourcecode meeleveren om te zorgen dat de klant het op zijn specifieke platform kan draaien, je moet maar genoegen nemen met executables. Ik geloof dat Adobe nog steeds geen flash-plugin levert voor BSD. Even compileren is leuk, maar dan moet je het nieuwe platform ook expliciet gaan supporten, en ondanks de vele standaarden lukt het maar niet om te zorgen dat C++-code overal werkt. Vaak werkt die POSIX-library toch net iets anders in BSD, of ontbreken er tools die in een ander OS wel aanwezig zijn.
Zoek eens op wat JIT betekent, en wat de voordelen zijn
Gebeurt standaard in Java, en daardoor hoef je door een stuk minder hoepels te springen om dezelfde snelheid te halen.Die is er ook: nieuws: Azul kondigt tweede generatie Java-processor aan
En het leeft nog steeds: Wikipedia: Azul Systems.
Da's heel aardig, maar wil jij een niet-triviaal systeem schrijven wat zonder problemen op Windows en Linux draait, dan heb je een probleem. Daarbij zal je namelijk óf netwerk, óf een GUI nodig hebben, en dat zit allebei niet in C++. Met QT kan je dan weer prima portable applicaties schrijven, maar dat is amper nog een toolkit te noemen.
Runtime is er veel meer info beschikbaar, zoals hoe vaak een functie wordt aangeroepen etc.
Que
Je zal wel JIT moeten compileren, anders kan het niet worden uitgevoerd. Simpel toch?Heb je een benchmark waaruit blijkt dat java (exclusief opstarttijd VM) veel trager (minimaal 2x) in een real-time applicatie?
Ik dacht eigenlijk dat een toolkit als QT minstens zo langdradig is als Java, maar daar kan ik naast zitten.
http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test
Ja ik heb gezien dat de recentere tests op die site java nergens meer als winnaar aanmerkenEn wat bedoel je met ordes? ik neem aan dat een lineair programma lineair blijft in Java
Ik denk dat als een taal 2x zo langzaam is, dat helemaal geen probleem is. Zolang je algoritmen maar snel genoeg zijn en het schaal-gedrag dus goed is. Extra ontwikkeltijd is veel duurder dan een extra computer.
Ik zie al dat het een holy war is als ik even google Volgens mij maakt het allemaal niet zo veel uit. Wel zie ik veel benchmarks van Java JIT tegen slecht optimized C++. Beetje flauw om JIT gewoon SSE etc te laten gebruiken en dan je C++ code te compilen met -march=i386. Verder kan je op je C++ compilatie ook dingen doen als -fprofile-generate, -fprofile-use dat dan ook run-time info gebruikt. Voor dat soort optimized benchmarks komt (volgens mij, ik heb zelf geen data) toch nog steeds wel uit dat java iets trager is. Het zal geen gigantisch verschil zijn, maar veel mensen doen wel erg makkelijk over 20-30%.
Ik wil best Java gebruiken hoor, dat zei ik eerder al. Lijkt me een prima taal tegenwoordig. Maar ik vind wel dat pro-Java mensen altijd een beetje oneerlijke vergelijkingen maken. Bij Java mag je altijd alles meerekenen: de JIT compiler, de gehele library, het feit dat voor elk platform een JVM/JIT implementatie moet worden/is geschreven, etc. Dat hoort erbij, dat is Java! Ja, maar dat kan ik met C++ bv toch ook allemaal. Oh, je gebruikt QT, nee dat kan natuurlijk niet, DAT is geen C++... Compilen en run-time optimizen op je platform? Nee, dat mag niet, je moet op de allerdomste manier je C++ code genereren: een keer op een 386 compilen en dan overal draaien. Maar ondertussen mag Java wel die hele JIT compiler draaien voor elk programma
Maar nogmaals, prima talen allemaal. C# kan je ook nog uit kiezen.
Volgens mij maakt het allemaal niet zo veel uit. Wel zie ik veel benchmarks van Java JIT tegen slecht optimized C++. Beetje flauw om JIT gewoon SSE etc te laten gebruiken en dan je C++ code te compilen met -march=i386. Verder kan je op je C++ compilatie ook dingen doen als -fprofile-generate, -fprofile-use dat dan ook run-time info gebruikt. Voor dat soort optimized benchmarks komt (volgens mij, ik heb zelf geen data) toch nog steeds wel uit dat java iets trager is. Het zal geen gigantisch verschil zijn, maar veel mensen doen wel erg makkelijk over 20-30%.Ik wil best Java gebruiken hoor, dat zei ik eerder al. Lijkt me een prima taal tegenwoordig. Maar ik vind wel dat pro-Java mensen altijd een beetje oneerlijke vergelijkingen maken. Bij Java mag je altijd alles meerekenen: de JIT compiler, de gehele library, het feit dat voor elk platform een JVM/JIT implementatie moet worden/is geschreven, etc. Dat hoort erbij, dat is Java! Ja, maar dat kan ik met C++ bv toch ook allemaal. Oh, je gebruikt QT, nee dat kan natuurlijk niet, DAT is geen C++... Compilen en run-time optimizen op je platform? Nee, dat mag niet, je moet op de allerdomste manier je C++ code genereren: een keer op een 386 compilen en dan overal draaien. Maar ondertussen mag Java wel die hele JIT compiler draaien voor elk programma
Maar nogmaals, prima talen allemaal. C# kan je ook nog uit kiezen.
:strip_exif()/u/26373/anim4.gif?f=community)
En met de -server commenline optie is java in nog wat meer gevallen sneller (http://shootout.alioth.debian.org/u32q/java.php):
[...]
http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test
En wat bedoel je met ordes? ik neem aan dat een lineair programma lineair blijft in Java
Ik denk dat als een taal 2x zo langzaam is, dat helemaal geen probleem is. Zolang je algoritmen maar snel genoeg zijn en het schaal-gedrag dus goed is. Extra ontwikkeltijd is veel duurder dan een extra computer.
Maar zolang er nog zat programma's zijn die op de 1 of andere manier I/O bound (disc, memory, netwerk, keyboard
) zijn hoeven we ons om dit soort vergelijkingen niet echt druk te maken wat mij betreft.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Haha, ja en de rest van de 15 is C++ sneller, waarbij er toch 20% en meer verschil in zit.:
http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test
Daar bedoel ik mee dat het verschil niet klein is.
Jah dat is de algemene opvatting, waar ik me absoluut niet in kan vinden, misschien geldt dat voor "enterprise" applicaties maar er zijn genoeg voorbeelden te verzinnen waar dit niet opgaat. ( embedded software bv )
Ik heb het idee dat dit argument te vaak wordt gebruikt om maar niet al te veel moeite te hoeven doen om een goed stuk software af te leveren.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Wel met C++ vergelijken, die is veel sneller
Enig idee hoeveel ontwikkeltijd dat kost op een groot project? Het voordeel van Java is dat dat allemaal 'gratis' is, en je dus direct die performance geniet. March=386 is inderdaad niet eerlijk, maar 100.000 compile-opties geven voor het laatste beetje performance ook niet.:
Ik zie al dat het een holy war is als ik even google
QT riep ik specifiek, omdat het ook een uitbreiding op de taal is (voegt syntactic sacharin toeIk wil best Java gebruiken hoor, dat zei ik eerder al. Lijkt me een prima taal tegenwoordig. Maar ik vind wel dat pro-Java mensen altijd een beetje oneerlijke vergelijkingen maken. Bij Java mag je altijd alles meerekenen: de JIT compiler, de gehele library, het feit dat voor elk platform een JVM/JIT implementatie moet worden/is geschreven, etc. Dat hoort erbij, dat is Java! Ja, maar dat kan ik met C++ bv toch ook allemaal. Oh, je gebruikt QT, nee dat kan natuurlijk niet, DAT is geen C++... Compilen en run-time optimizen op je platform? Nee, dat mag niet, je moet op de allerdomste manier je C++ code genereren: een keer op een 386 compilen en dan overal draaien. Maar ondertussen mag Java wel die hele JIT compiler draaien voor elk programma
Maar nogmaals, prima talen allemaal. C# kan je ook nog uit kiezen.
). Behalve dat is QT geen onderdeel van de taal: het is een library daarin om programmeren makkelijker te maken. Dus in C++ zelf zit helemaal niks om cross-platform een GUI te schrijven, net zoals er in Java niks cross-platform zit om de com-poort aan te sturen.
Hij was ook niet serieus bedoeld, maar er vroeg iemand om een voorbeeld waar Java sneller was. Alstu
Ok, dus 20% is een orde? Voor mij is een orde-verschil het verschil tussen een lineair en een kwadratisch algoritme.
Voor embedded high-performance dingen zal ik niet snel java aanraden, o.a. vanwege het geheugengebruik. Voor sommige specifieke applicaties is 20% performance wel cruciaal (3d), en daar moet je vooral gaan bit-fucken.
Maar Java is prima voor algemene software. Voor veel software op de desktop is het verschil tussen 50ms en 100ms verwerkingstijd niet relevant, zolang het maar snel blijft werken bij grotere aantallen (gegroeid aantal medewerkers/klanten/artikelen/...). Daar is de big-O-notatie zo belangrijk voor.
Whoops...:
Wel met C++ vergelijken, die is veel sneller
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
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.
Ik ook nog drie puntjes
- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.
- Iedereen roept altijd: je moet niet op de snelheid van de taal letten, maar op de algoritmes. Uiteraard implementeer je dezelfde algoritmes in beide talen. Het enige performance verschil komt dan uit de taal. 2x verschil vind ik aanzienlijk. Natuurlijk kan je er een computer bij zetten, maar dat kan dan in het andere geval ook. Het blijft een factor 2 (bijvoorbeeld). Soms maakt dat niet uit, soms wel, maar waarom zou je het niet sneller willen hebben? Dat is die hele code bloat mentaliteit van tegenwoordig en naar mijn idee een van de redenen dat ik nog steeds 5 minuten moet wachten op een boot tot ik mijn mail kan checken op een multi-Ghz quad core. (iets dat overigens niet veel sneller gaat nu dan 10 jaar geleden op m'n pentium 60)
- Eens met oisyn over geheugen management. Ik lees vaak dat een voordeel van garbage collection het contiguous alloceren van geheugen oid zou zijn, dat dat het zelfs sneller maakt. Het is vrij common practice om in C++ verschillende allocators te gebruiken (indien van belang), bijvoorbeeld een small-object-allocator die rechstreeks uit een block alloceert en vele maller sneller is dan default new.
- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.
- Iedereen roept altijd: je moet niet op de snelheid van de taal letten, maar op de algoritmes. Uiteraard implementeer je dezelfde algoritmes in beide talen. Het enige performance verschil komt dan uit de taal. 2x verschil vind ik aanzienlijk. Natuurlijk kan je er een computer bij zetten, maar dat kan dan in het andere geval ook. Het blijft een factor 2 (bijvoorbeeld). Soms maakt dat niet uit, soms wel, maar waarom zou je het niet sneller willen hebben? Dat is die hele code bloat mentaliteit van tegenwoordig en naar mijn idee een van de redenen dat ik nog steeds 5 minuten moet wachten op een boot tot ik mijn mail kan checken op een multi-Ghz quad core. (iets dat overigens niet veel sneller gaat nu dan 10 jaar geleden op m'n pentium 60)
- Eens met oisyn over geheugen management. Ik lees vaak dat een voordeel van garbage collection het contiguous alloceren van geheugen oid zou zijn, dat dat het zelfs sneller maakt. Het is vrij common practice om in C++ verschillende allocators te gebruiken (indien van belang), bijvoorbeeld een small-object-allocator die rechstreeks uit een block alloceert en vele maller sneller is dan default new.
[ Voor 3% gewijzigd door Zoijar op 20-12-2008 15:07 ]
Op basis van willekeurige benchmarks is geen overtuigend bewijs te geven, aangezien het er juist om gaat dat een JIT bijvoorbeeld ziet welke codepaden vaak gebruikt worden en het programma dan voor die veelgebruikte paden optimaliseert. Een benchmark heeft onvoldoende verscheidenheid aan codepaden om dat soort effecten zichtbaar te maken. Je hebt er wel degelijk iets aan dat het theoretisch sneller zou moeten zijn, omdat dit juist theorie is die zich in de gebruikspraktijk manifesteert. Je kan het effect demonstreren en je zou het demonstratieprogramma een benchmark kunnen noemen, maar als je er op staat dat het in een willekeurige benchmark sneller zou moeten zijn, dan is het per definitie niet aan te tonen.
Volgens mij is dat omdat het discussies zijn waar zowel de voor- als de tegenstanders eigenlijk niet begrijpen, of niet goed verwoorden, op welke manier de JIT nu eigenlijk voordeel kan bieden boven een statische compiler. Op basis van een set benchmarks, zoals de Debian shootout, hierover discussieren, is zoiets als vergelijken welke auto op een F1 circuit sneller is, terwijl het punt was dat een Subaru Impreza over een gemiddelde van tal van terreinsoorten een snellere tijd neer zal zetten dan een Lotus Esprit. God mag ook weten waarom ze zich er zo druk over maken, aangezien de verschillen waarschijnlijk voor de meeste applicaties marginaal blijven, hoewel het verschil met de toenemende kwaliteit van de JIT natuurlijk wel groter wordt en iedere tiende procent voor serverfarms een behoorlijk verschil kan betekenen.:
Ik zie al dat het een holy war is als ik even google
Ik ken de cijfers niet en zonder een standpunt in te nemen: ik kan me voorstellen dat er de laatste jaren in Java zo ontzettend veel libraries en frameworks zijn uitgebracht, dat je jezelf door het gebruik van zo'n library aardig wat tijd kan besparen, die je in C++ wel moet besteden, omdat een vergelijkbare library ontbreekt. Maar dit geheel zonder enige kennis van C++ en de daar beschikbare libraries.
Telkens als ik de nieuwe TIOBE rankings zie, dan vraag ik me af waarom Java zo ontzettend veel meer gebruikt wordt dan andere talen. Ik kan me niet voorstellen dat dat enkel door marketing komt.
[ Voor 26% gewijzigd door Confusion op 20-12-2008 15:34 ]
Wie trösten wir uns, die Mörder aller Mörder?
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Is er uberhaupt ooit onderzoek gedaan naar de productiviteit van programmeertalen? Vervolgens is de vraag van wat het belangrijkst is. Ontwikkeltijd? Is dit dan de totale ontwikkeltijd of alleen de tijd die je nodig had om de code in te tikken? Is het belangrijk om rekening te houden met hoeveel tijd je kwijt bent aan onderhoud na de ontwikkeling? Hoeveel invloed heeft de taal op vermindering van bugs en fouten? Heeft deze vermindering daadwerkelijk te maken met de taal zelve of met de programmeurs die het aantrekt om erin te gaan programmeren? Et cetera.:
Ik ook nog drie puntjes
- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.
Je moet letten op de requirements.
Het verschil in performance zou ik eerder aan de compiler toekennen dan de taal, maar .oisyn zal hier vast nog wel een voetnoot bij plaatsen.
Krijg je die factor 2 altijd gratis als je bijv. C++ kiest in plaats van Java? Of hangt het ook nog af van het soort toepassing waar je aan werkt?
Sneller is altijd mooi meegenomen, maar je moet wel afwegen of het niet ten koste van andere dingen gaat.
Tanenbaum zou in dit geval de monolithische kernels de schuld geven.
Ik weet wel dat in Java het opruimen van de meeste objecten geen tijd kost.
In dit geval biedt C++ meer flexibiliteit door de programmeur meer controle te geven. Ik heb geen idee hoeveel vrijheid de JVM biedt met het finetunen van de GC, maar de standaardinstellingen zijn denk ik good enough voor de meesten.
(In feite is dit gewoon een geval van hoeveel tijd je wilt en hebt te besteden.)
"In de praktijk"?
The Dangers of Benchmarks
Louter het aantal beschikbare libraries is niet het enige wat belangrijk is. Is de library stable? Is het portable? Wordt het nog onderhouden? Hoe is de documentatie? Is er support? Is het gemakkelijk te installeren en te gebruiken?
[ Voor 13% gewijzigd door RayNbow op 20-12-2008 16:18 ]
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Die index is dan ook best suf. Ze pakken gewoon search engine ratings voor de zoekterm "<language> programming". Dus ze tellen ten eerste gewoon het aantal websites over dat onderwerp (is niet gelijk aan hoeveel het gebruikt wordt), en ten tweede alleen die websites waar de programmeertaal gevolgd wordt door het woord "programming".
Neem bijvoorbeeld PHP, "PHP Programming" heeft bij google 1.35 miljoen hits. Echter wordt er bij PHP vaak ook gesproken over scripting, en als ik zoek naar ["PHP programming" OR "php scripting"], dan kom ik op 3.17 miljoen hits. Dat is meer dan "Java programming" (3.28 miljoen hits). Dus waarom staat PHP niet bovenaan? En denk je ook dat PHP daadwerkelijk meer gebruikt in de software industrie dan Java? En waarom gebruiken al die mensen dan Java, als PHP blijkbaar zo populair is?
Neem bijvoorbeeld PHP, "PHP Programming" heeft bij google 1.35 miljoen hits. Echter wordt er bij PHP vaak ook gesproken over scripting, en als ik zoek naar ["PHP programming" OR "php scripting"], dan kom ik op 3.17 miljoen hits. Dat is meer dan "Java programming" (3.28 miljoen hits). Dus waarom staat PHP niet bovenaan? En denk je ook dat PHP daadwerkelijk meer gebruikt in de software industrie dan Java? En waarom gebruiken al die mensen dan Java, als PHP blijkbaar zo populair is?
Het is dan ook geen opruimen, maar gewoon aan de kant schuiven totdat je de resources daadwerkelijk weer nodig hebt. Ik heb een C++ memory allocator gemaakt die precies dat doet, en dat zorgt in m'n got contest implementatie voor een factor 3 tot 4 snelheidsverschil. En je daadwerkelijke programmacode hoeft er niet eens anders voor geschreven te worden.:
Ik weet wel dat in Java het opruimen van de meeste objecten geen tijd kost.
[ Voor 24% gewijzigd door .oisyn op 20-12-2008 16:29 ]
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.
- Geen garbage collector zelf schrijven/uitzoeken/overal netjes verwijderen.:
Ik ook nog drie puntjes
- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.
- Daardoor minder kans op memory leaks, die best wel wat tijd kunnen kosten in de onderhoudsfase
- Eenvoudiger debuggen
- Minder quirks (ik hoor steeds iets roepen over bools in vectors in C++, wat is daarmee?)
Ik weet niet wat voor flut-OS jij gebruikt
, maar Linux is echt veel sneller geworden, en met de technieken die nu voor de deur staan wordt dat alleen maar beter. Probleem is dat het OS veel groter wordt, steeds meer moet kunnen doen (bluetooth, wifi, fancy 3d-animaties), en bij het opstarten gelimiteerd wordt door de HDD. Wil je 2x zo veel doen, dan zal je waarschijnlijk 2x zoveel van je HDD moeten halen, en zo veel sneller zijn de harde schijven (relatief gezien) niet geworden de afgelopen jaren. Dat je hetzelfde algoritme implementeert in verschillende talen vind ik niet vanzelfsprekend: als de libraries een heel efficiente sort-functie hebben, ga ik dat gebruiken, en geen eigen algoritme. Ga je functionele programmeertalen gebruiken, dan wordt het nog leuker.
Een paper "Comparing observed bug and productivity rates for Java and C++" uit '99 door ene Geoffrey Philips is een van de weinige papers die ik via google scholar kon vinden. Summary:
Nogal een flutonderzoek dus. Als iemand een betere paper tegenkomt via scholar.google.com ofzo, kan ik ze meestal gratis inzien (TU/e
), ik ben wel benieuwd.
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.
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.
Of even door valgrind
Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal. Grappig dat iemand iets zei over monolitische OS kernels: je wilt een taal ook modulair opzetten met zo'n klein mogelijke, gestandaardiseerde "kernel" en de rest in pluggen aan de hand van support libraries. Ik vind dat dus geen argument om deze twee talen te vergelijken. Op dat punt scoren ze gelijk naar mijn idee. (C++ support meer legacy libraries, maar dat terzijde)
Dat Java makkelijker debugged heb ik nog geen overtuigend argument voor gehoord.
Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht. Het ging me ook om twee programmeurs die beide de taal beheersen. Ik kan voor mezelf nog steeds niet het performance verschil verantwoorden.
Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal. Grappig dat iemand iets zei over monolitische OS kernels: je wilt een taal ook modulair opzetten met zo'n klein mogelijke, gestandaardiseerde "kernel" en de rest in pluggen aan de hand van support libraries. Ik vind dat dus geen argument om deze twee talen te vergelijken. Op dat punt scoren ze gelijk naar mijn idee. (C++ support meer legacy libraries, maar dat terzijde)
Dat Java makkelijker debugged heb ik nog geen overtuigend argument voor gehoord.
Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht. Het ging me ook om twee programmeurs die beide de taal beheersen. Ik kan voor mezelf nog steeds niet het performance verschil verantwoorden.
/u/220490/bombcut.png?f=community)
Het is heel simpel. Met Java heb je 1 leverancier, met C++ moet je op 10 plekken je support krijgen. Als iets het niet doet in java kan je als bedrijf java bellen dat ze het moeten fixen, terwijl je van Trolltech te horen krijgt dat GCC een foutje maakt, en het uit eindelijk aan boost bleek te liggen. Je kiest een pakket, en bent klaar.:
Of even door valgrind
Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal.
De taal alleen is C++ zonder stdlib, java zonder imports, en allebei zijn onwerkbaar. Alles wat je los schrijft moet onderhouden worden, en zoals hier al vaker is gezegd: onderhoud is he tduurste.
Misschien is het ook niet eerlijk, omdat ik in Java veel simpelere dingen doe (parser bouwen voor embedded SQL) dan ik in C++ heb gedaan (3D applicatie). Maar in C++ ben ik altijd veel langer bezig geweest met debuggen waar mijn fout zit dan in Java.
Daar heb je het dus al: je moet je aan de manier van programmeren houden. Volgend jaar beslis jij dat je iets anders wilt gaan doen, en komt er iemand waarvan jouw baas denkt dat hij C++ kent om jouw applicatie te onderhouden. Doordat je in Java automatische garbage collection hebt, en dat in C++ afhangt van de programmeur, maak je de kans op fouten tijdens onderhoud groter.
En performance is het argument waar je maar op terug blijft komen, ondanks dat iedereen toch wel zo ver wilt gaan dat het (bijvoorbeeld) 20% langzamer is. Is java de grootste vloek van de informatica omdat het 20% langzamer is dan C++? Jij gebruikt Java liever niet omdat jouw applicaties kennelijk heel erg goed moeten performen. Zijn er nog andere redenen?
Even een side-note: welk C++ framework zouden jullie gebruiken om een enterprise-applicatie met webinterface te schrijven?
Exactly
Sorry, 't was too obvious
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.
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.
Vroeger had je wel gelijk, maar tegenwoordig heb je op de meeste praktische platforms niet echt last. Als je echt embedded dingen doet weet ik het niet. Maar als het gaat om linux/macos/windows is er geen enkel probleem.
Ja, dat is idd een voordeel van Java. Ik hou me daar eerlijk gezegd niet zo mee bezig, dus ik weet er weinig van...
Op zich een mooi voorbeeld. Stel dat je daar een zoekboom hebt en je mag maar een bepaalde tijd rekenen, dan kom je zelfs met slechts 20-30% meer performance gewoon dieper en heb je een goede kans op een beter antwoord. Scheelt het veel? Het kan je de overwinning schelen
---
Geen verstand van. Een collector is dat GC? Is dat iets als two-space GC? Dat is het enige dat ik ooit in C heb geimplementeerd voor een toy OO compiler (uni opdracht...)
Wat een abstract... een hele kolom
Auw...
Het is even snel hoor, als je 5x zo veel geheugen hebt
[ Voor 22% gewijzigd door Zoijar op 21-12-2008 11:31 ]
Ik heb het net nog even gechecked, en van de 3 reeds afgelopen contests zijn er 2 gewonnen door een Java oplossing, en één door een C++ oplossing.:
[TweakersContest]
Op zich een mooi voorbeeld. Stel dat je daar een zoekboom hebt en je mag maar een bepaalde tijd rekenen, dan kom je zelfs met slechts 20-30% meer performance gewoon dieper en heb je een goede kans op een beter antwoord. Scheelt het veel? Het kan je de overwinning schelen
Niet echt representatief natuurlijk.Kijkend naar de top 3 waren er 6 java-oplossingen en 2 C/C++ oplossingen.
Nog steeds niet representatief natuurlijk, maar om even terug naar het originele topic te gaan, is Java dan misschien toch niet zo verschrikkelijk. Want als het dan trager is, moeten de algoritmes van de Java-oplossingen toch wel beter zijn dan die van de C++ oplossingen
note: deze reactie is niet heel erg serieus bedoeld he
Ah, en nu komen we eindelijk bij de conclusie: java programmeurs worden lui en onoplettend, en nieuwe programmeurs worden op die manier opgeleid, en iedereen weet dat daar fouten van komen
Het gaat zeg maar van "Java kan niet leaken" naar "Wat is een leak?". (niet dat ik het daar helemaal mee eens ben hoor; je kan natuurlijk prima een top java programmeur zijn die gewoon alles weet.)Wt? .NET?
Geen idee.Ik vraag me toch een beetje af hoeveel run-time information een (JIT) compiler nou echt nuttig kan gebruiken. Dat lees ik steeds: we have run-time info. En wat doen ze daar dan nuttig mee? Iets meer performance? En dan vervolgens roepen dat een applicatie die 2x zo langzaam is niet uitmaakt? En wat kost het om die run-time info te verzamellen? Meer of minder dan wat het oplevert?
En gewogen naar frequentie van inzendingen? 99 mensen die java gebruikten en eentje met C++ die steeds in de top 3 komt?:
Ik heb het net nog even gechecked, en van de 3 reeds afgelopen contests zijn er 2 gewonnen door een Java oplossing, en één door een C++ oplossing.
Kijkend naar de top 3 waren er 6 java-oplossingen en 2 C/C++ oplossingen.
Nog steeds niet representatief natuurlijk, maar om even terug naar het originele topic te gaan, is Java dan misschien toch niet zo verschrikkelijk. Want als het dan trager is, moeten de algoritmes van de Java-oplossingen toch wel beter zijn dan die van de C++ oplossingen
note: deze reactie is niet heel erg serieus bedoeld he
Ik ben ook niet zo serieus hoor; ik zie gewoon veel argumenten die naar mijn idee niet kloppen
[ Voor 20% gewijzigd door Zoijar op 21-12-2008 11:55 ]
Volgens mij beginnen we nu in herhaling te vallen: Zoijar in "Is java de grootste vloek in de informat...":
Ah, en nu komen we eindelijk bij de conclusie: java programmeurs worden lui en onoplettend, en nieuwe programmeurs worden op die manier opgeleid, en iedereen weet dat daar fouten van komen
Wie trösten wir uns, die Mörder aller Mörder?
Ja, een Two-space GC is een copying collector.
Het is dan altijd ook een tradeoff tussen performance qua geheugen en performance qua tijd. Als je het geheugen tot je beschikking hebt, dan zie ik iig geen probleem om het te gebruiken.[...]
Auw...
De paper laat wel zien dat GC soms een kleine fractie sneller is met grotere heaps.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Haha:
Volgens mij beginnen we nu in herhaling te vallen: Zoijar in "Is java de grootste vloek in de informat..."
Ja, deze hele discussie is een grote herhaling van andere fora Ah ok. Nee, dat heb je dan dus niet nodig met smart pointers. Die gebruiken reference counting. Het principe gaat op voor alle resources eigenlijk, inclusief geheugen dus. Een "object" blijft bestaan zolang het referencable is. Bij elk kopie van de smart pointer gaat de reference count omhoog, en bij elke destructie omlaag (zijn nog wat details, maar die zijn niet belangrijk nu). Als de reference count naar 0 gaat wordt het opgeruimd. Daar hoef je verder niet op te letten. Zoiets krijg je dan:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| typedef boost::smart_ptr<Object> OPtr; void foo(OPtr x) { // do stuff with x, ie x->foo(); etc. // assign new object x = new Object(); // oops, error here throw "error"; } void main() { try { OPtr obj = new Object(); // make object on heap foo(obj); } catch (...) {} } |
Deze code leaked niet, zelfs niet bij de exception. Als je ziet hoe makkelijk dit gaat, wat is dan eigenlijk nog het echte nut van GC? Overigens hebben smart pointers ook een cost natuurlijk, zeker in multi-threaded omgevingen.
5x zo veel geheugen geen probleem? Dat betekent dat elk huidig 4GB systeem maar effectief 800MB kan gebruiken in een complete GC omgeving. Jouw app is niet de enige die draaitHet is dan altijd ook een tradeoff tussen performance qua geheugen en performance qua tijd. Als je het geheugen tot je beschikking hebt, dan zie ik iig geen probleem om het te gebruiken.
De paper laat wel zien dat GC soms een kleine fractie sneller is met grotere heaps.
Ik vind het wederom een vrij grote cost voor weinig benefit. Uiteraard is dat op te lossen door er gewoon 20GB in te prikken...
Maar werkt reference counting ook als je te maken hebt met cyclische structuren?
Daarom is het ook een afweging. Je kan ook besluiten om een GC te gebruiken en minder performance. Het hangt totaal af van de requirements en je beschikbare resources (CPU, RAM, aantal ontwikkelaars in dienst, beschikbaar budget, beschikbare ontwikkeltijd, aanwezigheid bestaande tools en libs, etc.).[...]
5x zo veel geheugen geen probleem? Dat betekent dat elk huidig 4GB systeem maar effectief 800MB kan gebruiken in een complete GC omgeving. Jouw app is niet de enige die draait
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
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.
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.
Nee, dat hebben ze niet altijd en dat is ook .oisyns punt. De JVM ruimt niet alles volautomatisch voor je op. Wel veel, maar niet altijd alles: http://www.google.nl/sear...=UTF-8&q=java+memory+leak
Er zijn mensen die denken dat het onmogelijk is om een mem. leak te hebben in Java. En dat verbaast me aan de ene kant. Aan de andere kant ook niet omdat niet iedereen zich echt lijkt te verdiepen in de omgeving waarmee ze ontwikkelen.
[ Voor 21% gewijzigd door Creepy op 21-12-2008 17:57 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney