Archief - Programeren

Visual C++ is Microsoft gerelateerd en gcc is unix-based, zodus uw punt klopt op dat vlak al niet. (hij had dus duidelijk voor de linux-versie gekozen)

Voor de rest had ik het artikel wel gelezen en Java wint toch duidelijk op de OOP-vlakken...

Grayfox zei:

C++ niet moeilijk? HA, nog nooit function pointers gebruikt zeker?
Moeilijke aan C++ zijn dus de pointers, en memory management
Java heeft al automatische memory management (je moet niet zelf meer het geheugen free-en nadat je het gebruikt hebt, dat gebeurd vanzelf)
dit betekent veel minder debuggen, en veel vlugger kunnen coden!
Java heeft wel veel objecten enzo, daarmee bekend raken kan nogal lastig zijn omdat het er zoveel zijn
Maar C++ is dan weer veel sneller en beter voor (performance/spelletjes) bijvoorbeeld
Java is dan weer 'platform-onafhankelijk'
Voor simpele desktop apps voor windows is het eigenlijk zelf beter VisualBasic te gebruiken omdat dan de performance niet veel uitmaakt, je er genoeg mee kan doen, en het developpen veeel rapper gaat.

Klik om te vergroten...

De moeilijke aspecten van C++ liggen eerder in het domein van de templates. Niet dat het idee erachter zo complex is, maar de C++ implementatie ervan is gewoon walgelijk. Niet dat dit een argument is voor Java, want Java heeft geen templates. Je kan gewoon C++ gebruiken zonder zelf templates te schrijven (gebruik van de standaard templates is niet zo lastig).

Natuurlijk zal je na enkele lastigere projecten leren dat de moeilijkheden van de taal doorgaans triviaal zijn in vergelijking met de moeilijkheden van het doel van het programma. Tenzij je in Brainfuck, Intercal, Unlambda, Malbolge of iets dergelijks schrijft natuurlijk (wat ik zou afraden).


Iets om mee te beginnen?
http://www.python.org/
Trager dan C++ of Java, maar sneller te leren. En de eerste programmeertaal is gewoonlijk de moeilijkste, dus begin met iets simpel.

Het kan ook voor spellen gebruikt worden.
http://www.pygame.org/

Grayfox zei:

Java is wel degelijk trager dan VISUALC++ (vooral als het aankomt op geometrische functies zoals sinus en cosinus)
waarom zouden developpers anders niet in Java hun 3D spelletjes maken?
Java is multiplatform... veel vlugger te schrijven, en heeft memory management...
Dat artikel, als je het wat beter gelezen had, ging over JVM als server, JVM als Client verliest praktisch op alle gebieden, en hij gebruikt ook nog eens GCC (ipv VC++)

Als Java dan echt sneller was, waarom zouden de mannen van Sun zelf op hun website benchmarks hebben waarin ze tonen dat (Visual) C++ sneller is?
btw, FYI, snelheid ligt aan de compiler/interpreter, niet zozeer aan de taal

Klik om te vergroten...

Hier nog een paar leuke benchmarks:
http://www.racai.ro/~trausan/LispJava.htm
Java wordt afgeslacht.
De snelste programma's waren in C geschreven, maar gemiddeld was Lisp beter. Niet zo slecht voor een taal uit 1959. Ik voeg daar meteen aan toe dat op dit moment leren programmeren met Lisp waarschijnlijk lastig zou zijn. Niet dat de taal slecht is, maar ze wordt weinig gebruikt en je zou dus moeilijk hulp vinden. Neem voor de eerste taal best iets dat een paar vrienden al kennen.

Python zuigt. Al mee gewerkt. Java is volgens mij beter om mee te beginnen. Python syntax is ook nogal vreemd.

hahahaha, kwou da vroeger ook altij, een spel make, gelijk doom en duke nukem
waar is den tijd :applause:
mijne raad is, wordt wiskundefreak en ziet da ge goe zijt in engels
door wiskunde leer je geordent en en met logica werken, en engels, alles progtalen zijn in engels dus...

en dan me een beetje creativiteit kunde u storten in de gamedevelopperswereld

succes

WHiSPy zei:

Voor de rest had ik het artikel wel gelezen en Java wint toch duidelijk op de OOP-vlakken...

Klik om te vergroten...

Ah komaan, hoe kan je nu een artikel betrouwen dat met 2 zo'n lijnen begint, djeez.

Eerst: "C++ sux", en dan er direct onder: "Unbiased benchmark"

Zoek de fout...

wlibaers zei:

Niet dat dit een argument is voor Java, want Java heeft geen templates.

Klik om te vergroten...

Generics werden geïntroduceerd in Java 1.5 die bij mijn weten in beta 2 is (en gewoon beschikbaar voor download).

WHiSPy zei:

Visual C++ is Microsoft gerelateerd en gcc is unix-based, zodus uw punt klopt op dat vlak al niet. (hij had dus duidelijk voor de linux-versie gekozen)

Voor de rest had ik het artikel wel gelezen en Java wint toch duidelijk op de OOP-vlakken...

Klik om te vergroten...

dus als Java sneller is dan de unix-based GCC dan kan men zeggen "Java is sneller dan C++"
das bullshit imo, kweet er ni zoveel van, maar kweet genoeg dat als op die grafiek Java op ELK punt in het rood staat bij JVM Client version, da ge ni kunt beweren dat Java sneller is dan C++
(meeste apps zijn toch client version, of niet soms?)

Grayfox zei:

dus als Java sneller is dan de unix-based GCC dan kan men zeggen "Java is sneller dan C++"
das bullshit imo, kweet er ni zoveel van, maar kweet genoeg dat als op die grafiek Java op ELK punt in het rood staat bij JVM Client version, da ge ni kunt beweren dat Java sneller is dan C++
(meeste apps zijn toch client version, of niet soms?)

Klik om te vergroten...

Lees het artikel, en dan vooral het stukje over de server VM dan eens hé, alvorens dergelijke onzin te spuien. Daarbij, ik snap niet dat iemand zich druk maakt over "deze of gene taal is de snelste". De taal die mij toelaat van op een snelle manier mijn soft te ontwikkelen is imho steeds de beste keuze. Of dat nu Java, C++, Delphi, PHP of iets anders is, maakt mij eigenlijk geen zak uit. Het resultaat telt, niet de gebruikte tool.

Cocoa (Objective-C) is ook niet mis trouwens .

BTW Als je een iets anders aangepakte tekst wil :
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

da snap ik toch ni hoor, als je een applicatie ontwikkelt waar de performance belangrijk is, dan is het toch belangrijk da ge voor de 'snelste' taal gaat? of en ik hier mis?
en ik zei toch ook al eerder in de topic dat Java/VB veel rapper gaat om simpele desktop apps te ontwikkelen
mja, ik geef toe, kben er pas aan begonnen aan programeren, maar kvind toch als ge zegt dak onzin uitspui dat ge moogt zeggen wat er mis is
kvraag me dan eigenlijk gewoon af waarom spelletjes dan bijvoorbeeld in c/c++ geschreven worden

Grayfox zei:

maar kvind toch als ge zegt dak onzin uitspui dat ge moogt zeggen wat er mis is

Klik om te vergroten...

De onzin sloeg op 't feit dat je het artikel niet eens gelezen hebt (misschien eens vluchtig bekeken). Anders zou je weten dat je de JVM in "server" mode kan runnen, dat heeft in wezen niets met het client/server concept te maken.

These two systems are different binaries. They are essentially two different compilers (JITs) interfacing to the same runtime system. The client system is optimal for applications which need fast startup times or small footprints, the server system is optimial for applications where the performance is most important. In general the client system is better on GUIs. Some of the other differences include the compilation policy used, heap defaults, and inlining policy.

Klik om te vergroten...

Dus als je performance wil en niet te veel inzit met geheugengebruik is de keuze tussen client en server VM wel duidelijk zeker?

ah, ok nu snap ik het, thx

De Java VM voor windows is gemaakt met Microsoft Visual C++ 6.0...

Grayfox zei:

kvraag me dan eigenlijk gewoon af waarom spelletjes dan bijvoorbeeld in c/c++ geschreven worden

Klik om te vergroten...

Omdat Java platform onafhankelijk is en moeilijker kan interfacen met grafische API's zoals DirectX en OpenGL. Als je gebruik wil maken van één van deze technologiën moet je een native interface naar die API programmeren (of reeds een bestaande gebruiken: Java3D/JOGL/...) of J++/J# gebruiken (maar wie doet dat?).

Als ik mij niet vergis is IL Sturmovik voor een deel in Java geprogrammeerd.

Ik ben VB 6 beginnen te leren toen ik 14 was (jaartje geleden) en nu zit ik dus aan VB .Net en C++ heb overlaatst ook Visual Studio .Net 2003 Proffesional Academic gekocht speciaal voor tieners tottaal niet zo duur als gewone proffesional en is toch nog proffesional met extra Student Tools als ik u was zou ik E-Books oftewel echte leerboeken kopen (ik verkies echte leerboeken omdat ik tottaal niks kan leren als ik zoveel van het scherm moet lezen das saai )

zikje zei:

Python zuigt. Al mee gewerkt. Java is volgens mij beter om mee te beginnen. Python syntax is ook nogal vreemd.

Klik om te vergroten...

Nogal vreemd voor wie Java gewoon is misschien, maar zeker eenvoudiger om mee te beginnen. Ik zou het ook niet gebruiken voor een Doom 3 variant, maar om mee te leren programmeren is het zeker niet slecht. Een ander pluspunt is dat het goede functies heeft om tekst te lezen en te bewerken (regexp, is in vele talen maar in Python heel eenvoudig). En vermits de eerste programma's waarschijnlijk gewoon met tekst zullen werken lijkt het me geen slechte keuze. Er zijn ook goede tutorials voor. Het gaat hier voorlopig om wat leren programmeren, nog niet om geavanceerde 3D progs te maken.


Wat deze link betreft:
http://www.idiom.com/~zilla/Compute...Cbenchmark.html
Daar wordt verwezen naar abstraction penalty bij C++, met een verwijzing naar "The Kernighan and Pike book The Practice of Programming" (Ned. versie "Programmeren in de praktijk"). Ik zou iedereen die hiervoor interesse heeft aanraden dat boek eens te bekijken, de conclusies zijn namelijk iets complexer dan die site laat uitschijnen. Java zat bijvoorbeeld ook in die tests, en werd o.a. verslagen door Awk en Perl...

Grayfox zei:

da snap ik toch ni hoor, als je een applicatie ontwikkelt waar de performance belangrijk is, dan is het toch belangrijk da ge voor de 'snelste' taal gaat? of en ik hier mis?

Klik om te vergroten...

Ja. Je neemt niet de absoluut snelste taal (handgeoptimaliseerde assembly code is de laatste tijd niet meer zo populair, zelfs niet bij de meeste spelprogrammeurs, tenzij ze nog met software rendering werken), maar een taal die een redelijk compromis biedt tussen snelheid en gebruiksgemak. Verder is er een historische achtergrond, de meeste spelprogrammeurs zijn C/C++ gewoon en zullen daarin zeker op korte termijn dus productiever zijn dan in een andere taal. En praktische aangelegenheden: bijna alle OpenGL en DirectX documentatie veronderstelt dat je C en/of C++ gebruikt.

Hm, kheb gehoord dat het verschil in performance tussen VC++ en assembly maar miniem is, en dat ze toch wel in assembly stukjes van de code schrijven (bijvoorbeeld shaders) waar het helpt.
dus dan proberen ze toch wel de absolute snelste taal te gebruiken?
En OpenGL RedBook probeert zoveel mogelijk de voorbeeldjes in simpele code te zetten (dus als je gelijk welke programeertaal kent zou je het moeten begrijpen, behalve af en toe pointers dan)
Trouwens, in OpenGL documentaties is er veel meer uitleg over hoe OpenGL werkt dan dat er stukjes codes gegeven worden, en dat is dan nog eens met behulp van glut waardoor alles er zeer simpel uitziet.
Volgens mij (ben ik helemaal niet zeker) kan je jezelf behelpen in JOGL als je OpenGL Redbook leest.

Daarbij C++ (of andere native compiled taal) zal altijd beter zijn dan Java, want in welke taal ga je dan je VM in maken? :ironic:
En zou je niet eerst beter kijken naar de code van die programma's die ze gebruiken om de snelheid te vergelijken. Die C++ progs zijn gewoon een slechte vertaling van de Java versie.

ik zou u aanraden om een taal te leren. gaat later zeker nog van pas komen. ik zou voor java gaan. en als ge het echt simpel wilt houden, their is visual basic.

ik zou u afraden om van die programmas te downloaden om vb enkel spellekes ofzo te maken. serieus, leert een taal. ge gaat het u ni beklagen

Kunt kiezen Java of misschien een of andere gratis basic compiler.
Of kunt is http://www.freepascal.org/ proberen eens je daar mee goed kunt werken kan je ook veel mee doen.

Silenger.BE zei:

Daarbij C++ (of andere native compiled taal) zal altijd beter zijn dan Java, want in welke taal ga je dan je VM in maken?

Klik om te vergroten...

Ik vermoed dat je dan nog nooit gehoord hebt van compiler bootstrapping dan?

The usual process is to write an interpreter for a language, L, in an existing language, M. The compiler is then written in L and the interpreter is used to run it. This produces an executable for compiling programs in L from the source of the compiler in L.

This technique is often used to verify the correctness of a compiler. It was first used in the LISP community.

Klik om te vergroten...

Je kan dus perfect een Java JVM in Java schrijven, je kan zelfs Java bytecode gaan compileren naar native code via een Java applicatie als je dat zou willen (dan word die wel platform afhankelijk uiteraard).

En wat de uitvoering van Java apps in Java bytecode betreft : je hebt toch al gehoord van JIT compilatie?

Nu ja, het blijft imho een idiote discussie, de programmeertaal is maar een werkmiddel (net zoals een Operating System, of een IDE), het is het resultaat dat telt.