Kiezen voor C#, C of C++

[RevellNL]

Hallo allemaal,

ik ben al enige tijd aan het kijken welke taal voor mij de meest verstandige keuze is om te gaan leren (C#, C of C++) maar ik kom er nog niet echt uit. Ik zou jullie daarom ook graag om hulp/advies willen vragen.

Ik wil gaan programmeren voor zowel mobiele telefoons als gewone PC's. Ook zou ik graag een uitstapje willen kunnen maken naar b.v. de PSP of Nintendo DS om eens wat mee te proberen. Wat is dan de beste keus qua programmeertaal?

Alvast bedankt!

[BM]

Als je multiplatform wilt programmeren zal C# vrij snel afvallen. Daar is simpelweg geen runtime voor aanwezig op alle platformen (Linux kan nog via Mono, maar op de PSP of NDS zul je van een oude kermis thuis komen.

Verder is C# denk ik de eenvoudigste taal van de 3 genoemden om mee te beginnen, al ben ik bevooroordeeld als C# ontwikkelaar, en ken ik de andere 2 talen niet of nauwelijks.

[asfaloth_arwen]

Heb je een basis in programmeren? Je zult een heleboel moeten leren, echter de taal is slechts een tool. Van de talen die je nu noemt zijn C++ of C# het meest geschikt voor ondersteuning bij OO leren. Bij C# zit je ook meteen aan het .NET framework vast. Elke van de genoemde talen bied voor en nadelen, ik zou je dan ook aanraden om met meerdere talen aan de slag te gaan Hoe wil je leren? Zelfstudie, opleiding, cursus?

[ Voor 16% gewijzigd door asfaloth_arwen op 16-01-2009 16:56 ]

[Anoniem: 172123]

Leer programmeren, leer geen taal
De basis is uniform. De syntax verschilt en er zijn wat taalspecifieke features maar dat leer je in één dag. C is echt iets anders dan C++ en C# omdat dit niet object georiënteerd is. Tegenwoordig zijn er bar weinig situaties waar je C echt nodig hebt.

De meest geschikte omgeving om de basis te leren lijkt mij een goed (online) boek en C#.

[ Voor 23% gewijzigd door Anoniem: 172123 op 16-01-2009 16:57 ]

[Anoniem: 280796]

Wat ik je kan vertellen is dat het mij enorm geholpen heeft om te leren wat er gebeurt met je code. Dus hoe het vertaalproces tot machinecode werkt, hoe de stack werkt, of bij java wat een virtual machine doet, etc. Daarom zou ik je C++ aanraden, omdat het 'dichter bij de machine ligt'. Misschien is het wat moeilijker in 't begin, maar je zal er zeker profijt van hebben.

[RevellNL]

Ik ben nu PHP programmeur en wil de overstap gaan wagen naar een wat volwassenere taal. Ik heb ruime kennis dus wat de programmeerbasis betreft zit dat wel goed denk ik.

Als ik zo jullie reacties doorlees lijkt het me dus het verstandigste om te beginnen met b.v. C# en dan e.v.t. later een overstap te maken richting C++?

[asfaloth_arwen]

Ik zou een algemeen OO boek bestellen (voor tips zie: [Alg] Centraal boekentopic - part II) en daarmee beginnen. Welke taal is, zoals eerder aangeven, niet zo relevant. Als je een voorkeur hebt kun je daar natuurlijk op letten. Vaak zijn boeken of Java, of .NET (C#/VB), of C++ qua voorbeelden en oefeningen

[RevellNL]

OO heb ik al flink wat ervaring mee. Ik zal eens wat gaan rondneuzen in boekhandels e.d.

[prototype]

Wat dacht je van C#, C __EN__ C++? ;-) Niet veronderstellen dat als je een taal beheerst je ook de andere beheerst, ook al delen ze veel van de paradigms, er zijn genoeg onderscheidende factoren die je zeker ook moet leren om het meeste eruit te kunnen halen.Een taal als C++ masteren bijvoorbeeld doe je niet over 1 nacht, dus verwacht maar een lange zitting daarmee. Daar heb je echt heel veel tijd en geduld voor nodig om de benodigde ervaring ervoor op te doen. Zo zul je niet alleen de taal moeten leren met al zijn features (templates etc...) maar ook leren omgaan met zelf resources te managen (of bestaande libs ervoor gebruiken zonder daarbij te vergeten hoe het werkt). Denk daarbij aan RAII (te vinden in Bjarne Stroustrup's C++ boek, aanrader voor als je eenmaal de basics doorhebt), smart pointers etc... Dat zijn allemaal technieken die je je ook meester moet maken. Tel daarna nog kennis van onze grote vriend debugger erbij en evt tools als Valgrind om memory foutjes op te sporen, en je komt redelijk in de buurt. Dan moet je nog leren over portable code schrijven, en wil je misschien ook wat leren over hoe het er echt onderwater aan toe gaat. Assembly kennis is daarbij wel handig om te begrijpen hoe taal constructies nou echt vertaald worden, b.v. met respect tot hoe C/C++ argumenten/functie resultaten op de stack gooit en hoe je hier via ESP/EBP bij kan komen om maar even wat randoms te noemen. Als je games wil coden dien je --maar dat kan .oisyn je veel beter vertellen denk ik-- het meeste ook uit je hardware te kunnen halen en dan kan het ook hier op neerkomen...

Wat betreft OO, ervaring is 1 ding, maar dat impliceert imo niet meteen kennis. Daarbij is het ook zo dat elke taal het net iets anders aan je presenteert. Zo doet Java (om maar even een andere taal te noemen die veel op mobiele telefoons gebruikt wordt) voor polymorfie b.v. strict aan virtuele methoden, waarbij je bij C# en C++ weer de optie hebt om te kiezen tussen virtuele of non-virtuele methoden. Er zit dus weer verschil tussen hoe mensen dit implementeren. Verder kun je met C net zo goed OO doen en daar is onlangs nog een topic over geweest. Om echt goed tot deze realisatie te komen dien je echt goed in de stof te zitten van zowel de theory alswel de implementatie.

Tot slot, wat meer kennis van je machine is altijd mooi meegenomen. Wanneer je met talen werkt die vrij low-level al zijn, en die afhankelijk van de compiler je vaak zelfs in staat stellen om puur assembly te schrijven dan zou ik je aanraden om je ook te verdiepen in computer organisatie, architectuur en besturingsystemen. M.a.w. als je er echt serieus voor wil gaan wil je misschien ook een opleiding overwegen erin indien mogelijk! :-)

[ Voor 4% gewijzigd door prototype op 16-01-2009 18:42 ]

[MLM]

Uitstapjes naar de NDS/PSP vallen tegen, je kan niet zomaar een devkit bestellen en beginnen met coden

Maar goed, als je wel serieus op "kleinere" platformen (PDA, telefoons) wilt werken, dan ga je C/C++ moeten leren. Veel libraries voor deze hardware is C, dus dat zal je ieg moeten beheersen.

[leuk_he]

c++ is c met uitbreidingen.

c++ is strenger met compileren dus laat je minder fouten toe.

wellicht is het handig C te leren met een c++ compiler? dat zie je regelmatig: bewering dat het c++ code is, maar in werklijkheid 90% C en een paar %C++

wat je ook nog moet beslissen is wat voor omgeving je gaat leren. want een taal is 1 deel, maar weleke library(s) je gaat gebruiken bepaald straks veel meer de smoel van je applicaties dan de taal.

[IceM]

leuk_he schreef op vrijdag 16 januari 2009 @ 19:00:
c++ is c met uitbreidingen.

c++ is strenger met compileren dus laat je minder fouten toe.

wellicht is het handig C te leren met een c++ compiler? dat zie je regelmatig: bewering dat het c++ code is, maar in werklijkheid 90% C en een paar %C++

wat je ook nog moet beslissen is wat voor omgeving je gaat leren. want een taal is 1 deel, maar weleke library(s) je gaat gebruiken bepaald straks veel meer de smoel van je applicaties dan de taal.

C++ is OO, C is dat niet, lijkt me een wereld van verschil niet?

[PipoDeClown]

IceM schreef op vrijdag 16 januari 2009 @ 19:40:
[...]
C++ is OO, C is dat niet, lijkt me een wereld van verschil niet?

OO zit tussen je oren, daarentegen heeft "C++" wel meer handvatten om die OO concepten, bijv. multiple inheritance, er duidelijker uit te laten komen.
eiffel, java, object pascal, whatever##

[Soultaker]

Dit is gewoon een goed advies:

Anoniem: 172123 schreef op vrijdag 16 januari 2009 @ 16:56:
Leer programmeren, leer geen taal

Het maakt dus niet zoveel uit waar je mee begint, vooral als je geen specifiek doel voor ogen hebt.

Persoonlijk zou ik suggereren om C# te beginnen, omdat het een eenvoudige taal is met goede tool support (probeer wel te leren werken met de compiler, dus niet de IDE al het werk laten doen). Met C# kun je programmeren voor Windows (PC) en Windows Mobile (telefoons).

Als je de basis onder de knie hebt kun je C of C++ ook proberen; dat zal een stuk ingewikkelder zijn en je zult een aantal dingen moet afleren, maar dat neemt niet weg dat het nuttig is om je kennis te verbreden. Consoles zullen over het algemeen in C/C++ te programmeren zijn; voor alles wat met game development te maken heeft, is C++ eigenlijk een must (al hoef je meestal niet alle ins en outs van C++ te kennen).

[MLM]

C# is een stuk simpeler om te leren programmeren, je hoeft met een heleboel dingen geen rekening te houden (memory management, pointers).

Persoonlijk ben ik begonnen met C(++) en pas daarna C#. Voordeel is dat je dan wel leert waarderen wat C# voor je doet Als je echter na C# begint met C(++) denk je echt dat het een primitieve taal is met veel ingewikkelde constructies.

[MrBucket]

MLM schreef op vrijdag 16 januari 2009 @ 20:17:
C# is een stuk simpeler om te leren programmeren, je hoeft met een heleboel dingen geen rekening te houden (memory management, pointers).

Persoonlijk ben ik begonnen met C(++) en pas daarna C#. Voordeel is dat je dan wel leert waarderen wat C# voor je doet Als je echter na C# begint met C(++) denk je echt dat het een primitieve taal is met veel ingewikkelde constructies.

Hier ben ik het helemaal mee eens. Als je per se zowel C++ als C# wilt leren, zou ik het ook in die volgorde doen, want als je C# al kent en je moet dan C++'s pointergegoochel en STL gaan doorgronden, dan krijg je het gevoel dat je terug naar het stenen tijdperk moet. En dat is dan ook wel een beetje zo

Maar als je niet per se low-level aan de slag wilt en gewoon leuke software wil schrijven, zou ik voor C# of Java gaan. Die twee zijn qua syntax (in de basis in ieder geval) bijna identiek, en je krijgt veel meer functionaliteit tot je beschikking door de uitgebreide API. Daar waar je in C(++) voor zo ongeveer alles behalve file- en console output een proprietary library moet downloaden, kun je met C# en Java zo aan de slag met threading, xml, webservices, netwerkcommunicatie, grafische user-interfaces, etc.

Daarnaast kunnen de meeste mobiele telefoons prima Java-applicaties draaien, mocht je die weg in willen slaan.

[leuk_he]

IceM schreef op vrijdag 16 januari 2009 @ 19:40:
[...]


C++ is OO, C is dat niet, lijkt me een wereld van verschil niet?

Nee, c++ is niet OO, c++ heeft OO uitbreidingen. pas als je een OO framework kiest ben je gedwongen werkelijk OO te doen.

[MLM]

hoewel je met C++ prima niet-OO code kan schrijven, is het hele idee van C++ om wel OO te doen. Hoewel leuk_he technisch gezien gelijk heeft, kan je eigenlijk wel stellen dat C++ (op zijn minst bedoeld voor) OO is.

C++ zit niet voor niets de STL bij

Daarnaast, als je serieus van plan bent om PSP/NDS development te gaan doen, ga je niet om C(++) heen kunnen. Als je desktop development gaat doen, kan je denk ik beter C# gebruiken, en C(++) helemaal vergeten. Het heeft wel een aantal voordelen boven C#, maar dat gaat maar in een paar situaties op:
- platform restricties (er is geen java of .NET runtime voor het platform)
- game/high performance development (omdat er betere support voor C++ is)
- low level coding (SIMD, kernel/driver development)
- ik kan eigenlijk al geen #4 verzinnen

[ Voor 3% gewijzigd door MLM op 16-01-2009 21:29 ]

[TaraWij]

Volgens mij kan je best met C++ beginnen en eens je daar een goede basis hebt kan je dan nog steeds de .NET toer opgaan met C++/CLR (Desnoods als een enkele dll binnen het project, zodat je nog steeds cross-platform kan gaan) in plaats van een door Java beinvloedde taal te gaan. Het leren van C# als eerste taal geeft alleen maar verwarring naar mijn mening omdat dit een mix-up van C++, Java is (en in mindere mate ook F#-achtige talen). Verder hang je hier meer vast aan XNA, vind je minder libraries dan bij C++ en zijn er zoals eerder genoemd minder cross-platform mogelijkheden)

Voor hedendaagse gewone programmeurs is programmeren in C-stijl een slechte gewoonte en is het leren van die taal enkel nodig als je richting low-level wil gaan. (Je eigen kernel schrijven, drivers, apparatuur die geen C++ ondersteund, ...)

Over Java ga ik hier verder niet op in omdat je aangeeft dat je tussen C talen wil kiezen.

[RevellNL]

Wauw, wat een reacties! Ik weet verder van de achtergronden van de C talen vrij weinig af, vandaar dat ik hier dus ook de vraag stelde voor welke taal ik beter kan kiezen. Nu ik dit zo allemaal doorlees vallen mijn keuzes dan toch op C++ (voor het ontwikkelen voor b.v. PSP / NDS) en C# (voor het ontwikkelen voor Windows / Windows Mobile). Als eerste ga ik me dan toch op C / C++ orienteren voordat ik aan C# begin om de redenen die jullie noemen, dat ik anders in een, voor mijn gevoel, prehistorische omgeving terechtkom.

[jbvo]

MrBucket schreef op vrijdag 16 januari 2009 @ 20:29:
[...]

Hier ben ik het helemaal mee eens. Als je per se zowel C++ als C# wilt leren, zou ik het ook in die volgorde doen, want als je C# al kent en je moet dan C++'s pointergegoochel en STL gaan doorgronden, dan krijg je het gevoel dat je terug naar het stenen tijdperk moet. En dat is dan ook wel een beetje zo

Mijn ervaring bij eerst C/C++ en daarna C# leren is dat als je eenmaal gewend bent aan dat pointer gegoochel en STL, dat het dan best frustrerend is om met C# te gaan werken, omdat je dan het idee hebt dat je minder controle hebt over wat er daadwerkelijk in de machine gebeurt. Later is juist die kennis van pointers en dergelijke toch wel handig om te snappen hoe C# omgaat met reference/value types.

Als je gaat zoeken naar boeken/ebooks over C++, zal je over het algemeen boeken tegen komen die OF vooral het geavanceerde gedeelte van C++ zullen behandelen, OF boeken die eerst wat C behandelen en daarna naar dat geavanceerde gebeuren overgaan. Wat hier al eerder gezegd is, in de basis is C++ hetzelfde als C, de regeltjes zijn wat strenger, er zijn wat constructies toegevoegd om OO makkelijker te maken, enzovoort. Voor je aan templates en dergelijke toekomt, zal je een vrij groot gedeelte van C onder de knie hebben.

Ik heb zelf veel gehad aan het boek Thinking in C++ van Bruce Eckel, daarin zit ook echt een hoofdstuk waarin een basis van C wordt uitgelegd en de verschillen tussen C en C++ besproken worden. Verder kan je het boek in html vorm gewoon gratis downloaden met de code samples erbij, dus dat is ook wel handig.

[farlane]

leuk_he schreef op vrijdag 16 januari 2009 @ 20:37:

Nee, c++ is niet OO, c++ heeft OO uitbreidingen. pas als je een OO framework kiest ben je gedwongen werkelijk OO te doen.

Dus het is pas OO als je daartoe gedwongen wordt? Raar...

C++ zit niet voor niets de STL bij

De STL is nou niet echt een typisch OO ding.

@MLM
De STL is niet perse opgezet als een OO framework pur sang( alhoewel het wel gebruik van maakt van OO ) maar meer als generic framework; de voorbeelden van algoritmen en iterators wordt al genoemd. ( Overigens zegt Josuttis dat ook in zijn boek )

Je hebt natuurlijk gelijk als je zegt dat veel concepten die als OO worden bestempeld ook in andere talen ( moeilijker of makkelijker ) kunnen worden toegepast: wat dat betreft zijn het allemaal "universele patterns"

[ Voor 44% gewijzigd door farlane op 17-01-2009 15:32 ]

[MLM]

farlane schreef op zaterdag 17 januari 2009 @ 02:57:
[...]
De STL is nou niet echt een typisch OO ding.

Want? Tis gebaseerd op (template) classes en inheritance oa, wat toch wel OO concepten zijn.

[Stukfruit]

MLM schreef op zaterdag 17 januari 2009 @ 10:29:
[...]


Want? Tis gebaseerd op (template) classes en inheritance oa, wat toch wel OO concepten zijn.

..en algoritmes die allemaal gezellig in een namespace leven als ordinaire functie?

[leuk_he]

farlane schreef op zaterdag 17 januari 2009 @ 02:57:
[...]

Dus het is pas OO als je daartoe gedwongen wordt? Raar...

Nee, je mengt commentaren . C++ heeft ondersteuning voor OO uitbreidingen. Je KUNT die features gebruiken. Als je een OO framework/library gaat gebruiken Moet je dus OO extensies gaan gebruiken en MOET je dus OO gaan werken.

Maar vergeet niet dat je niet alle constructies van een taal moet gebruiken.

C heeft b.v. mogelijkheden heel compact, maar onleesbare code te creeeren.


(Met C kun je overigens ook OO werken, maar je maakt het jezelf niet makkelijker ermee)

[Anoniem: 69437]

TaraWij schreef op vrijdag 16 januari 2009 @ 21:23:
Over Java ga ik hier verder niet op in omdat je aangeeft dat je tussen C talen wil kiezen.

Da's op zich een beetje vreemd, aangezien C# en Java even veel te maken hebben met C++ en C: vrijwel niets. Je moet je niet laten misleiden door namen die op elkaar lijken.

[MLM]

Stukfruit schreef op zaterdag 17 januari 2009 @ 10:50:
[...]
..en algoritmes die allemaal gezellig in een namespace leven als ordinaire functie?

Hoe definieer jij OO dan?

Neem bijvoorbeeld een STL sorteer algoritme, die sorteert containers (=object) dmv iterators (=object) en (optioneel) een comparer-class (=object) om te sorteren. Die functie ontleent zijn bestaansrecht aan objecten en gebruikt objecten, maar is geen object.
Is het dan dus niet OO?
En zo niet, is het dan wel OO als het een static functie was in een object "algorithm"?

Is C# dan wel OO, omdat de taal forceerd dat alle functies en variabelen in een object zitten? Ookal is er support for static functies?

Je kan niet zomaar zeggen dat een taal wel/niet OO "is". Ik kan OO code in C schrijven, en non-OO code in C#, maar omdat het kan betekent niet dat je het ook moet doen.

Bijna alle projecten die in C++ geschreven zijn, en van redelijke grootte zijn, zijn OO vziw. Dat is waarom ik C++ zou indelen als OO-taal. Mijn punt is, je kan een programmeer taal niet per definitie OO of niet OO noemen, maar jij claimt keihard dat C++ niet OO is. Hopelijk kan je het wel met me eens zijn dat C++ in elk geval voor het overgrote meerendeel wel als OO taal gebruikt word.

[bomberboy]

Om het eens omgekeerd te doen: Wat zou je eigenlijk graag doen met je nieuwe programmeerkennis? Kleine tooltjes maken voor jezelf, je eigen kennis uitbreiden, freelance werk, games?
Op de vraag van wat voor platform heb je al deels geantwoord natuurlijk, maar opnieuw wat voor applicaties wil je voor die platformen maken?

Het is allemaal heel leuk om hier wat te roepen dat je met taal X of platform Y moet beginnen om "echt" te leren programmeren, voor welke definitie van "echt" dan ook, maar iedere taal of ieder platform heeft zijn voor en nadelen voor bepaalde toepassingen. Persoonlijk zou ik vooral beginnen met dat platform of die taal waar je het beste boek voor hebt, of de beste cursus voor hebt.

Argumentatie als met C sta je dichter bij de machine en daar leer je dus meer mee is voor mij persoonlijk onzin. Net als met een platform als .NET of Java is het veel makkelijker te leren programmeren want je hebt een virtual machine die alle moeilijke zaken voor je opknapt. Meestal is de volgorde die iemand aanraadt om de verschillende platformen/talen te bekijken ook de volgorde die hij/zij gebruikt heeft, en dat is niet noodzakelijk de beste. En misschien belangrijker, ook voor iedere persoon weer anders.
Vandaar eigenlijk ook mijn initiële vraag wat je in eerste instantie wil bereiken met je nieuwe programmeerkennis.

Mijn persoonlijk traject was rondrijden met zo'n autootje en kegels en muren detecteren (weet de naam van die omgeving niet meer), turboPascal, Java, mix van C en C++ tegelijk (niet aan te raden, ook een van de minder goede proffen die ik ooit gehad he), Haskel en Prolog en tussendoor ook nog allerlei assembler varianten en allerlei scripttalen, maar die schat ik minder belangrijk in.

Wat ik je vooral zou aanraden is om een bepaalde taal/omgeving uit te kiezen en daar een goede basiskennis van op te bouwen, al dan niet aan de hand van een cursus. Een eerste taal leren aan de hand van zelfstudie vind ik persoonlijk zeer moeilijk, vooral omdat je dan minder in contact komt met andere meningen en gebruiken waardoor je misschien een beperktere kennis opbouwt. Iemand hebben met wie je over het onderwerp kan discussiëren dus.

Dus van mij geen voorgeschotelde keuze van taal X of Y, maar misschien een aantal tips om zelf de keuze te maken die het best bij je past. (Of een boel geneuzel, je mag er zelf over oordelen )

[MLM]

Anoniem: 69437 schreef op zaterdag 17 januari 2009 @ 13:00:
[...]

Da's op zich een beetje vreemd, aangezien C# en Java even veel te maken hebben met C++ en C: vrijwel niets. Je moet je niet laten misleiden door namen die op elkaar lijken.

C# is een .NET taal, alleen is de syntaxis van de taal aangepast voor C(++) programmeurs (je gebruikt bijvoorbeeld { en } voor code blokken), net als VB.NET een .NET taal is, aangepast voor VB programmeurs (je gebruikt bijvoorbeeld IF en THEN als keywords).
Ik als C(++) programmeur kan prima C# code lezen en begrijpen, maar ik moet echt beter opletten als ik VB.NET code ga lezen. Het zijn beide gewoon high-level talen gebouwd om naar (MS)IL te compilen.

Ik heb ook nooit geclaimed dat C# op C(++) lijkt, integendeel. Maar als je als totale newb een taal wilt kiezen met een uitgebreid framework, dan zou ik inderdaad eerder aanraden om voor Java of C# te kiezen, dan C++. Tenzij je verwacht ooit te gaan devven in een context uit het lijstje dat ik iets terug postte, zou ik zelfs C(++) afraden voor iedereen

Echter, de TS overweegt NDS/PSP development, en dan kan je weinig met Java (met C# kan je ieg de XBOX360 nog op ), dus dan ga ik dat ook niet aanraden (Vergelijkingen tussen) programmeertalen zijn al ingewikkeld genoeg, en er zijn heel veel mensen die blind "hun" taal aanraden, wat het niet overzichtelijker maakt.

Had de TS gezegd dat hij PC en mobiele telefoons wou doen, dan had ik natuurlijk Java gezegd, omdat die op beide platformen ondersteund word

edit:
@bomberboy hierboven: Aldus mijn punt

[dotcode]

De basis is het belangrijkst, om de basis te leren zou ik eerst met C beginnen. Daarna overstappen naar C#, dan kan je het best begrijpen wat er echt gebeurd. Een mooie introductie op C kan je eens kijken op:
http://www.youtube.com/watch?v=Ps8jOj7diA0
De eerste paar colleges geven je een goed inzicht in hoe C / C++ werkt.

[Zoijar]

Wat wil je eigenlijk gaan programmeren? Tooltjes met user-interfaces etc.? Dan zou ik C# doen. Of programma's die dingen berekenen, of bv real-time graphics? Dan zou ik C++ leren. Wat wel zo is, is dat overstappen van C++ naar C# vrij makkelijk is, maar andersom zal dat wat meer tijd kosten. Om een taal te leren raad ik echt de O'Reilly boeken aan (bv zoiets: http://oreilly.com/catalog/9780596521066/ )

[.oisyn]

Stukfruit schreef op zaterdag 17 januari 2009 @ 10:50:
[...]


..en algoritmes die allemaal gezellig in een namespace leven als ordinaire functie?

En terecht, niets is zo onzinnig als classes te misbruiken als namespaces als je de mogelijkheid hebt om losse functies te kunnen definieren. Wat dat betreft is het gewoon jammer dat talen als Java en C# dat niet kennen, waardoor je vage "classes" als java.lang.Math krijgt.

MLM schreef op zaterdag 17 januari 2009 @ 10:29:
[...]


Want? Tis gebaseerd op (template) classes en inheritance oa, wat toch wel OO concepten zijn.

Ik kan anders niet zo snel bedenken welk deel van de STL gebruik maakt van inheritance. Wellicht wordt er in de specifieke implementaties ervan gebruik gemaakt, maar dat wordt niet geexposed naar de gebruiker toe. Feitelijk is er maar weinig OO aan de STL. OOP is niet gewoon "met objecten", het paradigma omschrijft veel meer dan dat (zoals de interacties tussen objecten middels message passing). De STL aan de andere kant neigt veel meer naar generic programming. Er zijn geen container en iterator base classes en vrijwel alle algoritmes zijn geïmplementeerd buiten de containers zelf.

[ Voor 88% gewijzigd door .oisyn op 18-01-2009 21:49 ]

[TaraWij]

Anoniem: 69437 schreef op zaterdag 17 januari 2009 @ 13:00:
[...]

Da's op zich een beetje vreemd, aangezien C# en Java even veel te maken hebben met C++ en C: vrijwel niets. Je moet je niet laten misleiden door namen die op elkaar lijken.

Ja, maar hij vermeld die keuze niet, en uiteraard lijken programmeertalen grotendeels op elkaar, ze zijn er dan ook ieder voor gemaakt om te programmeren. :-)

[Alain]

dotcode schreef op zondag 18 januari 2009 @ 09:25:
Een mooie introductie op C kan je eens kijken op:
http://www.youtube.com/watch?v=Ps8jOj7diA0
De eerste paar colleges geven je een goed inzicht in hoe C / C++ werkt.

offtopic:
Erg interresante link! Ik moet donderdag een cursus geven over talstelsels en binair rekenen. Ik had eigenlijk weinig voorbereid maar als ik het eerste stukje van Lecture 2 laat zien ben ik al een heel eind.

[Hydra]

dotcode schreef op zondag 18 januari 2009 @ 09:25:
De basis is het belangrijkst, om de basis te leren zou ik eerst met C beginnen.

Ik krijg altijd het idee dat mensen die aanraden met C te beginnen als 'basis' zelf maar wat aanprutsen en geen fatsoenlijke opleiding gehad hebben. Ik ben zelf op de middelbare school me zelf Pascal en C aan gaan leren, en heb daar in m'n HIO opleiding waar we met Java begonnen behoorlijk veel last van gehad.

Als je wilt leren programmeren MOET je IMHO met een 'managed' OO taal als Java of C# beginnen. Dan leer je OO programmeren en door middel van code een computer 'dingen' te laten doen. Je wilt eerst basic dingetjes gaan doen, en later ga je dan moeilijkere zaken als netwerken of threading uitwerken. En je wilt een beginner daar in C aan laten werken? Ik vind het didactisch onverantwoord een beginnen in het diepe te flikkeren met C++, laat staan C (over 'dead end' gesproken). In het begin zullen de segfaults je om de oren vliegen, wat alleen maar een hoop frustratie oplevert als je het allemaal zelf moet doen.

TaraWij schreef op zondag 18 januari 2009 @ 19:39:
Ja, maar hij vermeld die keuze niet, en uiteraard lijken programmeertalen grotendeels op elkaar, ze zijn er dan ook ieder voor gemaakt om te programmeren. :-)

C# en Java beschermen je vele malen beter tegen beginnersfouten dan C++, en hebben een veel meer straightforward API waar je heel makkelijk echt vanalles mee kunt doen. Van threading en networking tot GUI's en XML. IMHO is C++, als het op 'gewone' applicaties aanbouwen komt, gewoon dood.

RevellNL schreef op vrijdag 16 januari 2009 @ 23:13:
Als eerste ga ik me dan toch op C / C++ orienteren voordat ik aan C# begin om de redenen die jullie noemen, dat ik anders in een, voor mijn gevoel, prehistorische omgeving terechtkom.

Ik vind het dus diep en diep triest dat door dit "kijk mij eens cool zijn" gegochel jij op het verkeerde spoor gezet wordt. Kennelijk herinneren mensen zich niet meer hoe moeilijk het eerste begin was, dat ze je aanraden om met C bezig te gaan.

[ Voor 33% gewijzigd door Hydra op 19-01-2009 17:11 ]

[MLM]

Hydra schreef op maandag 19 januari 2009 @ 17:06:
[...]
...verhaal...

Ja en nee.

Als je high-level begint, dan is de stap naar low-level ineens wel moeilijk: je moet met allerlei concepten rekening houden, waarvan je niet wist dat ze bestonden (pointers/memory, een string is een null-terminated array etc). Daar ga je echt tegenaan lopen zeg maar

Andersom, je leert niet echt snel in een low-level taal, en de fouten die je quote ga je zeker maken (nullpointers etc).

Om volkomen eerlijk te zijn, ik weet niet wat de "efficiente" manier is om dit te leren. Ik kan enkel en alleen uit mijn eigen ervaring spreken, en van een beperkt aantal mensen om me heen, maar die zijn allemaal C++ biassed (incl. ikzelf), aangezien we specialiseren in game-programming.

Wat ik wel feitelijk kan zeggen is dat de PCs van tegenwoordig zoveel processing power hebben dat je in de gemiddelde applicatie echt de optimalisatie-mogelijkheden van C(++) niet nodig hebt. De extra tijd die je als programmeur nodig hebt om in C++ te devven ipv in C# weegt niet echt op tegen de paar % CPU die je app minder gaat gebruiken Daarnaast, .NET framework > crt+stl imo qua newb-vriendelijkheid.

[Zoijar]

Als je low-level begint dan heb je het voordeel dat je precies ziet wat er gebeurt. Als je op hoger niveau begint, dan zijn er dingen die je gebruikt waarvan je niet snapt hoe dat dan gaat. Je gebruikt dan allemaal blackboxes; het werkt, maar hoe je computer dat nou precies doet... persoonlijk vind ik dat lastig als ik iets nieuws leer: als je de hele tijd maar leest "hoe dat werkt kan je lezen in hoofdstuk 23".

[bomberboy]

Hydra stelt het misschien iets extremer voor dan ikzelf zou doen, maar ik ben het grotendeels wel met hem eens. C en C++ hebben nog steeds hun verdienste en nut, maar zijn zeker geen silver bullets (zoals geen enkele taal/platform) dat is.

En als je dan toch zo trots bent op het weten hoe het low level moet dan kan je net zo goed beginnen met assembler. Of misschien beter nog met microcodes. Hoe dichter bij de machine hoe beter toch?
(En ja, dat heb ik in mijn opleiding effectief gedaan, zij het voor virtuele architectuur).

Black boxes zijn bovendien goed. Wees blij dat ze er zijn, dat je alle onderliggende technologie niet moet begrijpen of zelfs weten dat die bestaat. Het maakt het leven alleen maar makkelijker.

Tot slot is het helemaal niet vanzelfsprekend om van een lager abstractieniveau naar een hoger abstractieniveau te gaan. Naar mijn mening zijn beide stappen vaak even moeilijk. Zoek op het forum maar naar de discussies over de overgang van proceduraal programmeren naar object geörienteerd programmeren.

Elke taal en elk platform heeft zijn doelen en doet waar het goed in is, en moet op de juiste plaats gebruikt worden.

[MLM]

bomberboy schreef op maandag 19 januari 2009 @ 17:52
...
Elke taal en elk platform heeft zijn doelen en doet waar het goed in is, en moet op de juiste plaats gebruikt worden.

QFT

Maar black boxes zijn nodig tegenwoordig. Het is onmogelijk om "alles" te weten, en geen black boxes nodig te hebben.

Als simpel voorbeeld in een low level taal, de sprintf functie. Als je wilt weten hoe en waarom het werkt (variadic argument lists, stacks, string parsing etc), dan mag je wmb los gaan. Maar ik denk niet dat veel C++ programmeurs dat echt weten, en het is niet nodig. Je weet wat het doet, en je weet hoe je het moet gebruiken (documentation). Het niet willen gebruiken van black boxes heeft nogal wat weg van het NIH syndroom, waar best veel programmeurs last van hebben (ik heb het mezelf moeten afleren )

[Hydra]

MLM schreef op maandag 19 januari 2009 @ 17:23:
Als je high-level begint, dan is de stap naar low-level ineens wel moeilijk: je moet met allerlei concepten rekening houden, waarvan je niet wist dat ze bestonden (pointers/memory, een string is een null-terminated array etc). Daar ga je echt tegenaan lopen zeg maar

Daar ga je ook tegenaan lopen als je er meteen mee begint, maar je gaat harder op je snufferd omdat je ook andere dingen fout doet.

Andersom, je leert niet echt snel in een low-level taal, en de fouten die je quote ga je zeker maken (nullpointers etc).

Een nullpointerexception geeft je een nette stacktrace met een regel en kolomnummer. Toen ik met C++ bezig ging was het "POOF, SEGFAULT" en moest ik maar uitzoeken waar de fout zat. Zie dat maar eens te vinden met al die manieren waarop je in C++ geheugen kunt benaderen. Dat memorymanagement is voor een beginner gewoon een enorme drempel.

Om volkomen eerlijk te zijn, ik weet niet wat de "efficiente" manier is om dit te leren. Ik kan enkel en alleen uit mijn eigen ervaring spreken, en van een beperkt aantal mensen om me heen, maar die zijn allemaal C++ biassed (incl. ikzelf), aangezien we specialiseren in game-programming.

Die kun je niet vergelijken. Zoals ik al zei ben ik zelf met Pascal en C begonnen (ook in assembly bezig geweest) en wist redelijk hoe een CPU werkt, en had dus een 'voorsprong' op mensen die dat niet hadden, en die hadden met Java al problemen genoeg.

Wat ik wel feitelijk kan zeggen is dat de PCs van tegenwoordig zoveel processing power hebben dat je in de gemiddelde applicatie echt de optimalisatie-mogelijkheden van C(++) niet nodig hebt. De extra tijd die je als programmeur nodig hebt om in C++ te devven ipv in C# weegt niet echt op tegen de paar % CPU die je app minder gaat gebruiken Daarnaast, .NET framework > crt+stl imo qua newb-vriendelijkheid.

Dat sowieso, maar dat heeft ook niks met beginners te maken. Zoals ik al zei is dat, als het op gewone apps (dus geen games die zo performance kritisch als de pest zijn) aankomt, C++ gewoon dood.

bomberboy schreef op maandag 19 januari 2009 @ 17:52:
Hydra stelt het misschien iets extremer voor dan ikzelf zou doen, maar ik ben het grotendeels wel met hem eens.

Ik stel het een beetje 'extreem' omdat ik dat elitaire geneuzel een beetje jammer vindt. Volgens mij weet iedere fatsoenlijke (met opleiding) developer best dat je beter met een 'makkelijke' taal kunt beginnen, maar is het veel 'stoerder' om C++ te coden. C++ is echt heel leuk om in te proggen, en zeker iets om je goed in te verdiepen als je eenmaal C# bijvoorbeeld onder de knie hebt, maar niet meer dan dat. Alleen als je echt specialistische gebieden in wilt (gamedev) heeft het echt nut veel met C++ te doen. Als je perse wilt weten wat een CPU lowlevel doet moet je gewoon met assembly bezig gaan, en niet met C++.

[netvor]

Met Hydra. Ik kom ongeveer uit hetzelfde traject: in mijn tienerjaren, toen ik nog dacht dat "leren programmeren" en "een computertaal onder de knie krijgen" hetzelfde waren, heb ik mezelf ook vanalles aangeleerd, voornamelijk varianten van pascal en een scripttaal of twee. En net als Hydra had ik vervolgens moeite toen ik op de uni leerde programmeren m.b.v. Java.

Ik denk dat als de programmeervakken in het eerste jaar op C waren gebaseerd, dat ik dan veel langer aan mijn oude brakke programmeerstijl zou zijn blijven hangen; in C heb je genoeg vrijheid om te doen wat je wilt en word je minder gedwongen tot een meer gestructureerde aanpak dan in Java/C#.

Een voorbeeldje; ergens vroeg in de herfst van mijn eerste semester vroeg ik me al af, "en waarom moet ik nou in hemelsnaam een class maken als ik alleen maar wat helloWorld geneuzel in de publicstaticvoidmain wil zetten?" Een paar weken later was dit ineens heel vanzelfsprekend.

Tot slot heb ik nog een kleine disclaimer: de meeste mensen die succesvol (denken te) programmeren, zullen op een vraag als deze aan de hand van hun eigen ervaringen reageren. In het geval van Hydra, mijzelf en ik denk een groot deel van de aanwezigen alhier betekent dat dat ze je zullen aanraden om een vergelijkbaar traject te kiezen als wat zij op de universiteit voorgeschoteld hebben gekregen. Op zich is daar niets mis mee (zo werken universiteiten al een paar eeuwen), maar houd het in je achterhoofd.

Mijn vrouw is arts, en in de tijd dat zij naar de universiteit ging waren de verschillende medische faculteiten elk aan het experimenteren met trajecten die afweken van het standaardmodel van anatomie->biochemie->histologie->de rest, om de studenten eerder in contact te brengen met echte casussen van echte patienten. Ik geloof dat ze daar nu, een jaar of zes later, allemaal op terug gekomen zijn. Don't change a winning team, lijkt het advies.

[.oisyn]

netvor schreef op maandag 19 januari 2009 @ 18:25:
Een voorbeeldje; ergens vroeg in de herfst van mijn eerste semester vroeg ik me al af, "en waarom moet ik nou in hemelsnaam een class maken als ik alleen maar wat helloWorld geneuzel in de publicstaticvoidmain wil zetten?" Een paar weken later was dit ineens heel vanzelfsprekend.

Ik vind het nog altijd niet vanzelfsprekend anders. Misschien dat jij het kan uitleggen?

[prototype]

Over de volgorde van leren heb ik me in m'n vorige post niet over uitgelaten, maar wil dat bij deze wel even rechtzetten. Als je object orientatie wil leren zou ik eigenlijk niet eens C# willen aanraden om mee te beginnen, maar een "pure" object oriented taal zoals smalltalk(verbaast me dat deze niet vaak genoeg aangehaald wordt als het over OO gaat, het is immers DE TAAL van het model)/ruby waarbij zowat alles een object is. Sure, je kan met de reflection api taalconstructies ook als objecten benaderen, maar in een taal als b.v. Ruby is dit veel intuitiever, i.e. verwerkt in de mogelijkheden van de taal zelf. Op deze weg kan je ook over het messaging passing model leren dat erachter schuil gaat en dit kan je weer gebruiken om te leren hoe je dergelijke messages kan intercepten en toe kan passen voor andere krachtige paradigms (functioneel, meta programming, aspect orientation b.v.). Ook kan je -- om even iets te noemen -- geleidelijk opbouwen van het responsemodel naar het inzien waar interfaces goed voor zijn etc...

De les waar iedereen het in ieder geval over eens lijkt te zijn is dat je eerst dient te leren programmeren (paradigms __en__ talen, talen zijn immers de tool voor de paradigm en beiden dien je te masteren imo) om echt goed te worden. De keuze voor een dynamische object georienteerde taal om mee te beginnen lijkt me dan ook geen slechte zet als je je vooral wil verdiepen in deze fase op concepten. Wat veel mensen misschien vergeten is dat "snel resultaat" zien een goede motivatie is om door te blijven proberen en bijdraagt aan het leerproces. In het verlengde daarvan zou noch C noch C++ als een goed beginpunt en alleen al aan mijn vorige post is denk ik wel af te leiden waarom. Een taal als -- dare I say it -- PHP daarentegen?

[netvor]

@Oisyn: Omdat dat de Java filosofie is. Everything is an object. En elk object is een instance van een class. Dus zodra je "iets" wilt hebben, heb je een class nodig. Okee, deze kort-door-de-bocht "Java in 30 woorden" uitleg geeft nog steeds niet aan waarom het nodig is een class te maken als je alleen wat met de main() wilt doen, maar het maakt het wel begrijpelijker.

@Prototype: als je je door snel resultaat wilt laten motiveren, dan lijkt Smalltalk me een zeer slechte keus. IMHO is smalltalk veels te geitenwollensokken om er praktijkgericht mee te leren programmeren. Ikzelf ben er nog steeds niet uit of het nou een programmeertaal, besturingssysteem of databasesysteem is. Tenminste, dat is mijn ervaring met VisualWorks.

[ Voor 33% gewijzigd door netvor op 19-01-2009 18:59 ]

[Anoniem: 281802]

Is in Java alles wel een object? Je hebt toch ook nog zoiets als primitieven e.d.?

[.oisyn]

netvor schreef op maandag 19 januari 2009 @ 18:53:
Omdat dat de Java filosofie is. Everything is an object.

Een int is geen object. Een functie is ook geen object. Je static void main() is ook geen object.

Dus zodra je "iets" wilt hebben, heb je een class nodig.

Da's dus onzin. De main() is een static functie. Hij zit dan wel in een class, maar je class hoeft niet geinstantieerd te (kunnen) worden. Kijk, als je voor je applicatie entry point nou een interface moest implementeren oid, dan had ik het nog wel begrepen. Hoewel dat nog steeds niet het generiekere geval verklaart, namelijk waarom functies alleen binnen classes gedefinieerd mogen worden.

[Herko_ter_Horst]

Niet dat ik netvor's standpunt wil verdedigen dat Java nou het uitgelezen voorbeeld van een pure OO taal is, maar hij zegt wel dat je een class nodig hebt, geen object.

De main methode (niet: functie) is overigens een slecht voorbeeld, omdat die methode voor de runtime een speciale betekenis heeft. Verder is er overigens niets speciaals aan en is het als keuze voor het starten van een OO applicatie nog niet eens zo vergezocht.

[netvor]

Zucht. Ik zeg ook helemaal niet dat Java een soort Smalltalk is, waarin alles volgens de meest pure OO principes is opgebouwd. Ik had het over de filosofie achter Java, de achterliggende gedachte van Gosling en zijn team toen ze de taal en het platform ontworpen. In de wereld van Java is alles netjes gestructureerd in een hierarchie van packages en classes. Via wat creatieve omwegen hebben zelfs primitieven een plaatsje in die rangorde, en ook de main() is, min of meer terug te vinden in de java.lang.reflect namespace.

Mijn oorspronkelijke punt was dat dit aspect van Java het een goede beginnerstaal maakt. Door de structuur die er al inzit is het makkelijker om een zelfde soort structuur aan te brengen in je eigen werk. Dat was mijn enige punt. Dat mijn dertigwoordige samenvatting van wat java is vervolgens een beetje brak was, daar ben ik het geheel mee eens.

[Hydra]

prototype schreef op maandag 19 januari 2009 @ 18:47:
Een taal als -- dare I say it -- PHP daarentegen?

PHP is net zo min als C++ 'puur' OO (even afgezien van het feit dat Java natuurlijk ook primitives heeft), de API is zelf absoluut niet OO. Daarnaast ben ik geen voorstander van dynamisch getypeerde talen als 'leer'taal, aangezien je juist door de strictere structuur van Java minder fouten maakt. Suffe cast fouten maak je al niet omdat de compiler die voor je afvangt.

Ik vind Java een goeie mix van OO en praktisch. Java (/C#) ervaring is bovendien iets wat hoe dan ook op je CV erg goed staat.

netvor schreef op maandag 19 januari 2009 @ 19:53:
Zucht. Ik zeg ook helemaal niet dat Java een soort Smalltalk is, waarin alles volgens de meest pure OO principes is opgebouwd.

IMHO kun je Smalltalk en Java verglijken als godsdiensten. Java heeft meer de praktische Boedhistische aanpak. Smalltalk is wat extremistischer Niks mis met Smalltalk overigens, wel eens wat mee gedaan en ik vind het "Everything's an object" princiepe erg leuk.

[ Voor 27% gewijzigd door Hydra op 19-01-2009 20:46 ]

[prototype]

Hydra schreef op maandag 19 januari 2009 @ 20:44:
[...]


PHP is net zo min als C++ 'puur' OO (even afgezien van het feit dat Java natuurlijk ook primitives heeft), de API is zelf absoluut niet OO. Daarnaast ben ik geen voorstander van dynamisch getypeerde talen als 'leer'taal, aangezien je juist door de strictere structuur van Java minder fouten maakt. Suffe cast fouten maak je al niet omdat de compiler die voor je afvangt.

En hier ben ik het dus niet mee eens. Fouten maken is opzich helemaal niks mis mee als je er wat van leert. Bij C/C++ zijn de fouten echter over het algemeen dusdanig lastiger te ontdekken (laat staan te fixen) dat het voor een beginnerling onoverkomelijk kan zijn en het hem/haar remt in het leerproces. Bij PHP is het instap niveau toch echt een stuk lager wat dit betreft.

Types hebben "bijna geen betekenis" in dynamische talen, aangezien je vaak adhoc de interface kan aanpassen tijdens runtime en het dan vooral gaat om of een object "reageert" op een invocation message (iets wat javascript en ruby je zullen leren). En dat is dus ook direct mijn punt dat je tot realisatie kan doen komen waar interfaces o.a. voor gebruikt worden. En daarbij, de strictere structuur is evengoed een voordeel als dat het een nadeel is. Veel programmeurs zijn van mening dat de strictheid je doet aanzetten tot overvloedig annoteren wat op zijn beurt weer aanzet tot boilerplate code schrijven, wat zowel de productiviteit als de onderhoudbaarheid weer niet ten goede komt. Een van de redenen ook waarom een taal als Python het nu ook enorm goed doet in de industrie waar voorheen Java enkel heer en meester was door het hebben van dynamiek. Als we het dan toch over CV hebben staat een dynamische taal dus zeker ook niet verkeerd erop ;-) De nadruk leg ik hier dan ook op ook.

[Woy]

Het meeste is al wel gezegd hier. Maar de TS wil graag een beetje windows programma's maken en eventueel ook wat games.

Met C# is het ook eenvoudig om voor de XBOX 360 te programmeren met XNA game studio. Je kan daar misschien geen grote commerciele titels mee maken, maar wat casual games kan wel. En het grote voordeel is dat het gewoon door MS ondersteund word, en het een eenvoudige omgeving is om mee te beginnen.

Voor platformen als de NDS en de PSP zul je ieder geval wel bij C/C++ moeten zijn, en ook zul je daar wat meer moeite moeten doen om zelf software te maken.

[prototype]

Als ik me niet vergis ligt de trend eigenlijk steeds meer om met C# en .net te werken icm Mono voor de Wii iig. Op de wii is onlangs zelfs de eerste titel verschenen als ik me niet vergis die volledig gebouwd is adhv C# + mono: http://tirania.org/blog/archive/2009/Jan-06.html

[.oisyn]

Herko_ter_Horst schreef op maandag 19 januari 2009 @ 19:19:
Niet dat ik netvor's standpunt wil verdedigen dat Java nou het uitgelezen voorbeeld van een pure OO taal is, maar hij zegt wel dat je een class nodig hebt, geen object.

Ja maar dat is nou de kern van deze subdiscussie. Waarom heb je per se een class nodig? Dan krijg je van die halfbakken abstract final classes als namespace om functies in te vergaren zoals de Math classes in Java en .Net. En ik snap wel dat dat vanuit het designperspectief van de implementatie van een taal handiger is op die manier, maar ik krijg nu het idee dat mensen denken dat dat "mooier" OO is, en dat vind ik, quite frankly, complete onzin. Een Math class heeft weinig met OO te maken. En terecht, het zijn letterlijk functies (in de wiskundige betekenis van het woord) zonder state (ok, Math.random() vormt een uitzondering, maar die past dan ook meer in een Random class en hoort eigenlijk niet tussen de Math functies), die een input middels een berekening omzetten in een output. Daar is niets OO aan en daar hoeft geen object of class bij te komen kijken.

De main methode (niet: functie)

Methodes, functies, subroutines, procedures... Allemaal van hetzelfde laken een pak.

is overigens een slecht voorbeeld, omdat die methode voor de runtime een speciale betekenis heeft. Verder is er overigens niets speciaals aan en is het als keuze voor het starten van een OO applicatie nog niet eens zo vergezocht.

Maar als functies niet classes hadden hoeven leven, dan had main() dat ook niet gehoeven. Ik snap je redenatie dan ook niet helemaal. Main() is helemaal geen slecht voorbeeld, het is juist een uitstekend voorbeeld van een applicatie entry point dat in feite geheel los staat van een class, maar in een class moet zitten omdat er nou eenmaal geen andere manier is.

[ Voor 31% gewijzigd door .oisyn op 19-01-2009 22:53 ]

[Zoijar]

Zo traag zijn games in C# niet hoor. Veel intensieve dingen doe je toch op de GPU, zoals rendering en physics. Het enige dat C# dan doet is wat API calls. Als je echt een game maakt dan zie ik geen rede om het niet in C++ te doen, maar als je alleen C# kent en je wilt gewoon wat proberen dan werkt het prima.

OOP is natuurlijk een grote hype, altijd al geweest. OOP bestond lang voordat alles ineens OO moest zijn. Het is eigenlijk gewoon in functionaliteiten denken en afgebakende stukjes code met een eigen afgeschermde state.

(PHP en PERL scheer ik over een kam, samen met het oude VB; nuff said )

[ Voor 31% gewijzigd door Zoijar op 19-01-2009 22:47 ]

[GroeneEend]

Zoijar schreef op maandag 19 januari 2009 @ 22:41:
Zo traag zijn games in C# niet hoor. Veel intensieve dingen doe je toch op de GPU, zoals rendering en physics. Het enige dat C# dan doet is wat API calls. Als je echt een game maakt dan zie ik geen rede om het niet in C++ te doen, maar als je alleen C# kent en je wilt gewoon wat proberen dan werkt het prima.

OOP is natuurlijk een grote hype, altijd al geweest. OOP bestond lang voordat alles ineens OO moest zijn. Het is eigenlijk gewoon in functionaliteiten denken en afgebakende stukjes code met een eigen afgeschermde state.

(PHP en PERL scheer ik over een kam, samen met het oude VB; nuff said )

Nee, OO is zeker niet in functionaliteiten denken! In zekere zin klopt het natuurlijk wel, met OO doe je aan decompositie in classes en in meer functioneel georieenteerde talen in decompositie in units of modules. Het is echter een misvatting om in functionaliteiten te denken. Enkele principes, zoals encapsilation, inheritance en het bijbehorende polymorphism zijn bij voorbeeld essentiele principes die veel verder gaan dan denken in functionaliteiten en afgebakende stukjes code. Ik geeft toe dat OO vaak zo wordt gebruikt, maar dat komt meer door onkunde over OO (bv door VB6).

En dan heb ik het alleen nog over de code zelf. Het analyseren en ontwerpen van systemen gaat bij elke beetje moderne methode ook met OO principes.

[GroeneEend]

C# leren is nooit verkeerd, de principes e.d. zijn b.v. nauw verwant met Java. Als je de principes van C# kent, kan je ook makkelijk in andere moderne OO talen werken.

C en C++ zijn een stuk complexer. Als je op b.v. een iPhone of Nintendo DS wil ontwikkelen, moet je inderdaad wel resp. Objective-C / C gebruiken, maar daar zou ik pas naar kijken als je daadwerkelijk met die apparaten aan de slag gaat. Je gaat dan toch vrij specifiek voor die devices ontwikkelen.

Ik ben zelf gek op C++, maar ik vermoed dat jij er weinig aan zult hebben. Ik merk helaas dat dit steeds minder gebruikt worden. UI ontwikkelen met de meeste C++ IDE's is hopeloos in mijn ervaring vergeleken met C#/XAML. Mocht je voor C++ gaan, gebruik dan wel bibliotheken van Boost e.d., dat scheelt een hoop ellende.

Maar het ligt er ook maar aan wat voor ervaring en kennis je hebt. Als je nog nooit hebt geprogrammeerd is het verreweg het makkelijkst om met C# te beginnen.

[Zoijar]

GroeneEend schreef op maandag 19 januari 2009 @ 23:31:
Nee, OO is zeker niet in functionaliteiten denken! In zekere zin klopt het natuurlijk wel, met OO doe je aan decompositie in classes en in meer functioneel georieenteerde talen in decompositie in units of modules. Het is echter een misvatting om in functionaliteiten te denken. Enkele principes, zoals encapsilation, inheritance en het bijbehorende polymorphism zijn bij voorbeeld essentiele principes die veel verder gaan dan denken in functionaliteiten en afgebakende stukjes code. Ik geeft toe dat OO vaak zo wordt gebruikt, maar dat komt meer door onkunde over OO (bv door VB6).

En dan heb ik het alleen nog over de code zelf. Het analyseren en ontwerpen van systemen gaat bij elke beetje moderne methode ook met OO principes.

Encapsulatie is het afschermen van gerelateerde functionaliteit in een eenheid, inheritance het modulair uitbreiden van bestaande functionaliteit en polymorphisme het transparant maken van functionaliteit. Op zich natuurlijk een goede design strategie, maar niet beperkt tot zuiver OO talen met classes en inheritance etc. Generic programming doet bv hetzelfde, afgebakende functionaliteit in een implementatie, uitbreidbaarheid van functionaliteit door verschillende policies, en een impliciete vorm van polymorphisme door het implementeren van verschillende concepts. De STL van C++ is eerder generic dan OO, wat samen met C++ templates het net zo goed een generic taal maakt als een OO taal. Eerlijk gezegd gebruik ik vrij zelden echt inheritance en virtual functions etc. Ik vind het ook vaak een vrij omslachtige manier van werken. Er ligt vaak te veel focus op inheritance en polymorphisme in programmeer boeken, terwijl dat geen essentiele programmeer skills zijn. Zeker niet aan het begin. De enige essentiele skill aan het begin is eigenlijk data structuren, en dat leer je het beste op laag niveau met pointers in C/C++. Java en C# maken dat alleen maar moeilijker met hun hele idee dat je alleen objecten hebt, maar als je dan een object mee geeft dan is het niet het object maar een referentie naar het object en als je het echt wilt kopieren moet je een copy() methode aanroepen, maar Java is call-by-value, dus als je een object assigned in een functie dan overschrijf je het niet want de reference is lokaal, behalve als je dan een methode van het object gebruikt, want dan dereference je.... of als je het in C# dan een "out" var maakt kan je er wel naar schrijven... maar moeilijke en ingewikkelde pointers hebben we daar niet!

[ Voor 16% gewijzigd door Zoijar op 20-01-2009 00:47 ]

[GroeneEend]

Zoijar schreef op dinsdag 20 januari 2009 @ 00:38:
[...]

Encapsulatie is het afschermen van gerelateerde functionaliteit in een eenheid, inheritance het modulair uitbreiden van bestaande functionaliteit en polymorphisme het transparant maken van functionaliteit. Op zich natuurlijk een goede design strategie, maar niet beperkt tot zuiver OO talen met classes en inheritance etc. Generic programming doet bv hetzelfde, afgebakende functionaliteit in een implementatie, uitbreidbaarheid van functionaliteit door verschillende policies, en een impliciete vorm van polymorphisme door het implementeren van verschillende concepts. De STL van C++ is eerder generic dan OO, wat samen met C++ templates het net zo goed een generic taal maakt als een OO taal. Eerlijk gezegd gebruik ik vrij zelden echt inheritance en virtual functions etc. Ik vind het ook vaak een vrij omslachtige manier van werken. Er ligt vaak te veel focus op inheritance en polymorphisme in programmeer boeken, terwijl dat geen essentiele programmeer skills zijn. Zeker niet aan het begin. De enige essentiele skill aan het begin is eigenlijk data structuren, en dat leer je het beste op laag niveau met pointers in C/C++. Java en C# maken dat alleen maar moeilijker met hun hele idee dat je alleen objecten hebt, maar als je dan een object mee geeft dan is het niet het object maar een referentie naar het object en als je het echt wilt kopieren moet je een copy() methode aanroepen, maar Java is call-by-value, dus als je een object assigned in een functie dan overschrijf je het niet want de reference is lokaal, behalve als je dan een methode van het object gebruikt, want dan dereference je.... of als je het in C# dan een "out" var maakt kan je er wel naar schrijven... maar moeilijke en ingewikkelde pointers hebben we daar niet!

C++ is natuurlijk in feite zowel een functionele taal, een generic taal en een oo taal. Je kan er alle kanten mee op Dat vind ik zelf ook een groot voordeel van C++, je hebt de voordelen van alle drie de concepten.

Encapsulatie is het is het afschermen van (bepaalde) eigenschappen van een object (de functionaliteit wordt geboden door de methodes volgens mij). In OO omgeving zal je die eigenschappen altijd via een methode moeten benaderen. Dit heeft zeer grote voordelen, vooral als de eigenschap gerelateerd is aan andere onderdelen en specifieke acties ondernemen moeten worden indien bv de eigenschap wijzigt. Dit kan je ook wel in een functionele taal implementeren, maar dat is complexer en aanzienlijk slechter onderhoudbaar.

Polymorphism is erg handig om b.v. zonder de basiscode te wijzigen nieuwe functionaliteit toe te voegen. Ok, voor kleinere systemen meestal een overkill, maar voor vrijwel alle systemen waarbij ik betrokken ben geweest bijzonder effectief, en vooral begrijpelijk.

En een van de grote voordelen van OO is natuurlijk het bijhouden van de state van een object. Een normaal systeem zal meerder instanties hebben van een class. Wil je dat op een meer funtionele manier bijhouden, is het een flink gehannes. Ik was dolblij dat er na jarenlang met functionele talen (Modula, Pascal, Clipper, C) gewerkt te hebben, OO talen kwamen (Class(y), Java, C++, C#).

Je hebt gelijk, je kan een hoop van dat soort dingen ook zonder OO technieken doen, maar dat kost aanzienlijk meer moeite om het begrijpbaar en onderhoudbaar te doen. Voor thuisgebruik en kleine of persoonlijke applicaties is dat misschien niet zo nodig of belangrijk, maar voor grotere systemen, zoals in het bedrijdsleven, zijn dat belangrijke kwaliteitseisen.

Datastructuren geven ze aan de universiteit overigens tegenwoordig ook met Java, kan wel kennelijk ook prima. Wel wat anders dan de C code die ik moest schrijven, zonder memory leaks

Ik heb aardig wat praktische programmeerervaring van wetenschappelijke en commerciele toepassingen, en ik kan je verzekeren: OO programmeren is aanzienlijk efficienter, begrijpelijker, onderhoudbaarder, beter testbaar, beter ontwerpbaar, etc, etc dan functioneel programmeren. Wel is het zo dat je enige training en ervaring vereist is, maar daar zorgen ook alle opleidingen ruimschoots voor.

[ Voor 20% gewijzigd door GroeneEend op 20-01-2009 02:42 ]

[PrisonerOfPain]

Zuch, weer zo'n talen discussie waar niemand een concreet antwoord op heeft maar wel iets over kan zeggen. Uiteindelijk heeft de vraagsteller er geen moer aan omdat er toch geen concreet antwoord uit komt, en worden er alleen nog maar meer feitelijke onjuistheden op het internet geplaatst.

GroeneEend schreef op dinsdag 20 januari 2009 @ 02:11:
Ik was dolblij dat er na jarenlang met functionele talen (Modula, Pascal, Clipper, C)

Sorry, maar als je na 30 jaar 'praktijk ervaring' een post maakt waarin zoveel verifieerbare onjuistheden staan en dan ook nog dat lijstje talen onder de functionele noemer wilt scharen heb je op z'n zachtst gezegt niet opgelet.

[Woy]

Zoijar schreef op maandag 19 januari 2009 @ 22:41:
Zo traag zijn games in C# niet hoor. Veel intensieve dingen doe je toch op de GPU, zoals rendering en physics. Het enige dat C# dan doet is wat API calls. Als je echt een game maakt dan zie ik geen rede om het niet in C++ te doen, maar als je alleen C# kent en je wilt gewoon wat proberen dan werkt het prima.

Ik zeg ook niet dat C# traag is. Ik zeg dat je met C# geen grote commerciele titels gaat maken. Er komen natuurlijk nog meer dingen bij een Game kijken als alleen het renderen. De Physics, Collision Detection, AI en dergelijk kunnen ook een vrij zware belasting op je processor leggen. Voor simpele spellen hoeft het inderdaad geen probleem te zijn.

Als je ziet op creators.xna.com zie je ook vrij complete games met redelijke graphics.

prototype schreef op maandag 19 januari 2009 @ 22:30:
Als ik me niet vergis ligt de trend eigenlijk steeds meer om met C# en .net te werken icm Mono voor de Wii iig. Op de wii is onlangs zelfs de eerste titel verschenen als ik me niet vergis die volledig gebouwd is adhv C# + mono: http://tirania.org/blog/archive/2009/Jan-06.html

Grappig dat ze Mono ook geport hebben naar de Wii, dat wist ik helemaal niet. Heb ik indirect ook wat op de Wii geprogrammeerd

[ Voor 23% gewijzigd door Woy op 20-01-2009 08:55 ]

[GroeneEend]

PrisonerOfPain schreef op dinsdag 20 januari 2009 @ 02:32:
Zuch, weer zo'n talen discussie waar niemand een concreet antwoord op heeft maar wel iets over kan zeggen. Uiteindelijk heeft de vraagsteller er geen moer aan omdat er toch geen concreet antwoord uit komt, en worden er alleen nog maar meer feitelijke onjuistheden op het internet geplaatst.


[...]


Sorry, maar als je na 30 jaar 'praktijk ervaring' een post maakt waarin zoveel verifieerbare onjuistheden staan en dan ook nog dat lijstje talen onder de functionele noemer wilt scharen heb je op z'n zachtst gezegt niet opgelet.

Ok,je hebt gelijk. Lisp e.d. zijn functionele talen Ik bedoelde in deze echter niet de officiele definitie, maar talen niet zijnde object georienteerde talen, waar je met units/modules en functies werkt in plaats van met classes en methoden. Je hebt zeker gelijk, maar anders moet je wel erg veel uitleggen in zo'n topic.

Maar onjuistheden? Wijs ze maar aan dan als ze zo makkelijk verifieerbaar onjuist zijn

[Woy]

GroeneEend schreef op dinsdag 20 januari 2009 @ 09:27:
[...]


Ok,je hebt gelijk. Lisp e.d. zijn functionele talen Ik bedoelde in deze echter niet de officiele definitie, maar talen niet zijnde object georienteerde talen, waar je met units/modules en functies werkt in plaats van met classes en methoden. Je hebt zeker gelijk, maar anders moet je wel erg veel uitleggen in zo'n topic.

Maar onjuistheden? Wijs ze maar aan dan als ze zo makkelijk verifieerbaar onjuist zijn

Je hebt het denk over Procedurele talen. Functionele talen zijn compleet wat anders, en juist Lisp is wel een Functionele taal!

[Zoijar]

Komt ook omdat ik het over functionaliteit had, maar daar bedoelde ik uiteraard geen functionele taal mee, was geheel iets anders is.

Een lange discussie is niet nodig denk ik; iedereen weet wel de voordelen van OOP. Mijn punt was dat het altijd zo gehyped wordt. Leren programmeren -> dan moet je OOP leren, want OOP is de holy grail... maar eigenlijk is de hele OOP _implementatie_ niets meer dan een tabelletje met functie pointers. En dan krijg je idd dingen als dat alles een class moet zijn. Maar een class zonder state is gewoon een namespace

Datastructuren kreeg ik ook in Java op de uni, maar toch zou ik dat eerder in C++ doen. Data structuren is toch juist geklooi met (triple-indirect) pointers en geheugenmanagement. Dat haal je dan allebei weg. Ach, uiteindelijk zal het niet zo veel uitmaken.

[r0_]

Als de TS met C++ aan de gang gaat kan ik hem iig dit boek aanraden:

"Aan de slag met C++" van Gert Jan Laan. (ISBN:90 395 1689 8 )

Ik heb dit boek van voor tot achter doorgewerkt en het heeft mij erg veel geleerd over C++. Wel is er nog een lange weg te gaan

[GroeneEend]

Zoijar schreef op dinsdag 20 januari 2009 @ 10:16:
Komt ook omdat ik het over functionaliteit had, maar daar bedoelde ik uiteraard geen functionele taal mee, was geheel iets anders is.

Een lange discussie is niet nodig denk ik; iedereen weet wel de voordelen van OOP. Mijn punt was dat het altijd zo gehyped wordt. Leren programmeren -> dan moet je OOP leren, want OOP is de holy grail... maar eigenlijk is de hele OOP _implementatie_ niets meer dan een tabelletje met functie pointers. En dan krijg je idd dingen als dat alles een class moet zijn. Maar een class zonder state is gewoon een namespace

Datastructuren kreeg ik ook in Java op de uni, maar toch zou ik dat eerder in C++ doen. Data structuren is toch juist geklooi met (triple-indirect) pointers en geheugenmanagement. Dat haal je dan allebei weg. Ach, uiteindelijk zal het niet zo veel uitmaken.

Als ik er ook nog eens over nadenk, denk ik dat ik toch datastructuren in C/C++ zou prefereren, om de redenen die je beschrijft. Juist bij datastructuren, wat leer je er anders van?

OOP is natuurlijk niet de holy grail, ik denk dat ik jouw reactie vannacht ook iets te gekleurd anti-OOP las, mijn excuses daarvoor Juist C++ vond ik zelf erg prettig omdat je met verschillende concepten kan werken afhankelijk van de eisen: Templates voor perfomance (scheelt echt 10-20%) , OO als je veel run-time instanties aanmaakt, etc. Maar ik vind C++ wel te ingewikkeld om te leren als je voor jezelf wat wilt programmeren, dan kom je met C# ook een heel eind.

[GroeneEend]

rwb schreef op dinsdag 20 januari 2009 @ 09:47:
[...]

Je hebt het denk over Procedurele talen. Functionele talen zijn compleet wat anders, en juist Lisp is wel een Functionele taal!

Ja precies, ik kon die term daarstraks al niet meer herinneren, procedurele talen zijn het Dank je.