[Alg] beste programmeertaal om mee te beginnen?

[Creepy]

Verwijderd schreef op 27 november 2003 @ 12:11:
Ook een nadeel aan C is dat het over het algemeen console apps zijn. het is heel moeilijk om in C een gui te maken en C is een beetje outdated en kan bv niet makkelijk met nieuwe hardware praten...

offtopic:
Psst: de drivers voor de meeste hardware zijn/worden nog steeds in C geschreven. Desnoods in C++, maar voor al het lowlevel gebeuren (het echte bitneuken zeg maar) wordt standaard C of zelfs assembly gebruikt).

En in C kan ik prima een GUI bouwen.. ligt aan de gebruikte tools en library maar GTK is toch echt C (en geen C++!).

[Riegstar]

De .NET omgeving is voor ieder wat wils en bied genoeg ingangen.
Ik bedoel, je kan er met diverse talen op programmeren: VB.NET, C#, J# enz.
Maar een nadeel van .NET omgeving is dat het framework niet goed draait op oudere windows.
En als je VisualStudio .NET wilt gebruiken als ontwikkel tool, heb je bovendien een stevige PC nodig met plenty geheugen.

Dus de antwoord op de vraag: "Welke programmeertaal is het beste om mee te beginnen" hangt dus ook af van wat voor hardware je hebt en welke besturingssysteem je gebruikt.

[Verwijderd]

ik zou beginnen met iets simpels als ik jou was?
wat ik zo gelezen heb, heb je nog amper/geen programmeer ervaring.

Heb je al een website? Probeer anders een zoiets te maken, met een database erachter enz enz, gewoon als zandbak.
Een boek kopen en maar een paar "hello worlds" maken heeft voor mij nooit gewerkt. Pas als je een uitdaging hebt die je ook ECHT wilt volbrengen ga je door, door die ellende van het zoeken naar die ene fout, de perfecte functie en de stress van een verborgen ; die daar niet hoord!

Trekt de hele ebiz je niet, maak dan een leuke divx store applicatie met titels, omschrijvingen, genres, nummers, uitleners, datums enz enz of iets anders wat echt een "practisch" doel bied.

Verder zal ik me niet uitlaten over geschikte beginnerstalen aangezien ik alleen php, asp.net, c++ en een klein beetje java ervaring heb.
Een website maken is opzich een aanrader aangezien daar ZOOOO onwijs veel informatie (ook bergen nederlands) over te vinden is.

succes!

[djlinsen]

whoami schreef op 27 november 2003 @ 12:02:
[...]

Dit is kortzichtig.
Met Delphi kan je evengoed een groot project ontwikkelen, als met C#, Java, ....

Ben ik het wel met je eens dat het kortzichtig is, tis alleen niet mijn eerste keus.

[Orphix]

Ik zou ook voor C# gaan, zoals D4Skunk het uitlegt. Waarom? Nou:
- C# heeft geen pointers ja, maar als je meer in C# bezig bent leer je ook het verschil tussen reference-types en value-types. Ik snap niet waarom je zoiets als pointers perse zou willen.
- Voor .Net is zeer veel informatie te vinden en wordt breed ondersteund.
- Je hebt al snel iets leuks in elkaar gezet (houdt de motivatie hoog)
- Het kan geheel gratis
- Makkelijke overstap naar web-based programmeren dmv asp.net
- Programmeren via click 'n play... ok ik weet hoe mensen hier tegenaan kijken maar in het begin is het erg makkelijk dat je kan dubbelklikken op een button en dan direct een eventhandler kan schrijven ipv dat je zelf dat event moet gaan koppelen (=moeilijker).

[curry684]

Verwijderd schreef op 27 november 2003 @ 12:11:
[...]
mmmm c is ook niet helemaal platform onafhankelijk.... ligt aan de librarys die je importeerd. Als je de verkeerde pakt dan kent bv linux deze niet...

Dat heb je in iedere taal. Als je in voor mijn part Lisp een platformdependent framework pakt is het niet portable, anders wel.

Ook een nadeel aan C is dat het over het algemeen console apps zijn. het is heel moeilijk om in C een gui te maken en C is een beetje outdated en kan bv niet makkelijk met nieuwe hardware praten...

Uhm dit is dus echt je reinste onzin. De hele Win32 API is C en geen enkele regel C++.

C++ komt weer beter in de richting van het moderne leven, maar heeft als nadeel niet echt goed overdraag baar te zijn.... Linux kan wel C++ lezen maar de windows GUI kan weer niet, want linux kent bv GTK+ als GUI

Ook onzin. GTK is een layer bovenop de XLib, net zoals bijvoorbeeld MFC en VCL dat zijn op Win32. XLib is net als Win32 100% C.

Delphi kan ook op linux (via kylix)

Delphi en Kylix zijn niet uitwisselbaar, ze gebruiken een ander framework.

C# is wel beter als je windows proggies gaat maken,omdat het microsoft is is de implementatie wat beter binnen hte windows model...

.NET loopt per definitie wat achter op de Win32 API. Je bent dus met een C programma dat Win32 gebruikt per definitie 'moderner'.

Maar als je OO en platform onafhankelijk wilt moet je Java doen... Die gui draait op alles waar een Virtual machine voor is te krijgen....

Mjah Java platformindependent is een leuk fabeltje maar ondertussen goed achterhaald. Zodra je iets serieus buiten je app wil doen moet je echt platformspecifieke onderdelen gaan includen.

Maar programmeer talen zijn natuurlijk heel persoonlijk

Ik vind ze juist heel onpersoonlijk, als ik in C tegen iemand ga praten zijn ze meestal beledigd

[bigtree]

Alarmnummer schreef op 27 november 2003 @ 12:23:
Waarom altijd beginnen met de 'gebruikelijke' talen.

Omdat er
- meer documentatie voorhanden is voor gebruikelijke talen
- meer code-voorbeelden te vinden zijn voor gebruikelijke talen
- meer vraag is naar programmeurs in gebruikelijke talen



Wel grappig trouwens, ik noemde BASIC eigenlijk als grap omdat je er nauwelijks nog een 'hedendaagse' applicatie mee kan maken, vanwege geen GUI-mogelijkheden. Toch kreeg ik van diverse kanten bijval, waarschijnlijk omdat er meer tweakers zijn begonnen met een C64 (of Atari zoals ik ). Qua taal is BASIC prima om mee te beginnen, net zo goed als Pascal trouwens. Maar beide hebben geen GUI-mogelijkheden om leuke dingetjes mee te proberen. Dan kom je snel op VB of Delphi. Het ligt er maar aan wat de topicstarter belangrijker vindt: leren programmeren of applicaties maken. Oftewel; zie je programmeren als doel of als middel?

[Creepy]

curry684 schreef op 27 november 2003 @ 12:53:
Delphi en Kylix zijn niet uitwisselbaar, ze gebruiken een ander framework.

Delphi heeft de VCL. Kylix de CLX. Maar Delphi 6 en 7 ondersteunen ook allebei de CLX om Kylix apps dus source code compatible te maken met Delphi 6 en 7.

[Riegstar]

Als je begint met programmeren wil je graag resultaat zien. Dus het gaat erom snel krijg ik "Hello world" en hoe ingewikkeld is het om dit aan te passen.
Dat motiveert weer om verder te gaan.

[Alarmnummer]

bigtree schreef op 27 november 2003 @ 12:59:
[...]
Omdat er
- meer documentatie voorhanden is voor gebruikelijke talen

Er is meer documentatie uit voor 'gekke' talen zoals Prolog, dan jij ooit in je leven zult lezen

- meer code-voorbeelden te vinden zijn voor gebruikelijke talen

Zelfde als hierboven.

- meer vraag is naar programmeurs in gebruikelijke talen

Als je voor het eerst een hamer krijgt, dan ziet alles eruit als een spijker

Ik ben van mening dat voor veel oplossingen de verkeerde taal wordt gekozen. Talen zoals prolog zijn uitermate geschik voor de meeste bedrijfslogica en zou ook veel beter beheerd kunnen worden als het niet hard in de code werd geprogrammeerd.

Je moet dus de juiste taal kiezen voor een bepaald probleem (het is natuurlijk wel erg fijn als je alles met elkaar kan combineren, anders heb je alsnog een groot probleem).

Wel grappig trouwens, ik noemde BASIC eigenlijk als grap omdat je er nauwelijks nog een 'hedendaagse' applicatie mee kan maken, vanwege geen GUI-mogelijkheden. Toch kreeg ik van diverse kanten bijval, waarschijnlijk omdat er meer tweakers zijn begonnen met een C64 (of Atari zoals ik ). Qua taal is BASIC prima om mee te beginnen, net zo goed als Pascal trouwens. Maar beide hebben geen GUI-mogelijkheden om leuke dingetjes mee te proberen. Dan kom je snel op VB of Delphi. Het ligt er maar aan wat de topicstarter belangrijker vindt: leren programmeren of applicaties maken. Oftewel; zie je programmeren als doel of als middel?

Ik zou geen basic aanrader, maar dan gewoon pascal.

c zou ik trouwens ook niemand willen aandoen, want het is gewoon een lelijke k*t taal die onnodig cryptisch is. Imho totaal ongeschikt om te leren programmeren.

[ Voor 9% gewijzigd door Alarmnummer op 27-11-2003 13:23 ]

[curry684]

Alarmnummer schreef op 27 november 2003 @ 13:17:
c zou ik trouwens ook niemand willen aandoen, want het is gewoon een lelijke k*t taal die onnodig cryptisch is. Imho totaal ongeschikt om te leren programmeren.

Onderbouwing?

C ligt heel dicht tegen assembler aan, en ondersteunt daarom "lelijke cryptische constructies" zoals pointers. Begrip van pointers levert je heel veel begrip op voor hoe een computer van binnen werkt, en daarmee het inzicht om snelle goed geoptimaliseerde constructies te implementeren.

Ik ben al vaak genoeg programmeurs tegengekomen die van hun leven enkel Java en VB hadden gezien en echt niet de vaagste notie hadden van hoe een computer z'n geheugen ordent en wat het verschil is tussen stack en heap geheugen en zo. Dat zijn de k*tprogrammeurs die ik niet in m'n team hoef, laat ze dan maar eerst een lelijk cryptische k*ttaal leren die ze dat onmisbare inzicht wel verschaft.

[Alarmnummer]

curry684 schreef op 27 november 2003 @ 14:05:
[...]

Onderbouwing?

Ok...

Afgezien van wat rommelige type notaties en volledig ontbreken van booleans het volgende:

&&, ||, ! voor een and, or en not.

Natuurlijk al het geouwehoer met die pointers (ipv een var keyword zoals bij pascal), en wat dacht je van die akelige import functies.

[edit]
Ik heb maar geen commentaar geleverd over de macro`s, want alle krachtige featurs kunnen misbruikt worden.

C ligt heel dicht tegen assembler aan, en ondersteunt daarom "lelijke cryptische constructies" zoals pointers.

C is heel krachtig, maar daarom hoeft de syntax niet onnodig lelijk te zijn.

Begrip van pointers levert je heel veel begrip op voor hoe een computer van binnen werkt, en daarmee het inzicht om snelle goed geoptimaliseerde constructies te implementeren.

Helemaal mee eens. Iemand die quake in java gaat proggen, verklaar ik ook terplekke voor gestoord.

De vraag of dit nodig is voor het goed leren proggen.

Ik ben al vaak genoeg programmeurs tegengekomen die van hun leven enkel Java en VB hadden gezien en echt niet de vaagste notie hadden van hoe een computer z'n geheugen ordent en wat het verschil is tussen stack en heap geheugen en zo. Dat zijn de k*tprogrammeurs die ik niet in m'n team hoef, laat ze dan maar eerst een lelijk cryptische k*ttaal leren die ze dat onmisbare inzicht wel verschaft.

Tja.. in java heb je dat inzicht niet nodig. Je hebt dan tijd om andere dingen te leren. Je moet je heel goed afvragen of je deze kennis ook nodig hebt aan het begin.

[ Voor 5% gewijzigd door Alarmnummer op 27-11-2003 14:21 ]

[whoami]

Alarmnummer schreef op 27 november 2003 @ 14:19:
[...]

Natuurlijk al het geouwehoer met die pointers (ipv een var keyword zoals bij pascal), en wat dacht je van die akelige import functies.

Een pointer in C/C++ is niet hetzelfde als een var keyword in Pascal.
Als je in Pascal een variable doorgeeft aan een functie met het var keyword, dan is dat hetzelfde als een variabele by reference passen in een C/C++ functie.

Een reference en een pointer zijn afaik niet hetzelfde.

C is heel krachtig, maar daarom hoeft de syntax niet onnodig lelijk te zijn.

Tja, da's een kwestie van smaak.
Ik vind de C++ syntax niet mis.

[Alarmnummer]

whoami schreef op 27 november 2003 @ 14:22:
[...]

Een pointer in C/C++ is niet hetzelfde als een var keyword in Pascal.
Als je in Pascal een variable doorgeeft aan een functie met het var keyword, dan is dat hetzelfde als een variabele by reference passen in een C/C++ functie.

c++ heeft dit er gelukkig bij in gekregen, maar c niet (daar zit je dus wel vast aan al die pointer extra`s). Ik moet er trouwens wel bij vertellen dat ik eigelijk geen c meer hebt geprogt (serieus) na turbo c 2.0.

En verder went het uiteindelijk ook wel, maar ik zie de toegevoegde waarde er neit van in. Java (of c#) leest gewoon lekker, geen gezeik met pointers ed. Je beperkt je gewoon meer tot de essentie van het verhaal en laat de vm maar uitzoeken hoe hij het wil aanpakken. Je verliest misschien wat controle, maar dat heb ik eerlijk gezegd nog niet nodig gehad. Zie het als het verschil tussen declaratief en procedureel proggen. Bij declaratief proggen beperkt je meer tot de essentie van het verhaal en met procedureel niet. Een declaratief programma is daarom korter, dus beter te lezen, dus bug vrijer. Tja.. en misschien wat langzamer..

[ Voor 44% gewijzigd door Alarmnummer op 27-11-2003 14:30 ]

[whoami]

Alarmnummer schreef op 27 november 2003 @ 14:25:
[...]

c++ heeft dit er gelukkig bij in gekregen, maar c niet. Ik moet er trouwens wel bij vertellen dat ik eigelijk geen c meer hebt geprogt (serieus) na turbo c 2.0.

Passing by reference kent C idd niet, maar ik weet niet of ze het principe references niet kennen...

[farlane]

Alarmnummer schreef op 27 november 2003 @ 14:19:
Tja.. in java heb je dat inzicht niet nodig. Je hebt dan tijd om andere dingen te leren. Je moet je heel goed afvragen of je deze kennis ook nodig hebt aan het begin.

Vind ik wel. Hoe vaak ik al niet ben tegengekomen dat iemand in VB een object variabele declareert en hem toewijst aan een andere, in de veronderstelling dat ie een kopie maakt van het originele object. ( Java is hetzelfde verhaal ).

Als die man had geweten wat pointers/references zijn dan had ie meteen gezien dat er niets van het object wordt gekopieerd, maar dat ie een tweede pointer naar hetzelfde object in zijn hand heeft.

Zo zijn er nog wel meer voorbeelden te verzinnen. ( Tel het aantal topics over bitpielen met de serieele / paralelle poort maar eens )

[Alarmnummer]

farlane schreef op 27 november 2003 @ 14:36:
[...]
Vind ik wel. Hoe vaak ik al niet ben tegengekomen dat iemand in VB een object variabele declareert en hem toewijst aan een andere, in de veronderstelling dat ie een kopie maakt van het originele object. ( Java is hetzelfde verhaal ).

Als die man had geweten wat pointers/references zijn dan had ie meteen gezien dat er niets van het object wordt gekopieerd, maar dat ie een tweede pointer naar hetzelfde object in zijn hand heeft.

Enige kennis is idd wel nodig, en je kan denk ik in 5 minuten wel uitleggen wat een object is, en wat een referentie naar het object is *ziet al een erg eenvoudig schema voor zich*. Maar dit wil niet zeggen dat je er steeds op moet letten, en dat je ook onderscheid moet maken tussen stack en heap gereserveerd geheugen. Ik vind het persoonlijk echt bijzaken en imho kan je je in het begin beter concentreren op allerlei andere interessante zaken zoals recursie, backtracken, zelf types maken etc. Daar ben je echt niet veel pointer kennis bij nodig.

Zie bv pascal. Pascal is ontwikkeld om studenten te leren programmeren. Schijnbaar vonden ze toen al dat pointers in het begin niet erg belangrijk waren om de essentie achter programmeren te leren. Anders hadden ze al die extra pointer notaties uit c wel overgenomen en het var keyword weggelaten.

c is imho totaal ongeschik om mensen mee te leren proggen.

[ Voor 17% gewijzigd door Alarmnummer op 27-11-2003 14:42 ]

[curry684]

whoami schreef op 27 november 2003 @ 14:28:
[...]
Passing by reference kent C idd niet, maar ik weet niet of ze het principe references niet kennen...

C kent totaal geen references, maar in principe is een reference niets anders dan een pointer die gegarandeerd naar een geldig object wijst (er zijn wel null-pointers maar geen null-references).

Het grootste voordeel van de reference is dat ie dus minder error-prone is (je kunt 'm niet vergeten te initializeren) en dat ie notationeel een stuk schoner is (je hoeft niet te dereferencen of address-of operators te gebruiken). Implementatietechnisch zijn ze verder eigenlijk gewoon hetzelfde.

edit:
en met references kun je trouwens geen ranzige botergeile pointerarithmetic uithalen

[ Voor 7% gewijzigd door curry684 op 27-11-2003 14:45 ]

[farlane]

curry684 schreef op 27 november 2003 @ 14:43:

edit:
en met references kun je trouwens geen ranzige botergeile pointerarithmetic uithalen

* farlane heeft op dit moment een merkwaardig beeld van curry684 achter zijn compiler voor zun ogen

Gelukkig, het is alweer weg .....

[Alarmnummer]

farlane schreef op 27 november 2003 @ 14:50:
[...]


* farlane heeft op dit moment een merkwaardig beeld van curry684 achter zijn compiler voor zun ogen

Gelukkig, het is alweer weg .....

brrr... *heeft nu het beeld*... dankje

[ Voor 5% gewijzigd door Alarmnummer op 27-11-2003 14:51 ]

[Verwijderd]

Ik zou toch voor python (www.python.org)
Deze taal is net zo makkelijk te leren als basic, maar enorm krachtig
- cross-platform
- goede online tutorials
- enorm object georienteerd (alles zijn objecten)
- leesbaar (in tegenstelling tot bv perl en php vaak)
- eenvoudige string handling (geen gedoe met buffers zoals in C)
- goede basis datatypes zoals lijst, dictionary, arbitrary length integer
- heeft een command line interpreter om makkelijk even contstructies uit te proberen zonder iets te hoeven compileren
- elegant, geen enorme kluwen code om eenvoudige dingen te doen
- grote toepasbaarheid, het wordt gebruikt voor command line tools, gui's, games (bijvoorbeeld de MMORPG Eve), servers, dynamische webpagina's

[ Voor 7% gewijzigd door Verwijderd op 27-11-2003 14:58 ]

[PeeJay]

Ikzelf geef de voorkeur aan Java. Ik ben ook met c++ begonnen en kan beide, maar java gaat toch soepeler.
Een klein java progje (5000 regels), kan je in een klein uurtje ombouwen naar C++.
Assembly moet je links laten liggen, dat is echt niet leuk

En BASIC, tja, dat heb ik nooit geleerd en ben ook niet van plan dat te doen.

[Glimi]

Nou, fase één hebben we al bereikt, iedereen heeft z'n favoriete taal geplugt? Mooi. Het wachten is nu op fase 2, waarin we gaan ranten op elkaars aanbevelingen

Serieus, hoe denkt iedereen toch te weten 'wat het beste is'. Wat weten we nou? 'Ik wil ooit een spel programmeren' tja, dat kan ook in Haskell zeg maar
Belangrijker is wat de TS wil leren en wat hij er voor over heeft. Wil je leren programmeren om meer te leren over informatica en dat ook echt _willen_, dan zou ik een mix van low level/high level geörienteerde taal proberen, zoals C++. Wil je gewoon wat kunnen programmeren om wat te doen aan softwaredesign, concentreer je dan meer op een meer high level taal als Java/Phyton. Wil je vervolgens toch de 'snel resultaat'-methode, dan zijn dingen als PHP en consorten weer de aangewezen talen.

Het draait imho dus allemaal om hoeveel de persoon wil investeren en wat hij/zij er mee wil leren.

[farlane]

PeeJay schreef op 27 november 2003 @ 15:01:
Een klein java progje (5000 regels), kan je in een klein uurtje ombouwen naar C++.

Hmm, dat lijkt me sterk afhankelijk van wat er in die 5000 regels allemaal gebeurt ....

[farlane]

Alarmnummer schreef op 27 november 2003 @ 14:51:
brrr... *heeft nu het beeld*... dankje

Erg he ?

[mbravenboer]

Glimi: Nou, fase één hebben we al bereikt, iedereen heeft z'n favoriete taal geplugt? Mooi.

(stel je martin voor met z'n vinger heel hoog in de lucht)
ikke nog niet! .

Maar goed, laat ik daar ook maar niet over beginnen. Ik voel wel wat voor de Python tips, als het idee achter deze tipis inderdaad aansluit op de situaties van de topic starter.

[PeeJay]

farlane schreef op 27 november 2003 @ 15:05:
[...]


Hmm, dat lijkt me sterk afhankelijk van wat er in die 5000 regels allemaal gebeurt ....

Redelijk standaard functies. Geen slechte random functies die in C++ zitten enzo.
Ik doelde eigenlijk meer op de opbouw met classes. In java gebruik je geen headerfiles en werkt prototyping anders.
De aanroepen van functies moet je wel langslopen idd.
Maar 5000 regels is niet zoveel met een menu en wat ander grafisch spul erin

[OkkE]

De topicstart doet mij denken aan mezelf een jaar of wat geleden.. Ik ging leren programmeren, want al die software en games waren zo gewelig, dat wilde ik ook kunnen. Toen ook info gezocht en vanalles...... en nu? Nog steeds niet veel van terecht gekomen, zit nu op me stage PHP scripts te schrijven.
Niet dat ik wil zeggen dat de topicstarter net als mij is, maar ik denk dat er veel mensen het ook graag willen en denken dat het wel "even" te leren is. Maar ik wens de topicstarter natuurlijk veel succes.

[Deviator79]

Op de HEAO begonnen we op dag 1 met Java en daarna door met Cobol

* Deviator79 haakte na dag 1 al af..

[.oisyn]

Alarmnummer schreef op 27 november 2003 @ 14:19:
Natuurlijk al het geouwehoer met die pointers (ipv een var keyword zoals bij pascal), en wat dacht je van die akelige import functies.

dat klopt niet, een pointer in pascal doe je met ^, net zoals een * in C. Zoals whoami al aangaf is var alleen maar voor references. Of wil je een array van C-style strings gaan definieren als var var char

Ik had het er laatst nog met iemand op #devschuur over (Creepy geloof ik) dat pascal juist een wat irritanter type-notatie-systeem heeft, omdat je niet elk type in 1 regel kan opschrijven. Een pointer naar een pointer naar int kun je niet definieren als ^^Int, daar heb je een ander subtype voor nodig.

Het wachten is op Visual C++ whidbey, waarbij je managed en unmanaged code perfect kan mixen. Managed pointers en references krijgen dan een andere notatie (resp. ^ en %)

Ik heb maar geen commentaar geleverd over de macro`s, want alle krachtige featurs kunnen misbruikt worden.

oh, dus ze moeten maar weggelaten worden, omdat het misbruikt kan worden Vind ik een erg kromme redenering (die ik overigens wel vaker hoor). Alsof we beschermd moeten worden tegen onszelf. Laten we dan pointers ook maar afschaffen, anders kan ik dit doen:

C++:

int main ()
{
    int * ptr = reinterpret_cast<int *> (rand ());
    *ptr = 1234;
}

Macro's zijn gewoon enorm handig voor compile-time conditionele code (bijvoorbeeld verschillen tussen debug en release builds), en assertions e.d.. Dat zijn dingen die ik echt mis bij andere talen

C is heel krachtig, maar daarom hoeft de syntax niet onnodig lelijk te zijn.

da's subjectief. Ik vind perl cryptisch, C is imho heel goed leesbaar. Het zit 'm denk ik in het feit dat veel C programmeurs ook cryptische namen voor hun variabelen en functies gebruiken (kijk bijvoorbeeld eens naar de linux API ). Dat kun je nauwelijks C zelf kwalijk nemen. Oh wacht, we moeten natuurlijk tegen onszelf beschermd worden, dus laten we identifiers van minder dan 8 tekens maar verbieden (beetje overdreven natuurlijk, maar alleen om het even te relativeren )

[.oisyn]

curry684 schreef op 27 november 2003 @ 14:43:
Implementatietechnisch zijn ze verder eigenlijk gewoon hetzelfde.

^{met uitzondering dat de check voor null niet hoeft bij casts}

PeeJay schreef op 27 november 2003 @ 15:01:
Ikzelf geef de voorkeur aan Java. Ik ben ook met c++ begonnen en kan beide, maar java gaat toch soepeler.

het is natuurlijk subjectief, maar ik denk dat je dan niet genoeg ervaren was in C++. Memory-management zijn vooral dingen waar je problemen mee gaat krijgen in het begin, maar waarbij je als ervaren programmeur gewoon absoluut geen moeite meer mee hebt. Bovendien is de STL zo ongelooflijk veel productiever dan java's collections, zelfs met generics (in 1 tel kan ik een dynamische array van ints gebruiken waarbij ik kan invoegen en verwijderen. Hoe lang duurt het in java voordat je zoiets hebt opgezet? Goed, en nu hetzelfde verhaal als je er ook een voor doubles nodig hebt). Templates, operator overloading en references maken het programmeerleven echt zoveel gemakkelijker

Een klein java progje (5000 regels), kan je in een klein uurtje ombouwen naar C++.

Dat betwijfel ik ten zeerste. 5000 regels vind ik niet bepaald klein (comments tellen niet mee natuurlijk), dat code je denk ik niet in een week als je er ook nog over na moet denken (en dus niet simpel typwerk, zoals het ophalen of initialiseren van allerlei data enzo)

[ Voor 73% gewijzigd door .oisyn op 27-11-2003 16:40 ]

[Alarmnummer]

.oisyn schreef op 27 november 2003 @ 16:31:
[...]
dat klopt niet, een pointer in pascal doe je met ^, net zoals een * in C. Zoals whoami al aangaf is var alleen maar voor references. Of wil je een array van C-style strings gaan definieren als var var char

Ik wil ermee zeggen dat je in pascal niet zo snel naar een pointer hoeft te grijpen omdat je door een var al dmv reference kan doorgeven.

oh, dus ze moeten maar weggelaten worden, omdat het misbruikt kan worden Vind ik een erg kromme redenering (die ik overigens wel vaker hoor). Alsof we beschermd moeten worden tegen onszelf. Laten we dan pointers ook maar afschaffen, anders kan ik dit doen:

Ik denk dat je het dan nog even goed moet lezen, het was positief bedoelt. Macro`s worden over het algemeen een schadelijk c element gevonden, omdat je het dus kan misbruiken. Maar iedere krachtige feature kan misbruikt worden. Ik heb dus geen problemen met macro`s (en zou zelfs willen dat ze in java terug te vinden zijn)

[.oisyn]

Ah ok, dan heb ik je opmerking verkeerd geinterpreteerd, sorry
(en derhalve is de helft van mijn post gelijk tot niet relevant verklaard, voor niets zitten typen )

[Alarmnummer]

Java heeft sinds kort het assert commando. Hierdoor kan je in ieder geval optioneel alle zware berekeningen laten uitvoeren (handig voor het debuggen). Maar je mag het niet gebruiken bij publieke methodes (en ook niet bij protected), dus je kan het maar beperkt inzetten aangezien ik toch graag mijn classes in verschillende packages indeel.

Dit zou met Macro`s ook opgelost kunnen worden, maarja... een betere assert functionaliteit was ook een oplossing geweest

[Verwijderd]

Zelf ben ik begonnen in basic [op een msx, lekker traag] toen ik 3/4 was. Let op: begonnen! dus ik beweer niet dat ik sockets aanstuurde op mn 4e verjaardag. Basic is imho erg makkelijk om mee te beginnen, met name visual basic dan. Je bouwt in enkele minuten een grafische interface, en de taal zelf programmeert lekker. De compiler is lekker soepel.
Alleen is basic natuurlijk niet een snelle taal. Hoewel de performance van VB aardig is, is het toch nog steeds niet aan te raden om een 3d game te bouwen in VB.

[drm]

Even wat dingen die me te binnen schieten:

Volgens mij is er geen beste programmeertaal om mee te beginnen. Er is alleen maar een goede stok achter de deur nodig om te leren programmeren. Als je een grote opdracht (of een goed idee) krijgt om weet ik wat voor toepassing te schrijven, moet je eens opletten hoe snel je dingen onder de knie hebt.

Het heeft geen enkele zin om te zeggen "Ik ga leren programmeren". Het heeft alleen maar zin om te zeggen 'Ik ga dit en dit maken, wat zou ik daar het beste voor kunnen gebruiken'. Vaak kom je dan bij php terecht als het gaat om eenvoudige website-toepassingen en bij delphi/vb/java voor clientside toepassingen. C++ is volgens mij (in de praktijk) vaak iets wat je pas later "aandurft". Niet omdat het zo moeilijk is maar omdat er eenvoudiger (lijkende) alternatieven voor het grijpen liggen.

Verder zal je keuze vooral afhangen van smaak; wat je wel/niet mooi vindt. Elke taal heeft zijn eigen voor- en nadelen (de een wat meer voor dan nadelen ). Je zult het nooit weten als je er niet eens wat mee geknoeid hebt.

Tot slot is er niemand die assembly in gaat zetten voor een webapplicatie en niemand die C# gebruikt om een wasmachine aan te sturen (hoewel ...?). Go figure

[.oisyn]

Verwijderd schreef op 27 november 2003 @ 17:58:
Zelf ben ik begonnen in basic [op een msx, lekker traag] toen ik 3/4 was.

het spijt me zeer, maar op je 6e leer je pas lezen/schrijven op de nederlandse school. Ik geloof er dus geen fluit van

[Verwijderd]

mischien een tip voor (beginnende) coders;
http://proce55ing.net/
een leuke taal gebaseerd op java, (nog wel in de alpha-fase)

En denk dat een beginnende coder tijd nodig heeft om dingen te snappen,
fietsen leer je ook niet in 1 dag.

mijn coding experience door de jaren heen;
basic - zx-spectrum/C64
assembler - zx-spectrum
basic - amiga
c - amiga
assembler - amiga

nu oa. java, c, c++ & (actionscript & lingo. ahum)
en python aan het uitchecken.

[bigtree]

Als het gaat om het leren programmeren, is de ene taal wel degelijk beter dan een andere. Zo lang een taal maar een soort van PRINT of IF-THEN-ELSE kent, kan je er al wat oefeningen mee doen. Dan dus liever een omgeving die lekker laagdrempelig is. Want om nou een pakket van 300MB te installeren om een 'Hello world' op het scherm te krijgen... beetje overkill.

[Verwijderd]

Tja ik zou met een echt object georieenteerde taal want dat begint telkens belangrijker te worden. Ik denk dat je niet zo zeer moet kijken waarmee je het beste kan beginnen maar welke taal je het beste kan gebruiken voor de doeleinden die je uiteindelijk met het daadwerkelijke programmeren later wil gaan bereiken.

[Macros]

Bovendien is de STL zo ongelooflijk veel productiever dan java's collections, zelfs met generics (in 1 tel kan ik een dynamische array van ints gebruiken waarbij ik kan invoegen en verwijderen. Hoe lang duurt het in java voordat je zoiets hebt opgezet?

Ik heb geleerd te programmeren met Java, later ben ik veel PHP gaan gebruiken en ik heb een tijd niet echt begrepen wat er met generics werd bedoelt. Toen ik een aantal maanden serieus aan C ging beginnen en voor mijn opleiding moest werken aan een compiler voor een vaag taaltje om te leren compiler bouwen, wat een mengsel is tussen pascal en c (zie je het voor je? hehe) kwam ik er achter wat generics is.

In C++ is generics geimplementeerd als templates, wat inderdaad een heel erg krachtig en flexibel systeem is, wat Java niet heeft, maar alles wat je met generics kan, kan je ook en flexibeler (wel langzamer) met Objects in Java en PHP heeft er al helemaal geen last van omdat die helemaal geen typing heeft. Een dynamische array van ints in Java is in 2 seconden gemaakt natuurlijk. Men nemen een Vector en stoppen daar Integer objecten in. Het zal niet zo snel zijn als een statische array van ints, maar Java is toch niet bedoeld om te concureren op snelheid met C++, wat het 10 van de 10 keer toch zal verliezen, vanwege de VM, en zelfs als het compiled is de run-time checks op bijna alles terwijl C++ helemaal niks checked.

PS. Ik heb wel gehoord dat generics waarschijnlijk wel in Java 1.5 komt.
PSS. Ook leuk in Java (en SmallTalk en niet C++ (wel met speciale tools)) is Reflection. Kan je ook leuke dingen mee doen.

[.oisyn]

Macros schreef op 27 november 2003 @ 19:59:
In C++ is generics geimplementeerd als templates,

nou nee, generics zijn fundamenteel anders dan templates

wat Java niet heeft

java kent wel generics (niet standaard overigens nee, werd het niet standaard sinds 1.5?)

maar alles wat je met generics kan, kan je ook en flexibeler (wel langzamer) met Objects

Nou dat is het hele idee. Generics is syntactische suiker om vervelende casts e.d. niet zelf te doen. Want waarom steeds casten als je weet dat elk element in een java.util.Vector een MijnKlasse is ipv een Object. Die casts worden er dus omheen gevouwen door generics

Een dynamische array van ints in Java is in 2 seconden gemaakt natuurlijk. Men nemen een Vector en stoppen daar Integer objecten in.

gemaakt ja, maar niet echt goed bruikbaar door alle casts. Bij primitives moet je ze eerst nog boxen, en je moet ook nog eens het zootje gaan casten voordat je het eruit haalt.

vergelijk

C++:

for (size_t i = 0; i < numbers.size (); i++)
    som += numbers[i];

met

Java:

for (int i = 0; i < numbers.size (); i++)
    som += ((Integer)numbers.elementAt (i)).intValue ();

De hele tijd casten en methods aanroepen is gewoon een pain in the ass imho. En het feit dat de java-variant niet type-safe is (in de C++ vector kun je er alleen ints in stoppen, in de java vector kan alles erin)

[ Voor 5% gewijzigd door .oisyn op 27-11-2003 20:26 ]

[Alarmnummer]

.oisyn schreef op 27 november 2003 @ 20:24:
[...]
nou nee, generics zijn fundamenteel anders dan templates

Als je je niet al te veel gaat verdiepen in de technische verschillen, dan is templates imho generics.

java kent wel generics (niet standaard overigens nee, werd het niet standaard sinds 1.5?)

Yep.. maar je kan het al een lange tijd gebruiken (lees een paar jaar)

Nou dat is het hele idee. Generics is syntactische suiker om vervelende casts e.d. niet zelf te doen.

In java misschien wel, maar in gyro niet.

De hele tijd casten en methods aanroepen is gewoon een pain in the ass imho. En het feit dat de java-variant niet type-safe is (in de C++ vector kun je er alleen ints in stoppen, in de java vector kan alles erin)

Als je je vector ook juist het geparametriseerd, dan kan je er alleen Integers in stoppen.

[ Voor 4% gewijzigd door Alarmnummer op 27-11-2003 20:37 ]

[Macros]

nou nee, generics zijn fundamenteel anders dan templates

Je zal het wel geen valide argument vinden, maar 2 weken terug heb ik een gast college gehad over C++ (vooral de verschillen met C) door 1 van de leden van het commitee dat de ANSI C++ standaard hebben bepaald.
Hij zei het letterlijk, dat de Templates samen met de STL zijn ontworpen om genericiteit te implementeren.

Een template kan bestaan voor alleen een functie of hele klassen. Als je zo'n template gebruikt dan wordt hij in de compiler vertaald naar het type dat je op dat moment wilt gebruiken en mee gecompiled, als je dezelfde template erg vaak gebruikt voor veel verschillende types, dan wordt die code in erg veel vormen door de compiler gedupliceerd en in je binary gezet. Genericiteit voor algoritmes is geimplementeerd met templates en iterators. Daarna kwam er een hele handeling met een ingewikkeld voorbeeld als afsluiting. Ik heb de sheets hier nog voor me, helaas kan ik geen digitale online versie vinden, want het is wel interesant

[Macros]

Alarmnummer schreef op 27 november 2003 @ 20:36:
Als je je vector ook juist het geparametriseerd, dan kan je er alleen Integers in stoppen.

Volgens mij kan je met Reflection wel generics simuleren.

Dit is dan wel geen generics perse, maar heeft wel een aantal ideeen van het principe inzich. Het was geinspireerd door de foreach constructie in PHP:

Java:

static Object[] foreach(Object[] arr, Method m){
    int size = Array.getLength(arr);
    Object[] results = new Object[size];
    try{
        for(int i = 0; i < size; i++)
            results[i] = m.invoke(arr[i], null);
    } catch(Exception e) {System.out.println(e); }
    return results;
}

Neemt een Object Array en een methode en voert die methode uit op elk object in die Array, deze versie werkt alleen op methodes zonder argumenten. Maar ik heb een paar verschillende versies gemaakt. Ik vond het wel geinig.

[Alarmnummer]

Macros schreef op 27 november 2003 @ 20:48:
[...]

Volgens mij kan je met Reflection wel generics simuleren.

Waarom zo stuntelen als je het echte werk kan krijgen? Haal Codeguide maar eens op, (of IDEA), dan heb je een IDE die ook meteen generics aankan.

Er komt trouwens een beta (weet niet eens of dat het wel is) jdk1.5 uit binnenkort. Dan krijg je er meteen nog een hele lading andere features bij zoals generics, attributen, autoboxing, nieuwe forlus en nog meer leuks.

[ Voor 28% gewijzigd door Alarmnummer op 27-11-2003 21:16 ]

[Macros]

Alarmnummer schreef op 27 november 2003 @ 21:12:
[...]

Waarom zo stuntelen als je het echte werk kan krijgen?

Omdat het leuk is?!

[MSalters]

Macros schreef op 27 november 2003 @ 20:39:
[...]

Je zal het wel geen valide argument vinden, maar 2 weken terug heb ik een gast college gehad over C++ (vooral de verschillen met C) door 1 van de leden van het commitee dat de ANSI C++ standaard hebben bepaald.
Hij zei het letterlijk, dat de Templates samen met de STL zijn ontworpen om genericiteit te implementeren.

Een template kan bestaan voor alleen een functie of hele klassen. Als je zo'n template gebruikt dan wordt hij in de compiler vertaald naar het type dat je op dat moment wilt gebruiken en mee gecompiled, als je dezelfde template erg vaak gebruikt voor veel verschillende types, dan wordt die code in erg veel vormen door de compiler gedupliceerd en in je binary gezet. Genericiteit voor algoritmes is geimplementeerd met templates en iterators. Daarna kwam er een hele handeling met een ingewikkeld voorbeeld als afsluiting. Ik heb de sheets hier nog voor me, helaas kan ik geen digitale online versie vinden, want het is wel interesant

Ik heb een vermoeden dat ik dat college ken. Sterker nog, ik heb het gevoel dat ik dat college 2 jaar geleden zelf heb gegeven TU Delft, ITS? En ik heb het vermoeden dat dit jaar JC van Winkel het college gaf?

In elk geval is er een verschil tussen Generic Programming, het concept en Generics zoals ze in Java 1.5 zitten. Een uitwerking van het eerste vind je in Advanced C++, wat de Loki library presenteert. Dat is een library die bekende patterns in code uitdrukt. Met Java's generics lukt dat niet.

[Verwijderd]

euh..

bedankt allemaal van jullie aandacht hehe..

maar nu weet ik het niet meer goed

iedereen zegt wat anders

sinds gisteravond gepost en nu al 90 berichtjes ofzo .

wat is c en c++ ofzo voor een programma? want dat hoor ik het meeste hier...

alvast bedankt voor jullie aandacht

[zakalwe]

Er is natuurlijk wel een enorm verschil tussen de verschillende talen, maar wat eigenlijk iedereen hierboven zegt is dat leren programmeren niet hetzelfde is als een syntax (taal) leren. Een programmeur is iemand die zonder moeite problemen om kan zetten in deelproblemen en daar oplossingen voor kan bouwen. Een goede programmeur kan dat in elke voor de klus geschikte taal.

Conclusie: begin gewoon in een taal waar je wat mensen kent die je om hulp kan vragen of je verder kunnen helpen.

[ Voor 14% gewijzigd door zakalwe op 27-11-2003 22:24 ]

[bigtree]

Zakalwe schreef op 27 november 2003 @ 22:22:
[...]waar je wat mensen kent die je om hulp kan vragen of je verder kunnen helpen.

Oftewel... welkom in P&W.

[.oisyn]

Macros schreef op 27 november 2003 @ 20:39 iets over genericiteit

je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

In java en .net wordt er namelijk niet aparte code gegenereerd voor functies en/of classes. Vandaar dat het ook prima past in de intermediate languages van Java en .net. Daar hoeft de implementatie ook niet bekend te zijn om een nieuw type te instantieren, en de gegeneralizeerde classes en methoden kunnen van tevoren gecompileerd worden.

Bij C++ templates ligt dat heel anders: je krijgt bijna letterlijk een substitutie van de template parameters, en op instantiatie-moment wordt er pas code gegenereerd. Vandaar dat je met C++ templates dingen hebt als (partial) specialization, en ander soort template parameters, zoals integral types, (member)pointers, etc. Dat is echt compleet wat anders dan generics zoals gebruikt in java en .net, en het gaat ook een heel stuk verder

[curry684]

.oisyn schreef op 27 november 2003 @ 22:51:
[...]
je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

Het grote verschil in insteek (en aannames hier) is dat generics niet per definitie templates zijn. Templates zijn wel per definitie een vorm van generic programming.

Zeg maar: een koe is wel vee, maar vee is geen koe

In C++ is generics geimplementeerd als templates, wat inderdaad een heel erg krachtig en flexibel systeem is, wat Java niet heeft, maar alles wat je met generics kan, kan je ook en flexibeler (wel langzamer) met Objects in Java en PHP heeft er al helemaal geen last van omdat die helemaal geen typing heeft.

DIt is dus een fundamenteel foute aanname. Templates zijn in C++ ook overbodig: alles wat je ermee kunt is ook te doen door heel veel typwerk, macro's en/of virtual functies. Het feit dat het voor generieke concepten zoals containers een veel summierdere en helderdere en typesaferdere ( ) notatie levert bepaalt de grote levensvatbaarheid van templates in C++.

Stroustrup heeft in "The C++ Programming Language" een hoofdstuk vol geschreven over waarom de containers van de STL als templates zijn geimplementeerd op de huidige manier, en waarom alternatieven met virtuals e.d. allemaal afvielen, met voor iedere mogelijkheid alle pro's en con's op een rij gezet. Erg interessant leesvoer.

Ik zie hier ook klassiek gevloek op de mogelijkheid van macro's in C++. Laat ik als toch wel zachtjes ervaren programmeur zeggen: macro's zijn fantastisch, macro's zijn allesbehalve evil. Abuse van macro's is evil, en hard ook. Maar goed gebruikt op de goede plekken kun je met macro's fantastische stunts uithalen die hopeloos goed leesbare en krachtige code kunnen reproduceren (oisyn weet in dat verband nog wel hoe ik bijv. code schrijf die in releasebuilds callstacks en profiling optioneel produceert). Macro's bieden je ook de mogelijkheid om language extensions te maken die veelgedane taken uniform continu op dezelfde manier uitvoert en daarmee de mogelijkheid tot typfouten reduceert tot nul.

Macro's per definitie tot evil reduceren getuigt van kortzichtigheid en/of gebrek aan passende ervaring met de goede toepassingen ervan.

[Macros]

MSalters schreef op 27 november 2003 @ 21:42:
[...]

Ik heb een vermoeden dat ik dat college ken. Sterker nog, ik heb het gevoel dat ik dat college 2 jaar geleden zelf heb gegeven TU Delft, ITS? En ik heb het vermoeden dat dit jaar JC van Winkel het college gaf?

In elk geval is er een verschil tussen Generic Programming, het concept en Generics zoals ze in Java 1.5 zitten. Een uitwerking van het eerste vind je in Advanced C++, wat de Loki library presenteert. Dat is een library die bekende patterns in code uitdrukt. Met Java's generics lukt dat niet.

Ja, JC deed het deze keer, hij deed het erg goed. Vorig jaar deed ik het college ook al, alleen toen heb ik erg veel colleges gemist, ook het C++ college.

[Macros]

curry684 schreef op 28 november 2003 @ 00:05:Iets over generics in C++ .

Wat jij nu zei zeg ik toch ook, dat generics is geimplementeerd is als templates. We moeten vee hebben! Laten we koeien nemen!

Als we het toch over evil code hebben. C++ heeft meer mogelijkheden dan C om evil code te schrijven. Laatst vroeg ik me af wat de sneltste manier is om uit een dubbele while/for loop te springen zonder een return te gebruiken om uit een functie te springen en dat was toch echt een goto jump. Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen? Zo ja, worden dan de stack geschoont van de functie calls waar je uit springt? Als dat niet gebeurd, kan dat dan slechte invloed op je programma hebben? Vreemd gedrag, memory leaks en dergelijke?

Toen ik 12 was in Basic schreef op de Commodore 64 was er alleen maar goto en gosub, dus toen verneukte goto's de gosubs niet, ook waarschijnlijk omdat je gosubs niet kon nesten (als ik me goed herinner)

[alienfruit]

Waarom geen discussie over Java vs. C#

[curry684]

Macros schreef op 28 november 2003 @ 00:14:
[...]
Als we het toch over evil code hebben. C++ heeft meer mogelijkheden dan C om evil code te schrijven. Laatst vroeg ik me af wat de sneltste manier is om uit een dubbele while/for loop te springen zonder een return te gebruiken om uit een functie te springen en dat was toch echt een goto jump. Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen? Zo ja, worden dan de stack geschoont van de functie calls waar je uit springt? Als dat niet gebeurd, kan dat dan slechte invloed op je programma hebben? Vreemd gedrag, memory leaks en dergelijke?

Ach ik heb Stroustrup hier toch liggen, hoofdstuk 6.3.4 dus:

6.3.4 Goto

C++ possesses the infamous goto:

goto identifier ;
identifier : statement

The goto has few uses in general high-level programming, but it can be very useful when C++ code is generated by a program rather than written directly by a person; for example, gotos can be used in a parser generated from a grammar by a parser generator. The goto can also be important in the rare cases in which optimal efficiency is essential, for example, in the inner loop of some real-time application.

The scope of a label is the function it is in. This implies that you can use goto to jump both into and out of blocks. The only restriction is that you cannot jump past an initializer or into an exception handler.

One of the few sensible uses of goto in ordinary code is to break out from a nested loop or switch-statement (a break breaks out of only the innermost enclosing loop or switch-statement).

En ook voor dat laatste 'sensible' use is het in het algemeen evil en lelijk

Goto is gewoon generally accepted als een nutteloos concept tenzij je idd in realtime 100% timecritical applications zit waar de compiler je bedoeling anders net niet goed snapt (zelden dus).

Toen ik 12 was in Basic schreef op de Commodore 64 was er alleen maar goto en gosub, dus toen verneukte goto's de gosubs niet, ook waarschijnlijk omdat je gosubs niet kon nesten (als ik me goed herinner)

Je had toen ook geen variabelen op de stack maar alleen return positions

[.oisyn]

Macros schreef op 28 november 2003 @ 00:14:
Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen?

andere functies kan natuurlijk niet met puur C++. Wat hoogstens kan is gebruik te maken van setjmp() en longjmp (), maar die moet je absoluut niet gebruiken in C++ code omdat ze niet de C++ object semantics ondersteunen. C++ is daar verder heel correct in: objecten op de stack worden altijd netjes geconstruct en gedestruct. Zoals curry al zei, springen voorbij een initializer kan niet, maar uit een scope springen kan altijd: alles wordt netjes opgeruimd. Ook bij het gooien van een exception wordt alles goed opgeruimd.

Sterker nog, destructor calls zijn de methode voor exception safe programming. Als je een stukje code hebt dat opruimwerk doet als de functie exit dan kun je dat in een destructor van een class gieten. Als je daar een instantie van maakt op de stack, dan wordt ie altijd gedestruct, ook al wordt er ergens een exception gegooid. Op die manier kun je bepaalde niet-atomaire acties dus rollbacken. Als er een exception optreedt tussen 2 acties kun je de eerste ongedaan maken, zodat je programma in een consistente staat blijft.

Deterministic finalization komt ook in vs.net whidbey , iets wat java en .net nu toch wel sterk missen

[ Voor 6% gewijzigd door .oisyn op 28-11-2003 01:22 ]

[Verwijderd]

misschien een goed idee om gewoon een sticky te maken van het onderwerp " wat is de beste programmeeertaal"

het komt toch zo eens in de 2 weken terug... en de trend is steeds het zelfde het wordt een flame of het word een rant

[Macros]

Verwijderd schreef op 28 november 2003 @ 07:17:
misschien een goed idee om gewoon een sticky te maken van het onderwerp " wat is de beste programmeeertaal"

het komt toch zo eens in de 2 weken terug... en de trend is steeds het zelfde het wordt een flame of het word een rant

Ik heb niet echt een rant gezien, en al helemaal geen flame.
Ik denk dat het over het algemeen geen ruk uit maakt welke programmeer taal je mee begint. Het is alleen belangrijk dat je de eerste paar stappen gestructureerd neemt en niet helemaal alles je zelf aanleert, wat kan leiden tot jaren lange training om dingen opnieuw goed te leren. Kies een taal die je het makkelijkst lijkt, ik zou met PHP beginnen als ik nu kon kiezen. Is erg vergevings gezind, en heeft redelijk veel feutures die je kan leren. Als je dan een beetje kan programmeren kan je een andere taal nemen die meer past bij wat je dan wilt.
Bijkomend voordeel van PHP is dat je vaak meteen HTML, SQL leert.

[whoami]

Macros schreef op 28 november 2003 @ 08:33:
[...]
Bijkomend voordeel van PHP is dat je vaak meteen HTML, SQL leert.

Bij iedere applicatie die je wilt schrijven die gegevens in een DB propt en er weer uithaalt, zal je SQL moeten leren. Dat heeft dus niets met PHP op zich te maken ofzo.
Trouwens, als je SQL leert mbhv MySQL (wat veel het geval is als je met PHP aan de slag gaat), dan leer je bepaalde dingen mbt SQL fout, dat heb ik hier al genoeg gezien.

[Skaah]

Superlogo!

code:

leer start
penneer
herhaal 4 zijde
wacht 10
penop
eind

leer zijde
vooruit 100
rechts 100
eind

[ Voor 4% gewijzigd door Skaah op 28-11-2003 09:05 ]

[whoami]

alienfruit schreef op 28 november 2003 @ 00:25:
Waarom geen discussie over Java vs. C#

Omdat we die al eens gehad hebben:
[rml][ Alg]Is C# een Java-clone? Waarom of waarom niet[/rml]

[Riegstar]

Verwijderd schreef op 27 november 2003 @ 22:03:
euh..

bedankt allemaal van jullie aandacht hehe..

maar nu weet ik het niet meer goed

iedereen zegt wat anders

sinds gisteravond gepost en nu al 90 berichtjes ofzo .

wat is c en c++ ofzo voor een programma? want dat hoor ik het meeste hier...

alvast bedankt voor jullie aandacht

Ik begrijp hieruit dat je door de bomen het bos niet meer ziet.
Want je vraag blijft natuurlijk staan: Welke taal....

Voor web:
Serverside: php of asp
Clientside: java (applets)

Voor windows / GUI:
Delphi
C++
Visual Basic
C# of VB.NET (.NET heeft toekomst maar hogere systeem/software eisen)
Java (vereist iets meer werk voor GUI)

Voor console:
Java
C
C++

Dos:
Modula
Pascal
C

Dus ieder taal/omgeving heeft voor- en na-delen.

[whoami]

Het belangrijkste is dat je leert programmeren. Niet dat je een taal leert.
Het is natuurlijk wel nodig dat je leert programmeren dmv een taal, maar die taal is een middel, geen doel.
Met talen zoals C++, pascal, Java en C# kan je imho goed leren programmeren. Je wordt gedwongen om nette/gestructureerde code te schrijven. De talen zijn wmb goed geschikt om de basisbeginselen van 't programmeren onder de knie te krijgen. Als je die basis hebt en snapt, kan je nog altijd verder bouwen met dezelfde taal om de wat geavanceerdere principes onder de knie te krijgen.

[Alarmnummer]

.oisyn schreef op 27 november 2003 @ 22:51:
[...]
je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

In java en .net wordt er namelijk niet aparte code gegenereerd voor functies en/of classes.

In .NET gebeurt dit wel, gelukkig vind dit runtime plaats (lees anders de documentatie van Gyro maar eens). Dit heeft als voordeel dat dat je niet van te voren alles hoeft uit te compileren (voor alle types de code te maken) en dat je dit kan:

code:

void foo(List<X> l){
      foo(List<List<X>> null)
}

[edit]
oeps.. haakjes vergeten

Dit het polymorfe recursie en dat vind c++ niet leuk. .NET en java hebben er geen problemen mee.

Dat is echt compleet wat anders dan generics zoals gebruikt in java en .net, en het gaat ook een heel stuk verder

ALs je gaat kijken naar de details dan is de werking idd heel anders. Maar als je aan een leek uit moet leggen, dan vind ik templates toch erg veel lijken op generics. Ik zou er niet zo moeilijk over doen om het verschil zo duidelijk te maken.

[ Voor 10% gewijzigd door Alarmnummer op 28-11-2003 10:28 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 19-02-2015 00:00 ]

[Alarmnummer]

Eelis schreef op 28 november 2003 @ 10:15:
[...]

Kun je dit fragment misschien meer toelichten? Zijn dit twee functies? Zo nee, wat is dan het idee van deze constructie? (En zo ja, is er een reden dat het returntype van de tweede functie mist?)

Dit is een recursieve aanroep van de functie foo. Stel dat je de eerste keer aanroept met List<int>, dan zal dit de 2e keer een aanroep zijn naar List<List<int>> en ik neem aan dat je wel aanvoelt dat dit wel een tijdje door kan gaan. Een c++ compiler kan hier onmogelijk alle code voor genereren omdat hij compiletime alles wil maken. Als je het lazy gaat doen (runtime), dan kan het wel (gyro).

[edit]
Ik zie dat ik de haakjes helemaal vergeten ben.. *eet hand vol koffie (is veel geconcentreerder)*...

[ Voor 13% gewijzigd door Alarmnummer op 28-11-2003 10:31 ]

[drm]

curry684:
Goto is gewoon generally accepted als een nutteloos concept tenzij je idd in realtime 100% timecritical applications zit waar de compiler je bedoeling anders net niet goed snapt (zelden dus).

Ik begrijp hieruit dat een goto eigenlijk alleen (goed) gebruikt wordt om uit meerdere levels te "breaken".

Om maar even een achterlijk (en vooral zinloos) voorbeeld te geven:

C++:

#include <iostream>

int main () {
   int a;
   for ( int i = 1; i < 16; i++ ) {
      a = i % 3;
      switch ( a ) {
         case 1:
            std::cout << "woei";
         case 2:
            break;
         case 0:
            std::cout << "spef!";
            goto end_for;
      }
   }
   end_for:
   return 0;
}

Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Enig idee

[.oisyn]

Alarmnummer schreef op 28 november 2003 @ 09:42:
[...]

In .NET gebeurt dit wel, gelukkig vind dit runtime plaats (lees anders de documentatie van Gyro maar eens). Dit heeft als voordeel dat dat je niet van te voren alles hoeft uit te compileren (voor alle types de code te maken)

compileren voor andere typen, zelfs at runtime, lijkt me een beetje nutteloos. Immers, je template parameters voldoen aan een bepaalde specificatie, het moet een bepaalde interface implementeren of een class extenden. Je kunt dus prima met de base class werken.

Het verschil in code zit 'm vervolgens in het gebruik van die template functie of class. Want als je een generic functie hebt zoals bijvoorbeeld (en ik ken de notatiewijze verder niet, maar dit is wel begrijpbaar denk ik)

Java:

generic<T extends Object> T eenFunctie (T t);

En je stopt er een MyClass in, dan verwacht je er ook een MyClass weer uit. Intern werkt de functie echter gewoon op Object. In feite zijn de volgende 2 regels code dan ook identiek:

Java:

MyClass c = eenFunctie<MyClass> (c);
MyClass c = (MyClass)eenFunctie ((Object)c);

(waarbij de cast naar Object op regel 2 slechts ter illustratie dient)
Intern aan eenFunctie hoeft er niets te veranderen aan de code. Wat erbij komt is slechts een cast op het eind naar MyClass (en de impliciete cast naar Object bij het argument).

En daarom is het mijs inziens ook fundamenteel anders dan C++ templates, waar er een lexicale substitutie plaatsvindt bij de template parameters.

C++:

template <class T>
void roepEenFunctieAan (T & t)
{
    t.eenFunctie ();
}

struct A
{
    void eenFunctie () { std::cout << "hoi" << std::endl; }
};

struct B
{
    struct functor
    {
        int operator () (int i = 0)
        {
            return i + 10;
        }
    };

    functor eenFunctie;
};

int main ()
{
    A a;
    B b;
    roepEenFunctieAan (a);
    roepEenFunctieAan (b);
}

A::eenFunctie en B::eenFunctie zijn compleet anders. Bij A is het gewoon een functie zonder parameters en returntype. Bij B is het een object, dat door middel van operator overloading aan te roepen is als een functie. En het heeft bovendien een compleet andere signature dan A::eenFunctie. A en B hebben totaal niets met elkaar gemeen, ze voldoen niet aan een bepaalde gespecificeerde interface oid. Dit werkt ook alleen maar als roepEenFunctieAan<A> en roepEenFunctieAan<B> totaal verschillende stukjes code produceren. En dit werkt dan ook alleen maar als de implementatie at compile-time bekend is (met uitzondering van het export keyword, waarmee de compilatie verplaatst kan worden naar link-time)


Ik moet er overigens wel bijzeggen dat ik eigenlijk alleen java generics ken, en alleen maar een beetje (door discussies van oa mbravenboer ). Uit de presentatie van visual c++ whidbey heb ik begrepen dat generics in .net ook ongeveer zo werkt als in java, en heel anders is dan c++ templates (anders is het ook vrij onlogisch om generics naar c++ te brengen, wat dus gebeurt in whidbey ). Ik zal vanavond als ik tijd heb de docs van Gyro eens doornemen, lijkt me wel interessant

[curry684]

drm schreef op 28 november 2003 @ 11:30:
Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Grote vraag inderdaad. Ik vind die syntax trouwens ook niet prettig: nodigt enorm uit tot fouten als je een nestlaag toevoegt. De beste oplossing imho zou zijn:

C++:

while(true)
  for(int i = 0; i != 1000; i++)
    switch(Value[i])
      {
      case BreakOutOfForBlock:
        break for;
      case BreakOutOfInnerBlock:
        break;
      case BreakOutOfSwitchBlock:
        break switch;
      case BreakOutOfWhileBlock:
        break while;
      }

Hier zou je vrijwel alle gevallen mee af kunnen vangen, het is taaltechnisch zuiver en introduceert geen nieuwe keywords. Aan de andere kant heb ik in een jaar of 8 C++ development nog nooit goto gemist of uberhaupt overwogen 'm te gebruiken: de constructie is echt obsolete en imho blijft het een teken van slechte programmeerinzichten als je 'm wilt/moet gebruiken.

Het eeuwige enige voorbeeld van de nuttige goto is de 5-dubbel geneste for-loop. Wanneer gebruik je echter 5-dubbel geneste for-loops? Alleen bij lookups. Wat is een voordeel aan lookups? Ze zijn generiek herbruikbaar voor de lijst, niet alleen voor 1 functie. Waarom schrijf je de lookup dan uit in de functie? Maak gewoon een aparte FindXXX(...) functie en return zodra je gevonden hebt, exit alle goto-problemen...

[whoami]

Over de verschillen mbt C++ templates / Java Generics en de generics in C# (.NET):

Differences between C# generics and other implementations
C++ templates differ significantly from C# generics. Where C# generics are compiled into IL, causing specialization to occur intelligently at run-time for each value type and once only for reference types, C++ templates are essentially code expansion macros that generate a specialized type for each type parameter supplied to a template. So, when the C++ compiler encounters a template, say a Stack of integers, it will expand the template code into a Stack class that contains integers internally as its native type. Regardless of whether the type parameter is a value or reference type, unless the linker is specifically designed to reduce code bloat, the C++ compiler will create a specialized class each time, resulting in a significant increase in code bloat over C# generics.

Moreover, C++ templates cannot define constraints. C++ templates may only define constraints implicitly by simply using a member that might or might not belong to the type parameter. If the member does exist in the type parameter that is eventually passed to the generic class, the program will work properly. If the member does not exist in the type parameter, the program will fail and a cryptic error message will likely be returned. Because C# generics can declare constraints and are strongly typed, these potential errors do not exist.

Meanwhile, Sun has proposed the addition of generics in the next version of the Java language, codenamed Tiger. Sun has chosen an implementation that does not require modifying the Java Virtual Machine. As such, Sun is faced with implementing generics on an unmodified virtual machine.

The proposed Java implementation uses similar syntax to templates in C++ and generics in C#, including type parameters and constraints. But, because it treats value types differently than reference types, the unmodified Java Virtual Machine will not be able to support generics for value types. As such, generics in Java will gain no execution efficiency. Indeed, the Java compiler will inject automatic downcasts from the specified constraint, if one is declared, or the base Object type, if a constraint is not declared, whenever it needs to return data. Further, the Java compiler will generate a single specialized type at compile-time that it will then use to instantiate any constructed type. Finally, because the Java Virtual Machine will not support generics natively, there will be no way to ascertain the type parameter for an instance of a generic type at run-time and other uses of reflection will be severely limited.

Meer info:
[rml][ .NET] New language features in C#[/rml]

[PeeJay]

.oisyn schreef op 27 november 2003 @ 16:35:
[...]

het is natuurlijk subjectief, maar ik denk dat je dan niet genoeg ervaren was in C++.

Ben ik wel met je eens. Toen was ik nog maar net 18 en zat het logisch denken nog niet op een redelijk niveau.
Toch vind ik Java tegenwoordig fijner werken. Maar dat komt waarschijnlijk omdat de opdrachten hier makkelijker (sneller) op te lossen zijn met Java. Ik steek gewoon veel minder tijd in C++, waardoor het omschakelen ook bemoeilijkt wordt.

Dat betwijfel ik ten zeerste. 5000 regels vind ik niet bepaald klein (comments tellen niet mee natuurlijk), dat code je denk ik niet in een week als je er ook nog over na moet denken (en dus niet simpel typwerk, zoals het ophalen of initialiseren van allerlei data enzo)

Als je met een groep van 5 man werkt, valt de tijd die je nodig hebt reuze mee

[drm]

curry684:
Grote vraag inderdaad. Ik vind die syntax trouwens ook niet prettig: nodigt enorm uit tot fouten als je een nestlaag toevoegt. De beste oplossing imho zou zijn:

code:

snipz0r

daar zit een zelfde soort probleem in, namelijk dat als je 2 while loops genest hebt je dus alleen of de "dichtsbijzijnde" while kan breaken of de "verste". Dan zou een nummertje toch sort of inevitable zijn Maar goed.

Hier zou je vrijwel alle gevallen mee af kunnen vangen, het is taaltechnisch zuiver en introduceert geen nieuwe keywords. Aan de andere kant heb ik in een jaar of 8 C++ development nog nooit goto gemist of uberhaupt overwogen 'm te gebruiken: de constructie is echt obsolete en imho blijft het een teken van slechte programmeerinzichten als je 'm wilt/moet gebruiken.

Ben ik met je eens inderdaad. Misschien is dat ook wel de reden dat een dergelijke break constructie niet bestaat, juist omdat het uitnodigt tot vreemde constructies/luie oplossingen? Who knows

[Eelis]

.

[ Voor 103% gewijzigd door Eelis op 19-02-2015 00:00 ]

[curry684]

Eelis schreef op 28 november 2003 @ 15:19:
Om die reden zou ik ook willen pleiten voor een loop-keyword zonder ingebakken conditiecheck, voor in die situaties waarin een check aan het begin of eind van de loop gewoon niet nodig/handig is.

Mjah ik vind while(true) lekker weglezen hoor

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 19-02-2015 00:00 ]

[Soultaker]

offtopic:
Ik vind zelf for(;;) echt veel lelijker dan while(true), maar blijkbaar is dat dus erg persoonlijk. Van mij mag je trouwens prima een regel #define loop while(true) toevoegen aan je project.

[curry684]

Bliep, je vind while(true) er workaroundachtig uit zien, en for(;;) niet met 3 lege expressies?

Ik vind de while-vorm heel logisch, "doe dit zolang true true is", ergo ad infinitum Waarom nieuwe keywords introduceren zonder nieuwe functionaliteit?

[curry684]

Soultaker schreef op 28 november 2003 @ 15:29:

offtopic:
Ik vind zelf for(;;) echt veel lelijker dan while(true), maar blijkbaar is dat dus erg persoonlijk. Van mij mag je trouwens prima een regel #define loop while(true) toevoegen aan je project.

Waren macro's trouwens niet per definitie evil?

[Eelis]

.

[ Voor 113% gewijzigd door Eelis op 19-02-2015 00:00 ]

[drm]

[flauw]
Er is ook wel wat te zeggen voor do { ... } while (true);
Aangezien de conditie in een while (true) { ... } altijd waar is, is een eerste iteratie onvermijdelijk. Aangezien dat ook de bedoeling is van een do {..} while zou die eigenlijk netter zijn dan een while{...}
[/flauw]

edit:
en nou in 't nederlands

[ Voor 16% gewijzigd door drm op 28-11-2003 15:53 ]

[Tomatoman]

Laten we vooral

Delphi:

repeat
  // bladibla
until False;

niet vergeten

[ Voor 4% gewijzigd door Tomatoman op 28-11-2003 15:58 ]

[drm]

ok, ik zal het niet vergeten

[Alarmnummer]

*vind het gesprek behoorlijk richting miereneukerij gaan

[Verwijderd]

om dan maar Offspring_nl een beetje op weg te helpen;

download gratis;

Dev-C++ - een c/c++ compiler
(tevens is hier te vinden een gratis delphi compiler)
http://www.bloodshed.net/

python;
http://www.python.org/


processing;
(per e-mail aan te vragen)
http://proce55ing.net/download/index.html

java;
(tja welke sdk je het beste kan downloaden,
daar durf ik even geen antwoord op te geven.)
http://java.sun.com/

edit:

laat ons weten waneer je, je eerste 'hello world' programma aan de praat heb gekregen.. puur uit nostalgie........

[ Voor 14% gewijzigd door Verwijderd op 28-11-2003 21:49 ]

[.oisyn]

Alarmnummer schreef op 28 november 2003 @ 16:11:
*vind het gesprek behoorlijk richting miereneukerij gaan

met de summiere topicstart van de topicstarter kun je alle kanten op

[Verwijderd]

ach ja..

wist ik veel

[Grijze Vos]

drm schreef op 28 november 2003 @ 11:30:
[...]

Ik begrijp hieruit dat een goto eigenlijk alleen (goed) gebruikt wordt om uit meerdere levels te "breaken".

Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Enig idee

Goto komt uit een tijd dat programmeertalen net iets geavanceerder werden dan Assembly. Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien). Goto is gewoon een higher-level language afkijksel van assembly talen.

Dijkstra is een van de eerste mensen die dat compleet heeft afgezeken, omdat het uiteraard de simpliciteit van je code, en met name de leesbaarheid, negatief beinvloed..

goto's cq jumps zijn nog steeds uitermate nuttig hoor, net als self-modifying code, als je het maar op assembly niveau houdt

[curry684]

Grijze Vos schreef op 30 november 2003 @ 03:31:
[...]
Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien).

Intel assembly is niet m'n sterkste kant, dus misschien dat je wat dat betreft gelijk hebt, maar op bijv. de Motorola 680x0 series kon je wel asm-style loopen met de Dxx serie van instructies: Decrement Register and Branch Conditionally.

Even roestige 8 jaar oude kennis uitproberen:

code:

  // 10 iteraties
  moveq #10, d0
  lea Source, a0
  lea Target, a1

myloop:
  move.l (a0)+, (a1)+
  dne d0, myloop

Hierbij wordt dus het D0-register gedecrement, getest en vervolgens als de Z-bit (zero) niet gezet is gebranched naar myloop

* curry684 hoopt dat dit syntactisch klopte

[Macros]

Ik heb nog Motorola 680x0 assembly gehad in mijn eerste jaar, was wel erg cool. Ook al is het RISC, sommige instructies konden de hond uitlaten, je peuter van de creche halen en tegelijk je afwasmachine uitruimen

[PommeFritz]

offtopic:
680x0 is geen RISC. Ben je in de war met de 88000 serie?

[_the_crow_]

Grijze Vos schreef op 30 november 2003 @ 03:31:
Goto komt uit een tijd dat programmeertalen net iets geavanceerder werden dan Assembly. Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien). Goto is gewoon een higher-level language afkijksel van assembly talen.

Dijkstra is een van de eerste mensen die dat compleet heeft afgezeken, omdat het uiteraard de simpliciteit van je code, en met name de leesbaarheid, negatief beinvloed..

goto's cq jumps zijn nog steeds uitermate nuttig hoor, net als self-modifying code, als je het maar op assembly niveau houdt

GAS:

MOV  ECX,200h
blaatlabel:
TEST EAX,80h      ; nutteloos iets :+
JZ   blaatlabel2
LOOP blaatlabel
blaatlabel2:

Dat is gewoon een loop in ASM hoor (met ECX 'rondes').
Of begrijp ik je verkeerd?

[ Voor 10% gewijzigd door _the_crow_ op 30-11-2003 18:03 ]

[Macros]

PommeFritz schreef op 30 november 2003 @ 17:39:

offtopic:
680x0 is geen RISC. Ben je in de war met de 88000 serie?

offtopic:
Je hebt gelijk

[GrimaceODespair]

curry684 schreef op 28 november 2003 @ 00:05:
oisyn weet in dat verband nog wel hoe ik bijv. code schrijf die in releasebuilds callstacks en profiling optioneel produceert

Beetje late reactie misschien, maar:

C++:

while (true) // for (;;)
{
    Grimace.listen("veryCarefully");
}

[Grijze Vos]

In opcodes gesproken zijn je 'loopjes' nog altijd jumps. Dat bedoelde ik eigenlijk te zeggen. Hij kan hooguit een register ergens mee comparen en aan de hand daarvan een paar keer ergens naar terugjumpen, dan heb je het wel gehad.

Ik sprak btw niet over Intel assembly, maar over Z80, waar ik nu mee bezig ben..

[alienfruit]

with-commando is pas vervelend in Delphi
Kan van die verschrikkelijk leuke bugs veroorzaken

[.oisyn]

Grijze Vos schreef op 01 december 2003 @ 02:28:
In opcodes gesproken zijn je 'loopjes' nog altijd jumps. Dat bedoelde ik eigenlijk te zeggen. Hij kan hooguit een register ergens mee comparen en aan de hand daarvan een paar keer ergens naar terugjumpen, dan heb je het wel gehad.

en wat is dan het verschil tussen een asm loop en een c++ for-lus

Goto is gewoon een higher-level language afkijksel van assembly talen.

daar ben ik het niet mee eens. Je wilt gewoon kunnen springen naar een bepaald stuk. Dat geldt voor zowel assembly als gewone code. Om dan te zeggen dat het een "aftreksel" is lijkt me een beetje onzin. Het heeft bestaansrecht, en daarom zit het erin. (goto is nog altijd heel erg nuttig bij generated code, zoals bijvoorbeeld voor gegenereerde parsers e.d.)

[whoami]

alienfruit schreef op 01 december 2003 @ 02:37:
with-commando is pas vervelend in Delphi
Kan van die verschrikkelijk leuke bugs veroorzaken

Tja, dat ligt niet aan dat statement, maar eerder aan de programmeur.

[Verwijderd]

Je kan C# en Java ook gebruiken om console apps te schrijven. Deze zullen allen maar gaan draaien op de PC's met de Virtual Machines...

Om ff terug te komen op Delphi platform onafhankelijkheid: Delphi6 en Delphi 7 (van borland) hadden de mogelijk heid om in een windows project ook gebruik te maken van de kylix compiler om zo een linux versie uit te poepen naast je windows versie.

C is idd goed over te brengen naar een linux bak, maar zal daar opnieuw gecompiled moeten worden. Dat is ook niet ALTIJD wenselijk. Het implementeren van de juiste libraries werkt idd, maar veel uitleg wordt gedaan met de geweldige windows libraries.

Op school hebben we C++ colleges gehad waar bijna alleen amar met de windows specifick libraries werd gewerkt....


En als je C++ gaat doen kijk eens naar DEV C++... Die is heeel licht, heeft ook GUI ontwikkelinge geloof ik.... en heeft snelle compiler (draaide op P2 366 veel beter dan die borland producten)