[disc] cursus: c++ vs c++.net

[Vampier]

Ik heb de stap weer gezet om terug te gaan naar school voor een cursus c++, nu heb ik echter het boek eens zitten doorlezen en ben tot de conclusie gekomen dat het c++.net is en geen c++. Nu vroeg ik me af ofdat een probleem kan zijn omdat ik cross platform wil gaan developen. Een voorbeeld:


c++

code:

cout<<"Hallo Wereld"<<endl;

VS de beschrijving van het boek:

code:

Console::writeLine("hallo wereld");

Bij de cursus aanduiding staat duidelijk c++ en wordt er met geen woord gerept over C++.net. Zal ik deze cursus gaan volgen (het is een introductie en de prijs is $75 voor 2.5 maanden 1x in de week 's avonds)

_{Ik heb geen idee ofdat dit in het goede forum onderdeel staat, zo niet dan mijn excuses}

[ Voor 4% gewijzigd door Vampier op 27-01-2004 09:31 ]

[.oisyn]

Als ze daar al niets over zeggen terwijl het toch echt .net is, dan zou ik dat opvatten als zijnde enorme incompentent en de cursus dus vooral niet volgen

[Vampier]

.oisyn schreef op 26 januari 2004 @ 23:06:
Als ze daar al niets over zeggen terwijl het toch echt .net is, dan zou ik dat opvatten als zijnde enorme incompentent en de cursus dus vooral niet volgen

Ook als je naar de prijs kijkt?

wat ik dus wil weten is de denkwijze van c++.net hetzelfde als van c++, de syntax zal me een zorg zijn. Ik heb al verschillende jaren ervaring met scripttalen zoals php/asp/jscript/vbscript etc etc (zoals in mijn post history al te zien is)

Het belangrijkste voor mij is om uit de denkwijze van de scripttalen te komen (iets wat me niet echt lukt moet ik zeggen)

[farlane]

Als je een fatsoenlijke cursus C++ wilt volgen, zou ik er niet een volgen die met het .Net framework werkt. ( Als je voor .Net gaat neem je m.i. liever C# )

C++ is naar mijn idee standaard C++.

[.oisyn]

Vampier schreef op 26 januari 2004 @ 23:10:
[...]


Ook als je naar de prijs kijkt?

wat ik dus wil weten is de denkwijze van c++.net hetzelfde als van c++, de syntax zal me een zorg zijn.

nee, totaal niet, dat is het 'm juist. Met managed C++ (C++.net) zit je vast aan het .net framework en al zijn restricties (denk aan mulitple inheritance en templates die gewoon niet mogelijk zijn). Het gros van de standaard C++ functies en classes zullen ze dus links laten liggen

[Vampier]

maargoed, ik ga hem toch volgen om de simpelle reden:

- het staat goed op je CV (het is op een campus met 7000 studenten, en de naam van de school is ook wel ok schijnt)

- Het is een eerste stap voor iets wat meer gaat worden (eerst bachelors dan masters)

- Het houdt je van de straat

- Als iets niet c++ is dan willen een aantal mensen mij alsnog c++ leren.

Bovendien kan iets erbij leren kan nooit kwaad.

_{ps bedankt voor voor de aanpassing in de topic titel, ik open niet zoveel topics op GoT}

[curry684]

Vampier schreef op 27 januari 2004 @ 09:25:
maargoed, ik ga hem toch volgen om de simpelle reden:

Nofi, maar waarom vraag je het dan als je toch niet luistert?

Managed C++ is absoluut ongeschikt om C++ mee aan te leren. Je leert delegates te gebruiken en properties, die beiden niet in ANSI-C++ zitten (de eerste met hele goede reden). Je leert een framework te gebruiken dat zo platformdependent is als wat, en je leert niet omgaan met STDC-libs, met STL of met gevorderde C++ constructies die oisyn reeds aangaf.

Ergo, na het volgen van die cursus ben je slechter af als ervoor: nu ken je nog geen C++, dadelijk ken je foute C++. En afleren is gruwelijk veel moeilijker dan aanleren.

Let wel: er is niets mis met managed C++. Enige lulligheid is dat heel managed C++ met de volgende release van VC.net op de schop gaat, en dat het incompatible is met ANSI-C++. De goede volgorde is dan ook om standaard C++ eerst tot in de puntjes te beheersen voordat je gaat spelen met managed extensions.

[Alarmnummer]

curry684 schreef op 27 januari 2004 @ 09:37:
Je leert delegates te gebruiken en properties, die beiden niet in ANSI-C++ zitten (de eerste met hele goede reden).

Wat is er mis met een delegate?

[ Voor 22% gewijzigd door Alarmnummer op 27-01-2004 09:39 ]

[Janoz]

Vampier schreef op 27 januari 2004 @ 09:25:
maargoed, ik ga hem toch volgen om de simpelle reden:

- het staat goed op je CV (het is op een campus met 7000 studenten, en de naam van de school is ook wel ok schijnt)

MCSE ook, maar of je er ook echt zelf beter van wordt ..

- Het is een eerste stap voor iets wat meer gaat worden (eerst bachelors dan masters)

Bacheler kun je nooit worden door het leren van c++, laat staan master.

- Het houdt je van de straat

Het lezen van stroustrup doet dat ook, dat boek is misschien iets duurder dan de cursus, maar je hebt er waarschijnlijk meer aan.

- Als iets niet c++ is dan willen een aantal mensen mij alsnog c++ leren.

Als je eenmaal een manier hebt aangeleerd kom je er heel lastig vanaf. Dat is waarschijnlijk ook waar je nu tegenaan loopt waneer je van scripten overstapt naar het 'echte werk' . Zorg gewoon dat je c++ from scratch goed leert, en niet bij voorbaat een dialect

Bovendien kan iets erbij leren kan nooit kwaad.

dat is waar.

[EfBe]

Vampier schreef op 26 januari 2004 @ 23:02:
Ik heb de stap weer gezet om terug te gaan naar school voor een cursus c++, nu heb ik echter het boek eens zitten doorlezen en ben tot de conclusie gekomen dat het c++.net is en geen c++. Nu vroeg ik me af ofdat een probleem kan zijn omdat ik cross platform wil gaan developen.

Dan zou ik het boek snel verruilen voor een puur C++ boek, want C++.NET is veelal managed en dan mis je multiple inheritance, templates en andere goodies. Op zich is C++.NET niet verkeerd, je kunt er managed + non-managed code mee maken, maar voor cross-platform development is het niet nuttig.

[EfBe]

Janoz schreef op 27 januari 2004 @ 09:51:
MCSE ook, maar of je er ook echt zelf beter van wordt ..

Niet om het een of ander, maar moet dat nou, als modje lekker goedkoop mensen met een MCSE diploma afzeiken (want dat is het)? Kun je die mensen niet beter gewoon in hun waarde laten? Iedere boerenlul die nauwelijks het verschil weet tussen een muis en een printer heeft zn bek vol over de crappyness van MCSE (en toegegeven het is slecht geweest) maar dat is al een paar jaar niet meer zo met de MCSE certificering voor windows 2000 (en nu voor 2003).

Als ik iedere dag mensen zou gaan afzeiken vanwege hun gebrek aan kennis, incluis mods, heb ik een dagtaak. Laat iedereen in hun waarde, zeker die arme MCSE'ers, ookal heb je ten dele gelijk mbt de MCSE-ers van voor de win2k certificering.

[curry684]

Alarmnummer schreef op 27 januari 2004 @ 09:39:
[...]

Wat is er mis met een delegate?

Ondanks dat ze vaak 'handig' zijn worden ze in het merendeel van de gevallen enkel gebruikt als shortcut om geen 'hele nieuwe class' te hoeven deriven en functionaliteit van class A op een hele ranzige manier in de compleet ongerelateerde class B te kunnen implementeren.

Ik ben overigens niet principieel tegen delegates (sterker nog, ik gebruik ze zelf ook gefaked in C++) maar ze worden vaker ranzig gebruikt dan correct.

Niet om het een of ander, maar moet dat nou, als modje lekker goedkoop mensen met een MCSE diploma afzeiken (want dat is het)?

psst. hij typte er een smiley achter en zelfs zonder smiley was het allesbehalve een harde of lompe flame hoor

[ Voor 19% gewijzigd door curry684 op 27-01-2004 10:10 ]

[whoami]

Alarmnummer schreef op 27 januari 2004 @ 09:39:
[...]

Wat is er mis met een delegate?

Dat vraag ik me ook af?
In C++ heb je toch ook zoiets als 'functie-pointers' ? Een delegate kan je min of meer als een functie-pointer beschouwen.

[curry684]

whoami schreef op 27 januari 2004 @ 10:10:
[...]


Dat vraag ik me ook af?
In C++ heb je toch ook zoiets als 'functie-pointers' ? Een delegate kan je min of meer als een functie-pointer beschouwen.

Een functiepointer echter is een onschuldig iets uit C-programma's. C-programmatuur is een grote bak met functies waarin het geen probleem is at random een greep uit die functies te doen en die rond te pompen.

C++ programma's bestaan als het goed is uit hermetisch afgescheiden en shielded blokken functionaliteit. Het hele idee achter interfaces en private/protected members is juist dat je de inner workings binnen het object houdt. Vervolgens kun je met delegates echter de helft van de functionaliteit van class Pietje in class Klaas gaan implementeren, wat vloekt met de meest puristische grondbeginselen van OOP.

[whoami]

Dus dan vind jij dit:
[rml]whoami in "[ VB.NET] waardes van een andere form?"[/rml]

een slecht gebruik van de mogelijkheden van delegates? Daar ga je nl. via een delegate waarden vanuit Form1 waarden uit Form2 gaan halen (waarbij de forms dus classes zijn).
Echter, deze 'constructie' laat wel een eerder 'loosely coupled' structuur toe, en zorgt er ook voor dat je de forms makkelijk kunt hergebruiken, aangezien er geen directe binding bestaat tussen die 2 forms.

[curry684]

whoami schreef op 27 januari 2004 @ 10:19:
Dus dan vind jij dit:
[rml]whoami in "[ VB.NET] waardes van een andere form?"[/rml]

een slecht gebruik van de mogelijkheden van delegates? Daar ga je nl. via een delegate waarden vanuit Form1 waarden uit Form2 gaan halen (waarbij de forms dus classes zijn).
Echter, deze 'constructie' laat wel een eerder 'loosely coupled' structuur toe, en zorgt er ook voor dat je de forms makkelijk kunt hergebruiken, aangezien er geen directe binding bestaat tussen die 2 forms.

Ik zeg toch niet dat ik het een lelijk concept vind en dat het niet in C# had mogen zitten? Ik vind de closures in BCB ook geniaal (dat waren delegates 5 jaar voordat C# werd bedacht). Ik zeg alleen dat ze vloeken met de grondbeginselen van OOP en dat ze daarom in 1978 niet in C++ zijn gestopt (en sindsdien nog steeds niet). De constructie waar je naar linkt is namelijk via een omweg ook met een interface te doen, en delegates zijn altijd door een constructie met interfaces te vervangen. Het is echter vaak een enorm rotwerk om het op die manier te doen.

Daarnaast is een geweer niet gevaarlijk omdat je er iemand mee dood kunt schieten: het wordt pas gevaarlijk zodra de verkeerde persoon 'm vast heeft. En voor delegates geldt 100% hetzelfde: je kunt ze miserabel misbruiken, of met wonderlijke schoonheid toepassen.

[EfBe]

curry684 schreef op 27 januari 2004 @ 10:08:
psst. hij typte er een smiley achter en zelfs zonder smiley was het allesbehalve een harde of lompe flame hoor

Ik ben geen internet-n00b, curry Jij ook niet. Je hoeft me geen onzin te verkopen dat je alles kunt zeggen en dan een smiley erachter te zetten zodat het kennelijk niet waar is. De 'grap' is gemaakt, de smiley zegt alleen dat het een grapje is, maar die lui worden al door jan en alleman afgezeken ook in grapjes zoals deze, vaak door de meest DOMME types die je je maar kunt voorstellen. Smiley of niet, een mod zou moeten weten dat het maken van dat soort grapjes anderen kan storen, zeker gezien het feit dat een MCSE2000 gecertificeerde er echt wel hard voor heeft moeten werken om dat diploma te halen maar TELKENS weer tegen vooroordelen moet opboksen, in stand gehouden door o.a. dit soort grapjes. Ik heb zelf ooit NT4-MCSE gedaan en ik weet dat het toen brak was, in mijn klasje van 11 was ik de enige met een HBO-inf diploma en veel ervaring met computers, sommigen wisten niet eens hoe een computer er van binnen uit zag of wat een utp kabel was. Dat soort mensen zijn debet aan het feit dat dat diploma geen fuck meer waard is. (wat mij niet zo boeit, maar anderen wellicht wel) Dat neemt niet weg dat het allang niet meer zo slecht is en de vooroordelen daarom wel eens de wereld uit mogen.

Nu zal het uiteraard zo gaan zoals altijd hier, dat ik ongelijk heb en de modjes het beter weten, het zij zo. Als je als modje niet begrijpt dat smileys erbij proppen het grapje en de wrange vooroordelen niet wegnemen is het m.i. een beetje fout aan het gaan. Ik gaf alleen maar aan dat je je moet realizeren dat in de IT wereld veel vooroordelen bestaan en zonder echte feitenkennis je beter je mond kunt houden dan er grappen over maken. Een ranzige turkenmop mag ook niet, en terecht, ookal pleur je er een smiley achter.

[ Voor 1% gewijzigd door EfBe op 27-01-2004 10:33 . Reden: er stond een komma op een wel hele foute plek ;) ]

[EfBe]

curry684 schreef op 27 januari 2004 @ 10:13:
C++ programma's bestaan als het goed is uit hermetisch afgescheiden en shielded blokken functionaliteit. Het hele idee achter interfaces en private/protected members is juist dat je de inner workings binnen het object houdt. Vervolgens kun je met delegates echter de helft van de functionaliteit van class Pietje in class Klaas gaan implementeren, wat vloekt met de meest puristische grondbeginselen van OOP.

Ik dacht dat het idee achter interfaces juist is dat je een voorafgedefineerd contract hebt waar je tegenaan kunt programmeren, ookal heb je veel meer functionaliteit in je object (interfaces is dan ook een van de 2 vormen van multiple inheritance: multiple type inheritance. )

Een delegate is altijd een pointer naar een public method. Het doet dus geen afbreuk aan OO beginselen, omdat je de pointer inkapselt in een object en laat wijzen naar een method die anders ook toegankelijk is.

Verder lijkt me het noemen van 'puristische grondbeginselen van OOP' in een thread over C++ een beetje vloeken in de welbekende kerk

[Verwijderd]

curry684 schreef op 27 januari 2004 @ 09:37:
Let wel: er is niets mis met managed C++. Enige lulligheid is dat heel managed C++ met de volgende release van VC.net op de schop gaat

Het valt me op dat niemand op dit zeer belangrijke argument ingaat. Volgens mij is dit toch wel een van de belangrijkste argumenten om nu niet voor die managed C++ cursus te gaan.

Ten eerste is managed C++ nog niet zo oud en zeker niet veel in gebruik. Als het dan ook nog eens bekend is dat het zeer binnenkort gaat verdwijnen en door een veel sterker alternatief wordt vervangen (de C++/CLI binding) dan kun je wel bedenken dat je met heel erg nuttelose kennis zit.

(als extra kennis kan het mischien geen kwaad, maar om te beginnen lijkt het me echt niet goed)

Op dit moment kun je beter beginnen met C# (en .NET), standaard C++, Java, of eventueel C.

Overigens is voor elke Informatica Bachelor of Masters kennis van tenminste 1 dezer talen (hang van de uni af, bv Leiden C++, VU Java, enz) echt wel een absolute basisvoorwaarde. De taal kennen voor je aan de opleiding begint is echter niet perse nodig. Er is altijd zoiets als Inleiding Programmeren of Programmeer Methoden oid voor de eerste jaars.

[EfBe]

Verwijderd schreef op 27 januari 2004 @ 12:25:
Het valt me op dat niemand op dit zeer belangrijke argument ingaat. Volgens mij is dit toch wel een van de belangrijkste argumenten om nu niet voor die managed C++ cursus te gaan.

Waarom? Die wijzigingen in de MC++ syntax duren nog een jaar voor ze uit zijn. Tot die tijd kun je dan met MC++ van nu ervaring op doen en dan de wijzigingen in de syntax in jan 2005 (en dan ben je een echte early adopter, dus reken maar op medio 2005) met whidbey meenemen in je werk. Let wel: MC++ van nu compileert nog steeds op whidbey.

Ten eerste is managed C++ nog niet zo oud en zeker niet veel in gebruik. Als het dan ook nog eens bekend is dat het zeer binnenkort gaat verdwijnen en door een veel sterker alternatief wordt vervangen (de C++/CLI binding) dan kun je wel bedenken dat je met heel erg nuttelose kennis zit.

Wat gaat er verdwijnen ZEER binnenkort? .NET 2.0 is nog een jaar weg en MC++ verdwijnt helemaal niet. Ik weet niet wat de C++/CLI binding inhoudt maar als je met die binding de ^-syntaxis bedoelt is het niets meer dan syntactische suiker: de CLI ondersteunt nog steeds geen MI en MC++ ook niet, ook niet in whidbey. Verder is het niet duidelijk in hoeverre templates ala C++ echt worden gesupport in MC++, immers de .NET lib generics werken anders. Ze denken erover om een STL.NET te releasen maar ik zie dat niet gebeuren dat dat met whidbey komt. ALLE zaken die normale C++ ook kan en nu op .NET LIJKEN te kunnen maar stiekum toch nietresulteren in unmanaged code.

Ik vind het nogal kolder om te beweren dat je dan met 'nutteloze' kennis zit, ik denk dat het tegendeel waar is. TS wil overigens cross platform hardcore C++ programmeren dus met MC++ kom je dan niet zo ver.

Overigens is voor elke Informatica Bachelor of Masters kennis van tenminste 1 dezer talen (hang van de uni af, bv Leiden C++, VU Java, enz) echt wel een absolute basisvoorwaarde.

WAT!? sinds wanneer heeft informatica IETS van doen met een programmeertaal? De programmeertaal is een middel om software design/development te onderwijzen, maar geen doel. Het liefst zie ik informatica opleidingen onderwijzen in een taal als Eiffel, zodat ze niet worden afgeleid door marketingpoep of politieke stromingen die beweren dat de taal het doel is en niet een middel.

De taal kennen voor je aan de opleiding begint is echter niet perse nodig. Er is altijd zoiets als Inleiding Programmeren of Programmeer Methoden oid voor de eerste jaars.

Zoals ik al zei, het beste is om programmeren te onderwijzen in een onbekende taal. Dan wordt men gedwongen te kijken naar wat programmeren inhoudt ipv dat men voortborduurt op zelf-aangeleerde truukjes en andere nonsens. HIO-enschede gebruikte terecht Eiffel en niet Java, omdat Eiffel veel beter OO implementeert dan Java ooit zal kunnen en een student veel beter dwingt na te denken over waar hij/zij mee bezig is.

Beweren dat een student / afgestudeerde een van de popi-jopi talen MOET kennen is IMHO een teken dat je niet begrijpt dat informatica niets van doen heeft met het leren van het gebruik van een programmeertaal, maar met de theorie en technologie achter het bouwen van software in het algemeen. Op dit moment heb je voor veel software nog programmeertalen in de vorm van ascii tekst nodig inderdaad, over 20 jaar echt niet meer, de theorie erachter echter blijft exact hetzelfde.

[Verwijderd]

EfBe schreef op 27 januari 2004 @ 12:42:
[...]

Waarom? Die wijzigingen in de MC++ syntax duren nog een jaar voor ze uit zijn. Tot die tijd kun je dan met MC++ van nu ervaring op doen

Van elke kennis die je opdoet weet je dat het zal verouderen. Inzichten in principes zijn natuurlijk wat meer houdbaar dan daadwerkelijke hands-on kennis. Van de huidige managed C++ variant is door het VC team naar buiten gebracht dat het een verkeerde beslissing was. (zie oa http://blogs.gotdotnet.com/hsutter/ en news: comp.lang.c++.moderated Ecma International Moves to Standardize C++ Binding ...).

Als het je alleen gaat om de principes van iteratief en OO programmeren dan is het huidige managed C++ niet zo slecht, maar de feitelijke hands-on kennis (zie het als een bij produkt van die cursus) is op z'n minst van een nogal twijfelachtige waarde.

Daarentegen bieden C#, C++ en Java identiekte inzichten, met als "gratiz" voordeel dat de feitelijke hands-on ervaring bewezen nuttig is. En natuurlijk moet het niet al te veel overtrokken worden. -zo'n- ramp is het nu ook weer niet allemaal. Laten we het dan iets nuanceren en zeggen dat managed C++ op dit moment 'een beetje dom' is en niet heel erg dom.

Verder is het niet duidelijk in hoeverre templates ala C++ echt worden gesupport in MC++, immers de .NET lib generics werken anders. Ze denken erover om een STL.NET te releasen maar ik zie dat niet gebeuren dat dat met whidbey komt.

Korte samenvatting van Herb over de targets voor de komende MSVC compiler:

* Pure native: Compile existing programs to native binaries just like we've all been doing for years. No CLI features, no CLI extensions.

* Normal C++ programs that happen to be compiled to IL instead of to x86: The code runs on the VM and is JITted and everything, but the program is still using all native data and not using any CLI data types, so no CLI extensions are needed here either.

* C++ programs that explicitly start using some CLI data types or features: At those points in the code where those data types or features are used, and only at those points, the extensions will apply, and most of the time the only new syntax will be to write gcnew and ^ (instead of new and *).

Met 'normal c++' wordt dan ook echt normal bedoelt. Zowel templates als multiple inheritance kunnen naar de CLI gecompiled worden, alsmede alle andere standaard C++. Natuurlijk compileert STL dan naar CLI, maar ook belangrijke andere libraries als bv boost of loki. Standard conformance is vandaag de dag het issue voor het VC team. Van een aparte STL.NET heb ik nooit gehoord. Ik denk dat dat een project is van voor de ECMA CLI/C++ binding.

TS wil overigens cross platform hardcore C++ programmeren dus met MC++ kom je dan niet zo ver.

Of juist wel. Sinds de CLI binding een ECMA standaard is, en dus mogelijk ook een ISO standaard wordt, zal dat er mogelijk voor zorgen dat de CLI een defacto VM en GB implementatie voor C++ wordt. (De CLI, inclusief de C++ binding kan voor elk platform geimplementeerd worden, zie oa het Mono project. Let wel, dit is in principe zonder de .NET libraries zelf).

WAT!? sinds wanneer heeft informatica IETS van doen met een programmeertaal?

Sinds het feit dat je op de Universiteit practica doet. Aangezien je niet van de nakijker/proffessor kan eisen dat ie 10.000 talen kent wordt meestal een bepaalde taal en omgeving verplicht gesteld. Tevens, als je voor elk practica een compleet andere taal zou moeten gebruiken, dan ben je meer met die taal bezig dan met het feitelijke onderwerp van de opdracht.

Bv, in Leiden krijgen de eerste jaars C++. In het 2de semester moest je dan een MIPS emulator in C schrijven. Alleen al die overgang zorgde nog al voor wat protest, omdat de studenten dan on-the-fly nog even de C eigenaardigheden erbij moesten leren, terwijl het eigenlijk om de CPU architectuur ging. Volgens jou moeten ze dan nog maar eventjes eerst Eifel gaan leren en dan in de laatste week voor de deadline de hele emulator schrijven ofzo?

De programmeertaal is een middel om software design/development te onderwijzen, maar geen doel.

Precies, maar de taal moet niet afleiden van het werkelijke doel. Als je telkens bezig moet zijn om andere talen te leren kom je niet aan het echte werk toe. Daarom is het noodzakelijk om, zoals ik al eerder zij, afhankelijk van de universiteit C++, C# of Java te kennen, daar de meeste practica die taal voorschrijven.

Maar eigenlijk was mijn hele opmerking andersom bedoelt: Namelijk dat je zonder kennis van 1 van die programmeertalen gewoon de opleiding niet doorkomt. Je hebt het gewoon in bijna elke vak met een practica nodig. Daarmee is het een middel wat je relatief gezien het vaakst gebruikt.

In Leiden heb je bv ook een vak dat Concepten van Programmeertalen heet. Daar krijg je oa Prolog, Lisp/scheme of clean (verschilt per jaar) en Java. De kennismaking met de logische en functionele talen is heel interesant, maar het komt meestal niet terug bij een vervolg vak. Als je naar bv andere vakken kijkt als Lineaire Algebra, dan zie je dat deze kennis ook niet heel veel te gebruiken is bij andere vakken, alleen als je je specificiek in geometrisch modelleren gaat specialiseren komt het weer terug.

Dit zijn maar voorbeelden. Het hele punt is dat C++ enz de kennis is die in de meeste vervolg vakken nodig is. Punt.

Het liefst zie ik informatica opleidingen onderwijzen in een taal als Eiffel, zodat ze niet worden afgeleid door marketingpoep of politieke stromingen die beweren dat de taal het doel is en niet een middel.

Ja! Laten we dat doen! Lekker makkelijk om samen te werken met mensen van andere universiteiten dan Lekker makkelijk om references op te zoeken en om code te delen met elkaar. Leuk voor vakken als Operating Systems waar studenten een stuk van een OS kernel moeten implementeren (bv Minix, Linux, of OSP). Ook zeer veel beter voor vakken als Compiler Construction. Bv Bison en Flex werken toch nog altijd het makkelijkst met Eiffel. En dan meteen alle commentaar in het Nederlands he? Want dat leest toch veel makkelijker?

omdat Eiffel veel beter OO implementeert dan Java ooit zal kunnen en een student veel beter dwingt na te denken over waar hij/zij mee bezig is.

Hoewel de taal zeker in zeer belangrijke mate bepaald hoe je gedachten gevormt worden, is het toch ook zeer zeker de student zelf die zich tot een zekere mate van zelf bewustzijn moet dwingen. Het beseffen wat je nou eigenlijk aan het doen bent, en daarmee het jezelf aanleren van principes en algemene methodes moet gewoon ook in je zitten. Wellicht dat HBO studenten dat van nature minder in zich hebben en daarom iets meer gedwongen moet worden. Dat de HIO Enschede daarom Eiffel verplicht stelt is in dat licht gezien mischien nog niet eens zo'n slecht idee.

Beweren dat een student / afgestudeerde een van de popi-jopi talen MOET kennen is IMHO een teken dat je niet begrijpt dat informatica niets van doen heeft met het leren van het gebruik van een programmeertaal, maar met de theorie en technologie achter het bouwen van software in het algemeen.

Sure. Informatica is ook geen programmeurs opleiding an sich. Maar nogmaals, je hebt de kennis van die ene taal nou eenmaal nodig om practica te doen en voorbeelden in boeken te lezen. Toevallig is die ene taal meestal C/C++ of Java. Beiden verschillen echter kwa syntax zo weinig dat het wel te doen is om deze iet wat te mixen, zeker voor hogere jaars vakken. In Leiden had je bv het vak Interfaces dat 'opeens' in Java was. Met 2~3 jaar C++ kennis is dat wel te doen. Als het opeens in Eiffel was geweest dan geldt het zelfde verhaal als met bovenstaande emulator, zelfs voor 3de jaars.

Op dit moment heb je voor veel software nog programmeertalen in de vorm van ascii tekst nodig inderdaad, over 20 jaar echt niet meer, de theorie erachter echter blijft exact hetzelfde.

Kewl. Jij kan 20 jaar in de toekomst kijken! Hoewel ik ook verwacht dat de theorie ongeveer hetzelfde zal blijven hoeft dat natuurlijk niet. Ook zal over 20 jaar best nog ascii text nodig zijn. Overigens kun je nu toch ook al unicode gebruiken in je source? Chinese studenten hadden bv gewoon chinese comments in hun C++ en Java source code staan.

Ik heb zelf btw gewerkt aan het ontwerp en implementatie van een recursieve data-flow based taal. Deze is op XML gebasseerd en er kan in principe geheel grafisch geprogrammeerd mee worden (door oa aan elkaar clicken van blokjes). Maar dat is natuurlijk weer een heel ander verhaal.

[EfBe]

Verwijderd schreef op 27 januari 2004 @ 14:04:
Korte samenvatting van Herb over de targets voor de komende MSVC compiler:

* Pure native: Compile existing programs to native binaries just like we've all been doing for years. No CLI features, no CLI extensions.

* Normal C++ programs that happen to be compiled to IL instead of to x86: The code runs on the VM and is JITted and everything, but the program is still using all native data and not using any CLI data types, so no CLI extensions are needed here either.

* C++ programs that explicitly start using some CLI data types or features: At those points in the code where those data types or features are used, and only at those points, the extensions will apply, and most of the time the only new syntax will be to write gcnew and ^ (instead of new and *).

Met 'normal c++' wordt dan ook echt normal bedoelt. Zowel templates als multiple inheritance kunnen naar de CLI gecompiled worden, alsmede alle andere standaard C++.

Waar staat dat MI naar CLI gecompileerd wordt? Lippman beweert toch echt het tegenovergestelde. (en terecht, de CLI ondersteunt geen MI. Je kunt uiteraard in theorie wel MI compileren naar CLI, maar dan heb je helperclasses nodig (zie Eiffel.NET) en dan verlies je interop mogelijkheden met bv C#.

Natuurlijk compileert STL dan naar CLI, maar ook belangrijke andere libraries als bv boost of loki. Standard conformance is vandaag de dag het issue voor het VC team. Van een aparte STL.NET heb ik nooit gehoord. Ik denk dat dat een project is van voor de ECMA CLI/C++ binding.

Nee, Lippman had het daarover op zn blog toen hij mijn MI inzichten aan het neersabelen was met zn botte voorhamer . (http://weblogs.asp.net/slippman ). Ik geloof direct dat standard conformance een hot issue is, maar zonder MI in de CLR heb je een probleem daarmee. Als ik Lippman mag geloven vindt hij interface based programming (dus niet multiple implementation inheritance) vele malen beter dan de rauwe MI zoals C++ dat ondersteunt en heeft dan ook geen problemen met de absentie van MI in MC++.

Dat rijmt dan compleet niet met jouw verhaal dat C++ met MI constructies gewoon naar IL compileert.

[pkouwer]

om even in te haken op de topicstart zonder hier een nieuw topic voor te openen:

Ik kan goed overweg met VB(6) en wil eigenlijk overstappen naar VB.Net. Nu ontbreekt het mij aan een bepaalde hoeveelheid vrije tijd zodat het echt volgen van een cursus/training niet voor mij is weggelegd. Mijn plan is om een goed, en dan bedoel ik goed,boek te kopen, en stapsgewijs dit volgen. Daarnaast wil ik eigenlijk mijn huidige projecten (VB6) omtoveren in VB.Net.

Wat is jullie mening van deze werkwijze/strategie ?

[whoami]

pkouwer schreef op 27 januari 2004 @ 19:31:
om even in te haken op de topicstart zonder hier een nieuw topic voor te openen:

Ik kan goed overweg met VB(6) en wil eigenlijk overstappen naar VB.Net. Nu ontbreekt het mij aan een bepaalde hoeveelheid vrije tijd zodat het echt volgen van een cursus/training niet voor mij is weggelegd. Mijn plan is om een goed, en dan bedoel ik goed,boek te kopen, en stapsgewijs dit volgen. Daarnaast wil ik eigenlijk mijn huidige projecten (VB6) omtoveren in VB.Net.

Wat is jullie mening van deze werkwijze/strategie ?

Ik wil niet lullig doen ofzo, maar dit topic gaat eigenlijk over C++ / C++.NET. Als we nu over VB.NET zouden beginnen, zo dit topic nogal onoverzichtelijk worden.
Ik weet niet zozeer een goed boek voor VB.NET (wel voor C#).
VB6 code naar VB.NET 'omtoveren' zal imo niet zo in 1 2 3 gaan, aangezien de taal eigenlijk compleet anders is. 't Enige wat vertrouwd zal overkomen, zal de syntax zijn. (Niet dat ik je wil ontmoedigen ofzo hoor. )
Maar goed, we blijven hier beter on-topic.

[pkouwer]

ik zou nog wel even willen reageren, maar laten we op verzoek maar even on-topic blijven. Ik open tzt wel een nieuwe.

[Vampier]

Even een klein detail vergeten: Ik woon in California (Anaheim) ik heb nog geen studie ervaring in Amerika iets wat erg belangrijk is op je CV schijnt.

Hier is wat ik doe:

Ik ga de cursus volgen, ik rond hem af met een zo goed mogelijk resultaat. Dit zet ik op mijn CV en hoop dat iemand me dan wel een kans geeft op werk. Voor die $75 blijf ik niet thuis zitten.

Ik heb wel veel aan dit topic gehad en gezien dat ik me niet teveel aan de 'syntax' moet hechten. Maar gewoon het boek moet kopen van Bjarne Stroustrup als ik met deze opleiding klaar ben en het opnieuw moet gaan proberen.

Bedankt voor jullie inbreng

[Vampier]

zow op amazon.com even het boek van Bjarne besteld ($34.95) zodat ik niet te ver afdwaal)