Archief - [ALG] hoe verder gaan

ik heb net een boek uit over vb 6.0
nu is mijn vraag met welke taal kan ik het best verder gaan
ik had gedacht aan C maar ik weet niet juist hoe dat werkt kan iemand mij wat meer info geven ???

Ga naar VB.NET, leer je waarschijnlijk iets beter met OO omgaan.
Blijf van C af, ga anders voor C#, mooie moderne taal die een goede basis legt om eventueel ooit nog eens over te schakelen naar C++ of JAVA, mocht je dat willen.

wat is OO ??

Object Oriented (Programming).

De meeste C# en Java tutorials zullen dat wel allemaal uitleggen.
Het beste is imo een goed boek zoeken (gebruik de search hier eens, die vraag is al 100x gesteld)

black_ganon zei:

wat is OO ??

Klik om te vergroten...

Daarom dus.

In kort, klassen en objecten.

Klinkt moeilijker dan het in feite is hoor, moet alleen die klik kunnen maken. Persoonlijk vond ik dit wel moeilijk om uit een boek te leren, vooral omdat ik geen idee had waarover de auteur het had.

string x = new string();

wtf???

Eens iemand dit een keer deftig uitlegde was dit volledig duidelijk, bon niet direct, maar toch al 80%.

Mocht je wat uitleg willen ofzo, stuur dan maar een PM.

OO uitleggen adhv gamedesign is eigenlijk vrij gemakkelijk.

Object oriented wil alleen maar zeggen dat we met objecten gaan werken.

Elk object heeft properties en methods.

vb properties object player:
health, mana, int,str,agi

vb methods object player:
loadfromsave, regenerate, hurt...

wat is daar nu handig aan?

stel je moet iedere keer dat de speler een slag krijgt met een zwaard berekenen of hij de slag dodged, parried of blocked

in zijn method hurt kan je dan testen :

%kans tot dodgen (afhankelijk van agi)
%kans tot block (afhankelijk van of hij een shield heeft en of hij +block heeft van het shield)
%kans tot parry (afh van parry skill)

dit roepen we dan op via

player.hurt(100) waarin 100 de damage is die de player te verwerken krijgt.
Afhankelijk van zijn dodge/block/parry abilty zal die damage al dan niet doorkomen

Hier zie je een beetje de kracht van OO. Als je het nog iets verder doortrekt kan je je damage ook als een object beschouwen

bv
slice - canbedodged,canbeparried,canbeblocked,canbemissed
frost blast - cannotbedodged, cannotbeparried,cannotbedodged, canbemissed

dan krijgen we zoiets van
damSlice = new Damage();
damSlice .Type = "slice";
damSlice .CanBeDodged = true;
damSlice .CanBeParried = true;
damSlice .CanBeBlocked = true;
damSlice .CanBeMissed = true;

damFrostBlast = new Damage();
damFrostBlast .Type = "frostblast";
damFrostBlast .CanBeDodged = false;
damFrostBlast .CanBeParried = false;
damFrostBlast .CanBeBlocked = false;
damFrostBlast .CanBeMissed = true;

player.Hurt(damSlice);
player.Hurt(damFrostBlast);

dit damageobject kan je dan later in je spells en wapens objecten steken zodat je uiteindelijk tot dit komt:

player.Hurt(BarbaricSword.DamageType,BarbaricSword.Damage);
player.Hurt(FrostBlastSpell.DamageType,FrostBlastSpell.Damage);

Hoop dat het hiermee een beetje duidelijker is.

k thx dan zal ik wel eens een boek gaan halen over VB.net heb je hier een apart programma voor nodig of is dat een uitbreiding op VB 6.0

kan je met vb simpele spelletjes maken zoals tetris of pong ??

Kan zeker.
Al vraag ik me af of je nu enkel de oefeningen uit het boek gemaakt hebt & daarmee vind dat je kan programmeren (no offence moest het zo zijn).
Programmeren is beginnen met een basis & de rest van de mogelijkheden zelf uitwerken & opzoeken naar believen. Bedenk hoe jij een Pong zou maken (Tetris zal vrij moeilijk zijn). Voor pong zal je het balletje automatisch moeten laten bewegen & een soort van collision detection nodig hebben .. ga daar naar opzoek, etc.

VB.NET ontwikkelen de meesten in visual studio .net, een ongeloofelijk duur pakket, maar moest je student aan een hogeschool/unif zijn (of in sommige gevallen ook middelbaar), kijk dan zeker eens op www.ma3d.com.

met de ervaring die ik opgedaan heb door dat boek kan ik totaal geen pong maken in dit boek hebben ze het nooit over collision detection gehad

kan jij mssn een goed boek over vb aanraden

Ik persoonlijk vind dat jij teveel hooi op je vork wil nemen in een keer. Ik wil maar zeggen, je kent op dit moment nauwelijks iets van eenderwelke programmeertaal en je wil al een mini-game programmeren. Boeken die specifiek over een bepaalde taal gaan, daar leer je NIETS anders mee dan DE TAAL (althans een stuk ervan, zeker niet alles). Nog iets, is zulke boeken zal je nooit de term "Collision Detection" vinden hoor, er bestaat niet een of andere functie doCollisionDetectionForMeSoIDontHaveToThink().

Persoonlijk vind ik VB een taalje voor de kinder programmeurtjes onder ons, maar dat even ter zijde...

Neem eventjes een beetje raad aan van iemand die in het vak zit. Je moet keuzes maken. Welke taal? Waar wil je naartoe? Wat wil je nu juist doen? Wat is je motivatie om te leren programmeren?
Knoop goed in je oren dat er ook nog eens een groot verschil is tussen een taaltje kennen en OOP technieken beheersen. Het is niet omdat je perfect een taal kan dat je daarom ook een prachtig boek kan schrijven. Software Architecture en Design is een kunst op zichzelf en ikzelf leer nog dagelijks nieuwe dingen terwijl is reeds jaren in het vak zit. Je mag niet denken, en ik heb de indruk dat jij dat denkt, dat indien je een taal kent, je zomaar alles kan doen. NEEN, zulk een taal is een werktuig om jou creativiteit en vindingrijkheid uit te drukken zodat een computer doet wat je hem verteld, meer niet. Het is nog steeds jou denkwerk en creativiteit dat eraan te pas moet komen. Zeker als je met nieuwe dingen bezig bent moet je veel opzoekingen en research verrichten, zodat je een beetje in de juiste richting kan lopen. Er bestaat geen boek waar alles in staat, dat is gewoon niet mogelijk doordat je met een programmeertaal alle richtingen uit kan en je zelfs dingen kan doen die nog nooit door iemand anders zijn gedaan. Het boek dat jij las ging over Visual Basic en THAT's IT.

er bestaat niet een of andere functie doCollisionDetectionForMeSoIDontHaveToThink().

Klik om te vergroten...

Niet zo letterlijk dat niet.

In VB.net kan je wel rectangles vergelijken en een boolean terugkrijgen die aangeeft of er detectie is ( weet niet meer 100% hoe het werkt, dus het kan net iets anders zijn.).
Heb het ooit gebruikt voor Pong dacht ik.

Je hebt wel gelijk overigens, trouwens uit een boek leren vind ik al niet zo schitterend. Dikwijls veel school voorbeelden en je eigen code wordt niet verbeterd, zolang het maar werkt, zal het wel correct/goed zijn. Slechte gewoonten zijn zo snel aangeleerd en moeilijk af te leren.
Ik niet dat een boek je niet veel kan bijleren hoor en er zijn zeker uitzonderinen (die het zeker niet zullen na te laten het me mee te delen )maar de basis kan je volgens mij nog altijd beter van een persoon leren.

Radiance zei:

VB.NET ontwikkelen de meesten in visual studio .net, een ongeloofelijk duur pakket, maar moest je student aan een hogeschool/unif zijn (of in sommige gevallen ook middelbaar), kijk dan zeker eens op www.ma3d.com.

Klik om te vergroten...

Je kan het zo duur maken als je zelf wil.
Het dot net (sdk) framework kan je gratis downen (net zoals de J2EE sdk)
Er bestaan gratis IDE's voor dot net zoals:
- SharpDevelop
- WebMatrix
- C#Builder (Borland)
- Mono (is eigenlijk geen ide, maar een opensource project om dot net applicaties te kunnen ontwikkelen en draaien op Linux.
...

En natuurlijk eveneens voor J2EE:
- Eclipse
- intelliJ idea
- NetBeans
- JCreator
- Sun Studio Standard/Enterprise (ben niet zeker of deze gratis is of niet, een trial kan je wel downen)
...

En natuurlijk kan je (vr zowel J2EE als Dot Net) werken met gewone txt-editors...

alva848 zei:

Niet zo letterlijk dat niet.
In VB.net kan je wel rectangles vergelijken en een boolean terugkrijgen die aangeeft of er detectie is ( weet niet meer 100% hoe het werkt, dus het kan net iets anders zijn.).
Heb het ooit gebruikt voor Pong dacht ik.

Klik om te vergroten...

Dat kan best zijn hoor. Ik wilde gewoon een punt maken door te stellen dat je niet de heilige graal zal vinden door een boekje te lezen en dat niet alles kant en klaar al voor jou klaar ligt.

C/C++ raad ik enkel aan om te leren als je echt op low-level nog wilt gaan werken (games & meer hardware/os-gericht programmeren - met os bedoel ik dan op het niveau waarop os geprogrammeerd wordt, niet VOOR een bep os ). Als je "gewone" user-applications wilt ontwikkelen zal je veeleer al toekomen met c# of java. Deze zijn daarbij ook nog eens veel gebruiksvriendelijker (vooral als het anakomt op gui proggen ).

Maar laat ik je 1 ding zeggen: maar zeeeeeeeeeeer weinig mensen gaan ooit games programmeren hoor, en als je toch dat lowl-level werk (hardwareproggen) wilt doen zal je hiervoor zowiezo de juiste studies voor moeten doen waar ze je dat ook aanleren .

Jormungand zei:

Ik persoonlijk vind dat jij teveel hooi op je vork wil nemen in een keer. Ik wil maar zeggen, je kent op dit moment nauwelijks iets van eenderwelke programmeertaal en je wil al een mini-game programmeren. Boeken die specifiek over een bepaalde taal gaan, daar leer je NIETS anders mee dan DE TAAL (althans een stuk ervan, zeker niet alles). Nog iets, is zulke boeken zal je nooit de term "Collision Detection" vinden hoor, er bestaat niet een of andere functie doCollisionDetectionForMeSoIDontHaveToThink().

Klik om te vergroten...

Tja, het kan wel lukken. Ik ben zo begonnen met Turbo Pascal in DOS. Tutorials of leerboeken had ik niet (wel een paar tutorials voor de OOP-functies die Borland toen pas aan Pascal hadden toegevoegd, maar als je de basis niet kent...), ik begon gewoon door het referentieboek met alle elementen van de taal en syntax te lezen, dan de library functies, en dan een paar simpele testprogramma's gemaakt om die dingen te proberen. En dan meteen aan een sidescroller begonnen. Veel werk, veel dingen verkeerd gedaan, veel moeten herschrijven en opnieuw herschrijven, geprobeerd OOP toe te passen terwijl ik eigenlijk niet wist hoe, zelfs nog wat inline asm moeten leren om in mode 13h te raken. Maar uiteindelijk was er wel een werkend resultaat (en ja, ik weet dat de code er niet al te elegant uitziet):
users.telenet.be/wim.libaers/diamant.zip
Zal nu wel wat te snel werken op een nieuw systeem, want timing gebeurde op basis van een vaste refreshrate in mode 13h.

In die tijd was het natuurlijk wel makkelijker om zo te beginnen. Een paar instructies en je zat al in een grafische mode. Nu zit je voor een grafisch programma toch wel aan enkele schermen initialisatiecode, wat niet echt leuk is voor een nieuweling. En de beschikbare libraryfuncties leren door gewoon een referentieboek met alle functies van a tot z uit te lezen zou ik in het geval van Java of .NET ook niet meteen aanraden

Over het algemeen kan je twee fouten maken bij het leren van iets nieuws: alleen die dingen doen waarover je quasi zeker bent, maar dan leer je traag bij, of snel verder gaan en meer leren, maar ook wel wat ongelukjes meemaken onderweg.

Persoonlijk vind ik VB een taalje voor de kinder programmeurtjes onder ons, maar dat even ter zijde...

Klik om te vergroten...

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." - Edsger W. Dijkstra


(hij had overigens ook iets tegen OOP en "software engineering")

Neem eventjes een beetje raad aan van iemand die in het vak zit. Je moet keuzes maken. Welke taal? Waar wil je naartoe? Wat wil je nu juist doen? Wat is je motivatie om te leren programmeren?
Knoop goed in je oren dat er ook nog eens een groot verschil is tussen een taaltje kennen en OOP technieken beheersen. Het is niet omdat je perfect een taal kan dat je daarom ook een prachtig boek kan schrijven. Software Architecture en Design is een kunst op zichzelf en ikzelf leer nog dagelijks nieuwe dingen terwijl is reeds jaren in het vak zit. Je mag niet denken, en ik heb de indruk dat jij dat denkt, dat indien je een taal kent, je zomaar alles kan doen. NEEN, zulk een taal is een werktuig om jou creativiteit en vindingrijkheid uit te drukken zodat een computer doet wat je hem verteld, meer niet. Het is nog steeds jou denkwerk en creativiteit dat eraan te pas moet komen. Zeker als je met nieuwe dingen bezig bent moet je veel opzoekingen en research verrichten, zodat je een beetje in de juiste richting kan lopen. Er bestaat geen boek waar alles in staat, dat is gewoon niet mogelijk doordat je met een programmeertaal alle richtingen uit kan en je zelfs dingen kan doen die nog nooit door iemand anders zijn gedaan. Het boek dat jij las ging over Visual Basic en THAT's IT.

Klik om te vergroten...

En verder: OOP technieken beheersen is nog geen garantie dat je ook een goed programma maakt. OOP is een manier om een programma een zekere structuur te geven (en er zijn nog andere manieren, ik zou OOP zeker niet als de enige goede of altijd aan te raden methode beschouwen). Zelfs met de meest perfecte programmeervaardigheden kan je nog altijd een afschuwelijk gedrocht produceren als je niet zeker bent over wat je wil bereiken met je programma.

En verder: OOP technieken beheersen is nog geen garantie dat je ook een goed programma maakt. OOP is een manier om een programma een zekere structuur te geven (en er zijn nog andere manieren, ik zou OOP zeker niet als de enige goede of altijd aan te raden methode beschouwen). Zelfs met de meest perfecte programmeervaardigheden kan je nog altijd een afschuwelijk gedrocht produceren als je niet zeker bent over wat je wil bereiken met je programma.

Klik om te vergroten...

Ik ga toch van de veronderstelling uit dat als men OOP technieken BEHEERST, men ook weet wanneer en waarom men bepaalde technieken in bepaalde situaties toepast. Als dat niet zo is dan kan ik ook niet zeggen dat die persoon OOP technieken beheerst, maar slechts de beginselen ervan kent.

We moeten het meer algemeen stellen denk ik. Men moet beseffen dat het schrijven van code in een software ontwikkel proces slechts een STUKJE is van het ganse proces. Er is ook zoiets als het design, management, testing, etc... die allemaal samen werken, in een iteratief proces. De fout van beginnelingen is meestal dat men niet kan wachten om te beginnen met coderen en later tot het besluit komen dat ze eigenlijk een mesthoop ervan gemaakt hebben die niet te onderhouden is en dus ook enorm dure software blijkt te zijn. Er zijn ook vele amateur programmeurs die van zichzelf niet weten dat ze zeer slechte code schrijven, ze weten gewoon niet beter. Natuurllijk is dit voor de hobbyisten niet zo een geweldig probleem, de dingen die ze maken zijn meestal toch zeer beperkt in omvang. Maar ieder professioneel software ontwikkelaar weet waarover ik spreek.

Jormungand zei:

Er zijn ook vele amateur programmeurs die van zichzelf niet weten dat ze zeer slechte code schrijven, ze weten gewoon niet beter. Natuurllijk is dit voor de hobbyisten niet zo een geweldig probleem, de dingen die ze maken zijn meestal toch zeer beperkt in omvang. Maar ieder professioneel software ontwikkelaar weet waarover ik spreek.

Klik om te vergroten...

Daarin heb je zeker gelijk, maar de beste manier om te leren is uit uw eigen fouten. Zelfs hedendaags beginnende programmeurs mogen rommelige code schrijven en al doende zullen ze wel leren. Laat ze maar beginnen met het begin en vervolgens de smaak te pakken krijgen en zich dan verder verdiepen in architectuur modellen e.a.
Want, geef toe, je kan tientallen (honderden) artikels/boeken/tuts/... lezen vooralleer je maar 1 letter code geschreven hebt. Op den duur zie je 't bos niet meer door de bomen. Dus mijn raad is, begin gewoon simpelweg wat te experimenteren en rommelen en gaandeweg zal je je eigen code wel verbeteren, maar vergeet niet dat onwikkelen een continu leerprocess is, zelfs al ben je er al meer dan 15 jaar mee bezig (zoals ik) dan nog leer je elke dag nieuwe dingen bij.
Vergeet ook nooit voor u eigen na te denken. Het is niet omdat honderden/duizenden mensen zeggen dat, bijvoorbeeld OO, goed is, dat jij dat dan zomaar moet klakkeloos aanvaarden... Alles heeft zijn pros en cons...

Dus mijn raad is, begin gewoon simpelweg wat te experimenteren en rommelen en gaandeweg zal je je eigen code wel verbeteren, maar vergeet niet dat onwikkelen een continu leerprocess is

Klik om te vergroten...

Dat is inderdaad een feit, je leert het alleen door veel code ZELF te schrijven en daarbij ook te struikelen over de typische fouten die beginners maken. Van fouten leert men inderdaad nog het meeste.

Het is niet omdat honderden/duizenden mensen zeggen dat, bijvoorbeeld OO, goed is, dat jij dat dan zomaar moet klakkeloos aanvaarden... Alles heeft zijn pros en cons...

Klik om te vergroten...

Met deze stelling kan ik slechts gedeeltelijk akkoord gaan. Als er iets is waarvan men veel kan leren en waardevolle besluiten kan trekken, dan is het wel uit het verleden. En het verleden heeft keihard bewezen dat OOP, voor projecten van een relatief hoge complexiteit en omvang, een veel hogere kans op slagen geeft dan eender welke andere werkwijze. Dat is een feit, en het is naief (ik heb een qwerty keyboard) om dit in vraag te stellen.

Wat ik wel kan zeggen is dat het voor hobbyisten, waarschijnlijk, overkill is om zichzelf te verdiepen in geavanceerd OO design. Het zou ook teveel tijd kosten, want op dit vlak heb je nooit gedaan met leren. De dingen die ze maken zijn toch van beperkte omvang en complexiteit zodat je je het hier nog kan permiteren om bijvoorbeeld gewoon C-style te programmeren, of om slechte classes te ontwerpen. En het is een beginner zeker vergeven om fouten te maken of slechte code te schrijven, een programmeertaal leren is nu eenmaal een proces van continue leren en experimenteren, en dit geldt zeker voor complexe talen zoals C++.

Jormungand zei:

Met deze stelling kan ik slechts gedeeltelijk akkoord gaan. Als er iets is waarvan men veel kan leren en waardevolle besluiten kan trekken, dan is het wel uit het verleden. En het verleden heeft keihard bewezen dat OOP, voor projecten van een relatief hoge complexiteit en omvang, een veel hogere kans op slagen geeft dan eender welke andere werkwijze. Dat is een feit, en het is naief (ik heb een qwerty keyboard) om dit in vraag te stellen.

Klik om te vergroten...

Omdat tegenwoordig iedereen zomaar klakkeloos aanneemt dat OOP de manier van werken is, vind ik het zeker niet naief om dit in twijfel te trekken, zelf voor grote projecten. Ok, in Java en .NET (ea) omgevingen werk je automatisch OO, maar je kan er ook in overdrijven. Op vele grote projecten (projecten van enkele duizenden mandagen en meer) heb ik al regelmatig gezien dat men eerst een framework bouwt en dan hierop verder de applicatie ontwikkeld. Dat is een technisch goede manier van werken, maar daarom niet de beste. Als ik dan vraag aan de technische architecten waarom ze 't niet veel simpeler (en dus sneller en goedkoper) doen, dan krijg ik hier zelden of nooit een duidelijk antwoord op. Meestal is 't zo van: Je kan nu veel meer code herbruiken, het is meer scalable en de klant heeft de mogelijkheid om erop verder te bouwen vr andere applicaties. Maar in de praktijk achteraf als je dan eens terugkomt bij de klant gebeurt dat redelijk weinig. Dus al die tijd en geld die er meer inkruipt om het op de echte OO wijze te doen, brengt in zeer weining gevallen op. Het duurt zeer lang voor je iets af hebt wat de klant al effectief kan gebruiken.
Zeker op kleinere projecten, waar de lifecycle van het afgewerkt product meestal niet lang is, loont het soms wel de moeite om iets snel te bouwen, zonder al te veel ingewikkelde OO dingen erin te bouwen.
Wat je tegenwoordig fel opmerkt is dat men toch begint terug te komen van de OOP-boom die er geweest is.
Wat ik ook wel grappig vind is dat men telkens opnieuw voor elk nieuw project begint vanaf nul. Dit omdat die projecten meestal lang duren (enkele jaren) en tegen dat het af is de technologie niet heeft stilgestaan... En dan komt er van code-reuse ook weinig in huis...
Samengevat vind ik (imho) OOP zeer mooi theoretisch, maar in de praktijk zeer weinig ROI...