Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 66 reacties
Bron: Microsoft Watch

In juni hebben Microsoft Watch en eWeek gesproken met Anders Hejlsberg, de ontwikkelaar van de Borland Turbo Pascal-compiler en de chief architect van Borlands Delphi. Sinds 1996 werkt hij voor Microsoft en daar heeft hij de programmeertaal C# ontwikkeld. Hejlsberg bevestigt dat Visual Studio, SQL Server en BizTalk Server steeds nauwer geïntegreerd zullen worden. Deze integratie is nodig omdat softwareontwikkelaars in hun programma's deze wederzijdse afhankelijkheid inbouwen en om dat ontwikkelproces te vereenvoudigen, kan integratie handig zijn. Hoe dit er precies gaat uitzien, is nog niet bekend, maar een voorproefje zal in de aanstaande release van Visual Studio 2005 'Whidbey' beschikbaar zijn.

Vervolgens vertelt Hejlsberg dat C# 2.0 features zal bevatten die lijken op functionaliteit uit dynamische programmeertalen, zoals Ruby en Python. Softwareontwikkelaars die gebruikmaken van dat soort talen vinden dat positief omdat het relatief kortere code oplevert die ook nog eens snel geschreven kan worden. Dat heeft echter als nadeel dat er niet automatisch 'type checking' plaatsvindt. In C# 2.0 zullen features aanwezig zijn die het mogelijk maken om zowel relatief korte code te produceren als 'strong type checking' uit te voeren. Dit zal onder meer zichtbaar worden in het feit dat C# 2.0 een datatype zal afleiden van de manier waarop het door de softwareontwikkelaar gebruikt wordt.

Om dit soort zaken mogelijk te maken, zal geen compleet nieuwe programmeertaal ontwikkeld worden. Hejlsberg verwacht dat het ontwikkelen van een nieuwe taal meer problemen oplevert, dan het zou moeten oplossen. Vervolgens gaat Hejlsberg over naar het onderwerp C# 3.0. Deze programmeertaal zal nog meer mogelijkheden bevatten op het gebied van data-integratie. Dit zal, in tegenstelling tot bijvoorbeeld FoxPro, niet alleen gaan om databasedata, maar om allerlei soorten data, zoals XML en grafiekdata. Dit is gedeeltelijk al mogelijk met het genoemde FoxPro, maar die taal staat op zichzelf en kan dus geen gebruikmaken van de voordelen van het .NET-platform.

Moderatie-faq Wijzig weergave

Reacties (66)

In C# 2.0 zullen features aanwezig zijn die het mogelijk maken om zowel relatief korte code te produceren als 'strong type checking' uit te voeren. Dit zal onder meer zichtbaar worden in het feit dat C# 2.0 een datatype zal afleiden van de manier waarop het door de softwareontwikkelaar gebruikt wordt.
OcaML anyone?
En hoe zit het met de plek van F# in al deze ontwikkelingen?
Waarschijnlijk gaat het erom dat (veel) meer mensen met Python (en allicht ook Ruby) werken dan OcaML.
OcaML wordt vooral door universiteiten gebruikt, terwijl python veel meer in alledaagse situaties gebruikt schijnt te worden.
Verder lijkt mij het van oorsprong functionele ontwerp van OcaML het ook net iets te ingewikkeld om C# op te baseren.
Ook nog eens heeft python geen 'copyleft', en is speciaal ook bedoeld voor commerciele toepassingen (ook doorverkoop) wat het geschikter maakt voor gebruik door MS, terwijl de ocaml compilers en tools onder QPL vallen, hoewel een groot deel weer onder LGPL valt, maar MS houdt en niet van QPL lijkt me, en zeker niet van LGPL.
[flamebait ofzo]
Wat hebben de licentievormen van Python OcaML en whateverprogrammeertaal hier in godsnaam mee te maken? C# kan toch gewoon features gaan bevatten die _lijken_ op features van andere programmeertalen. C# is nu toch ook niet onder een of andere Sun licence omdat het veel op Java lijkt?? Ik snap je hele post gewoon niet.... Behalve het stukkie dan dat F# en OcaML functionele talen zijn en C# imperatief. Ik denk wel dat ze het onderzoek naar / met F# zeker hebben gebruikt voor de ontwikkeling van C#.
[/flamebait]

Ik ben trouwens niet zeker of dit nou een goede ontwikkeling is van C#. Hierdoor wordt het weer mogelijk om slordige ongetypeerde code te schrijven. Het is fijn dat het kan op momenten dat het echt handiger zou zijn, maar gezien MS's devloper base, dat toch voornamelijk uit ex-VB/ASP-ers bestaat (en een handjevol C++ programmeurs, maar die programmeren nog steeds C++), lijkt mij dat het weer gewoon good old ik-programmeer-slordig-maar-het-werkt-wel wordt.

Beter is de aanpak van Java (versie 6, en nu al met Jakarta Bean Scripting Framework) om allerlei interfaces tussen scripttalen en java te maken. Je houdt je java taal (en dus code) zuiver, maar je geeft toch de mogelijkheden die het publiek (blijkbaar) vraagt. Ik heb er overigens weinig behoefte aan, maar dat is mijn mening.
Ik bedoelde, als MS het leuk vindt kunnen ze zo delen uit de pythoncode overnemen (en waarom niet?). Net zoals ze bij het programma FTP hebben gedaan van BSD (als je het FTP progje met een editor bekijkt, zie je nog copyright van Berkeley).
Als S Ballmer zegt dat GPL een kanker is (en dat HEEFT hij gezegd) zou MS zich er ver vandaan moeten houden, en anders moet dhr Ballmer gewoon z'n b*k houden.
Edit: Om het wat duidelijker te maken, het probleem is inderdaad meer filosofisch dan praktisch, MS heeft hard geroepen dat GPL innovatie remt, dus features uit GPL software namaken, zou toegeven zijn dat deze innovatiever is dan de hunne, wat een zwaktebod zou zijn.
C# kent ook interfaces en samen met delegates en boxed classes kun je prima stronged typed programeren hoor. En raar is dat je er weinig behoefte aan hebt, want een echte ooper in .NET kan niet zonder :z
C# wordt helemaal niet ongetypeerd. C# gaat de kant op van Cω (C-omega), een uitbreiding van C# waaraan in de Microsoft Research Labs aan gewerkt wordt. Het artikel is een beetje vreemd geschreven, maar je hoeft nergens bang voor te zijn, C# blijft strong-typed, omdat dat inherent is aan .NET.

Zie ook: http://research.microsoft.com/comega/
Ik ben echt te spreken over C# 2.0. Van de nieuwe features vind ik de Generics toch wel de geweldigste. Dit scheelt in de praktijk echt veel code die je nodig hebt om die vervelende wrapper classes te maken en het zorgt ervoor dat je objecten niet meer ge-typecast hoeven te worden, wat performance winst oplevert.

Hier een linkje:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs0 5/html/csharp_generics.asp

@curry684 && @hla:
Jullie hebben helemaal gelijk.
@DeKaluh: generics zijn toch de C# versie van templates in C++?
Niet helemaal, generics zijn essentieel anders dan templates. Voor de leek lijkt het in eerste instantie hetzelfde, maar je kunt met beide systemen hele andere dingen doen. Het grootste verschil is dat templates in C++ zorgen voor aparte compilatie van elke template instance, waardoor dingen als specialization mogelijk zijn (dit is tevens de grote kracht van C++, imho). Met generics in C# (en Java for that matter) wordt er maar één versie van je class gecompileerd, en de compiler zorgt voor de nodige casts bij het interfacen ermee.

Overigens kun je met templates ook generics simuleren.
Dat is niet geheel waar. De compiler compileert de generic naar generic MSIL code. De JIT compiler creert on the fly wel degelijk verschillende instanties van die klasse als het programma gedraaid wordt. Voordeel is dus minder grote executables (tot op zekere hoogte).

Voordeel van C# generics is dat er type checking kan plaatsvinden (door aan te geven welke interfaces het doorgegeven type MOET ondersteunen). Dit geeft simpelere foutmeldingen bij het compileren dan C++ templates.

Echter, met templates in C++ zijn veel meer dingen mogelijk die veel mensen niet inzien totdat ze ermee in aanraking komen.
De JIT compiler creert on the fly wel degelijk verschillende instanties van die klasse als het programma gedraaid wordt
Nou heb ik niet helemaal verstand van het compilatieproces in .Net, maar waarom in hemelsnaam? De code blijft hetzelfde, een MyGenericClass<MyObject> werkt intern gewoon als een MyGenericClass<object>. Het handige is dat er geen cast meer plaats hoeft te vinden als een functie een generic type teruggeeft, maar verschillende instanties van de generic class voor verschillende typen is niet nodig, je weet namelijk dat je minstens een object hebt, en meer kun je in de implementatie van de generic ook niet doen dan doen alsof het een object is.

En die casts die wel gegenereerd kunnen worden kunnen ook best @ compiletime op het moment dat je interfacet met een specifieke generic implementatie.
Nou heb ik niet helemaal verstand van het compilatieproces in .Net, maar waarom in hemelsnaam? De code blijft hetzelfde, een MyGenericClass<MyObject> werkt intern gewoon als een MyGenericClass<object>.
Nee. Als MyObject een method Foo heeft dan kun jij in je generic class een where definieren die bv zegt dat het ingevoerde type minimaal een interface X of een base class Y moet hebben. Dan kun jij in je generic class T.Foo() aanroepen. 'object' heeft dat niet.

Het voordeel daarvan is dan dus dat je at runtime niet meer hoeft te casten maar direct T.Foo() kunt aanroepen, in je typed instance. Je rolt je types dus niet uit at compile time maar at runtime, omdat je de JIT hebt die dat voor je kan doen.
Het handige is dat er geen cast meer plaats hoeft te vinden als een functie een generic type teruggeeft, maar verschillende instanties van de generic class voor verschillende typen is niet nodig, je weet namelijk dat je minstens een object hebt, en meer kun je in de implementatie van de generic ook niet doen dan doen alsof het een object is.
Tuurlijk wel, daarom heb je juist restricties op de generic definition :)
Ik ben echt te spreken over C# 2.0.
Je zou hier ook kunnen zeggen:
'Ik ben echt te spreken over VS2005.'

Ook in de nieuwe versie van VB zijn Generics beschikbaar:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcv s04/html/vs04k1.asp

@curry684:
Inderdaad. Het gaat om een feature van het framework. Thanks voor de verbetering van de verbetering. :)
Je zou hier ook kunnen zeggen:
'Ik ben echt te spreken over VS2005.'
Als je dan verbetert, verbeter dan goed :) Hij bedoelt te zeggen dat ie blij is met .NET 2.0, generics zijn namelijk een feature van het framework (met name de CLR+IL). VS.NET 2005 is enkel de 'native' ontwikkelomgeving voor .NET 2.0, maar je kan zelfs in Notepad code C#, VB.NET of MC++ code schrijven die .NET 2.0 features zoals generics gebruikt.
wat is dat C# nou? Is het een samenvoeging van C++ en C, of is het iets op zichzelf staands? En wat zijn de voordelen ervan?

Buiten dat, de beter intergratie is wel prettig, dat vergemakkelijkt eht programmeren weer.
C++ is een 'uitbreiding' op C.
C# is een 'uitbreiding' op C++.

De # moet 4 plusjes voorstellen...

/--- ++
\--- ++

Ascii-art :D
Al kan je sommige krachtige features van C++ byebye zeggen als je geen gebruik maakt van 3rd party componenten (zoals bijvoorbeeld directe hardware I/O en inline assembly).

In mijn ogen is C# echt niet beter dan C++. Als ik een performance crunching app moet maken, doe ik dat nog altijd liever in C++.

Ik maak meer gebruik van C# bij webontwikkeling en RAD (waarvoor het ook eigenlijk bedoeld is) als ik bijvoorbeeld snel een database gekoppelde applicatie moet maken die niet al te complexe taken moet verrichten, mbt. tot wiskunde en dergelijke.
Leuk bedacht, nu het goede antwoord:
Q. What is the symbol in the name "C#"?

A. It's not the "hash" (or pound) symbol as most people believe. It's actually supposed to be the musical sharp symbol. However, because the sharp symbol is not present on the standard keyboard, it's easier to type the hash ("#") symbol. The name of the language is, of course, pronounced "see sharp".
Bron: http://msdn.microsoft.com/vcsharp/productinfo/faq/default.aspx (helemaal onderaan)
C# is een compleet "nieuwe" taal, die verdacht veel op java gelijkt.
Het heeft meer weg van C-varianten dan van Java, vandaar ook de naam C#.
Heb ik hier wat nieuws geleerd... ik noemde # hash!?
Het # symbool heeft verschillende namen, hash of pound zijn er twee. Officieel is het # symbool in C♯ niet het Hash symbool, maar het Sharp symbool. Zie ook: http://en.wikipedia.org/wiki/Number_sign en http://en.wikipedia.org/wiki/Sharp
Hoe spreek je dat nou uit dan C#? :?

Edit: Dus het kan staan voor de scherpe variant van C, of een programmeertaal met een scherpe visie op de toekomst.
Je spreekt C# als C-Sharp uit. Dat dacht ik tenminste...
Sie sjarp
C sharp
Zie een aantal posts boven je reactie


Spuit 11 :+
See-sharp... ;) (fonetisch dan)

@Dekaluh:
Een paar collega's van mij die op de SDN waren geweest waren ook erg over de Generics te spreken, ik moet er zelf nog mee gaan stoeien, zie het met plezier tegemoet...! :+
Heb ik hier wat nieuws geleerd... ik noemde # hash!?
In een notedop:
C# of Csharp is een hele handige programmeertaal.
Sterker dan c of C++ mits je het dotNetFramework maar op je pc installeert
wil dit dan ook zeggen dat C# niet werkt op linux, Mac OS, ...??

wel al gehoord van C#, maar er nooit echt mee gewerkt of ...
"Sterker" is subjectief.

C# is een combinatie van C++ en Java voor het .NET platform.

Waarbij vooral de wat meer specialistische functionaliteit uit C++ zoals generics is weggelaten en een paar nuttige dingen uit Java zijn geleend.

Ik verbaas me trouwens wel over al die integratie bij MS, de rest van de IT wereld beweegt juist in de tegenovergestelde richting door alles modulair te maken. Soort monopoly-gok van MS?
Het enige wat uit Java is geleend is Garbage Collection, voor zover ik weet, en C# heeft al wel degelijk generics.
Sterker dan c of C++
Die vergelijking kun je simpelweg niet maken. C# is ontworpen om veilige code te produceren dat draait onder een virtual machine, C++ is ontworpen voor performance. Daarnaast heb je overigens ook C++/CLI, de opvolger van "managed C++", waarin het mogelijk is om .Net code te schrijven en dat eveneens te laten interfacen met native code. De nieuwe C++/CLI kan alles wat C# kan, maar andersom niet, dus ook wat dat betreft klopt het sterker zijn van C# niet ;)
En op welke manier zou C# sterker zijn dan C++? Ik heb met beide ervaring, en als we even de .NET library buiten beschouwing laten, dan heb ik in C++ veel meer flexibiliteit met betere performance dan andersom. En voor een groot gedeelte van wat de .NET library kan zijn open-source alternatieven in C++ die zonder problemen in commerciele producten gebruikt kunnen worden. Plus het grote voordeel van die C++ libraries, ze zijn wel degelijk cross-platform compatible, iets wat van .NET (ondanks de Mono tegenhanger) niet geheel gezegd kan worden.
Microsoft's "Embrace and Extend". C++ maar dan "beter". Zoals gewoonlijk.
Juist geen "Embrace & Extend" in dit geval. Dat zou het geval zijn geweest als ze op C++ of op Java door hadden geborduurd.
Hij is tevens één van de belangrijkste personen bij Microsoft achter J++, WFC en het .NET Framework.

Filmpje -- http://channel9.msdn.com/showpost.aspx?postid=10116

@RetepV, dat was mijn eerste gedachte ook, echter de J++ taal zelf, zit goed in elkaar, en dat is dus meer aan hem te danken. De uiteindelijke implementatie is vaak een heel ander verhaal, waar soms marketing en back-wards compatibility een grotere rol spelen, die het gehele security model bij opzet ongedaan kunnen maken.
Hmm, dat is dan weer negatief, dat hij achter J++ zit. Dat kenmerkt deze Anders Hejlsberg als iemand die de veiligheid van computers ondergeschikt vindt aan de mogelijkheden van het platform dat gecreeerd wordt. En door dat soort mensen moeten wij allemaal firewalls, virusscanners, adware scanners, rootkit scanners en spyware scanners draaien.

Voor mensen die niet weten wat ik bedoel: J++ was een uitbreiding op Java, waardoor vanuit Java kernel functies van Windows aangeroepen konden worden. Daardoor werd het concept van Java als een veilige 'sandbox' weer teniet gedaan. En dat terwijl die sandbox juist één van de basisfeatures van Java was. Bedoeld om op een veilige manier code uit te kunnen voeren op een client (als tegenhanger van ActiveX code uitvoeren in IE, wat nog vele malen onveiliger is dan J++).
Je moet natuurlijk wel beseffen dat in de tijd dat Active X en J++ ontwikkeld werden de veiligheidsproblemen lang niet zo groot waren als nu. Daarnaast is het een kwestie van de juiste tool voor de juiste taak gebruiken. ActiveX is nog steeds één van de beste manieren om hoogwaardige intranet applicaties te schrijven.

Ook J++ had daarvoor een zeer zinvolle uitbreiding kunnen zijn.
Dit zal onder meer zichtbaar worden in het feit dat C# 2.0 een datatype zal afleiden van de manier waarop het door de softwareontwikkelaar gebruikt wordt.
Dus de compiler gaat zelf beslissen welk type een variable is? Dit lijkt me nu niet echt een goed idee, voor zowel preformantie als voor foutdetectie...
1/ Als je nu een variable numeriek definieerd als bijvoorbeel een integer, en je wil er gedurende je programma een string in steken, dan krijg je nu een foutmelding. In de nieuwe 'strategie' wordt die variable dan ineens type string???
2/ Mij lijkt het dan ook meer dat met dit principe alle variablen van het "type" variant worden, in plaats van een bepaald type. Hiervoor wordt er dus per variable vele malen meer geheugen gealloceerd dan in 99% van de gevallen nodig is als je ze normaal zou definiëren. Dus qua performance....
Ik denk eerder dat het afleiden pas gfebeurt als een variable niet gedeclareerd wordt, of zelfs in plaats van een variant.
Dat zou juist een flinke besparing van de recourses opleveren, behalve dan at compiletime... :>
Ik denk dat het nog steeds strongly-typed blijft.
python voorbeeldje(runtime error):

a = 123
a = a + 'abc'
Traceback (most recent call last):
File "<pyshell#1>", line 1, in -toplevel-
a = a + 'abc'
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Het gaat om het strong type checking. Ik lees niet dat de variabelen niet meer hoeven gedeclareerd te worden of dat je plotseling een float bij een string kan gaan optellen. Wel zal de verkorte syntax een soort van built-in strongtype checking krijgen.
Hoe ik het lees is het idee dat juist de gebruiker dit gedrag zelf kan definieren, dus de gebruiker kan er (op de een of andere manier) voor kiezen om wel of geen strong-type te gebruiken. Hij kan er dus eigenlijk zelf voor kiezen om in 'Python' stijl of meer 'C' stijl te programmeren, wat MS graag wil lijkt me, omdat nou eenmaal alle devels andere voorkeuren hebben, en als deze allemaal met de MS taal C# kunnen/gaan werken, hebben ze het meeste kans op groot succes.
Het gaat hier niet om javascript hoor :/

Voor verdere uitleg.. zie de post van DaKaluh
Hopelijk maakt deze geweldige uitspraak een einde aan een hoop geruzie:
You can see that in the religious wars over whether it should be VB (Visual Basic) or C# — which, effectively, comes down to what syntax do you prefer?
Jaja, maar ik ontwikkel wel eens in VB.NET, maar probeer een C# programmeur maar eens aan zijn verstand te krijgen dat het enige verschil de syntax is :+.

C# programmeurs zijn doorgaans de wat jongere en/of minder ervaren programmeurs. Die zijn nog blij met hun verworvenheden en denken dat ze alles weten.

Prima, maar als je denkt in 'beter' en 'slechter', dan heb je toch echt je blik afgesloten voor een deel van de mogelijheden die er zijn. Dan leer je dus niks meer bij. Ook prima, maar de computerwereld vernieuwd zich elke 5 jaar, en als je niks meer bijleert, dan loop je op een gegeven moment vanzelf achter.
Het verschil zit in meer dan de syntax. Momenteel kan C# gewoon meer dan VB.NET (of welke andere .NET-taal for that matter), omdat C# voor MS dé .NET-taal is. En ja, VB.NET ondersteund ondertussen ook generics en partial classes, maar dat is voor de C#-ers die een beetje bijblijven al oude koek. Dingen als nullable types, anonymous methods, delegate deferring etc zie je nog niet snel terug in VB.NET.
En ja, VB.NET ondersteund ondertussen ook generics en partial classes, maar dat is voor de C#-ers die een beetje bijblijven al oude koek.
Je vergeet voor het gemak dat Generics in C# ook 'pas' in .NET 2.0 zitten, en dat is tegelijk met Generics in VB :P? Ouwe koek valt dus nog wel mee, want het is de fabriek nog niet uit...
Naar mijn weten ondersteund VB.NET pas generics sinds Beta 2 van Visual Studio 2005. C# ondersteunde al die features al sinds Beta 1, dus wat dat betreft is het wél oude koek.
Jaja, maar ik ontwikkel wel eens in C#, maar probeer een VB.NET programmeur maar eens aan zijn verstand te krijgen dat het enige verschil de syntax is .

VB.NET programmeurs zijn doorgaans de wat jongere en/of minder ervaren programmeurs. Die zijn nog blij met de BASIC-achtige syntax en een beetje schuw voor wat betreft C#'s java/c++-achtige notatie.

Mijn ervaring is dat de notatie die je prefereert afhankelijk is waar je vandaan komt. Ik ben C++ programmeur, en vind 'dus' C# een prettige taal om in te werken. De meeste ASP en 'kantoor' (vbscript, office macro's enzo) programmeurs kiezen daarentegen weer voor VB.NET, omdat dat een voor hun makkelijkere schrijfwijze is.
C# programmeurs zijn doorgaans de wat jongere en/of minder ervaren programmeurs. Die zijn nog blij met hun verworvenheden en denken dat ze alles weten.
Kom maar op met de bewijsvoering voor je claim, want ik denk dat het juist andersom is.

FB, C# MVP
Ik vraag me nog steeds af, wat er nou straks met Visual Basic gaat gebeuren. Volgens mij verdwijnt dat allemaal gewoon en moet je gaan programmeren in die .NET-talen die heel anders zijn dan Visual Basic. ;(
Iemand enig idee?
Gelukkig wel ja...

Hoewel VB een makkelijke taal is om snel wat in elkaar te hacken is het ook traag, resource onvriendelijk en absoluut ongeschikt om een echt grote applicatie in te bouwen.

VB.NET (en de andere .NET talen, wat in essentie gewoon verschillende notaties zijn om dezelfde virtual machine aan te sturen) heeft bijna dezelfde syntax, maar is eindeloos veel robuuster en presteert een stuk beter (niet in de laatste plaats door het betere onderliggende framework). Wat je als VB'er dan wel moet leren is het denken in objecten, maar als je eenmaal die manier van het organiseren van je code goed beheerst wil je waarschijnlijk nooit meer terug...
VB.NET (en de andere .NET talen, wat in essentie gewoon verschillende notaties zijn om dezelfde virtual machine aan te sturen) heeft bijna dezelfde syntax
Inderdaad, het verschil zit voor het overgrote deel in de syntax.

Wel een punt om rekening mee te houden bij de keuze tussen VB en C# is dat veel 3rd party componenten (editors, menu's, grafieken, etc.) in C# geschreven zijn. Mocht je 3rd-party componenten gebruiken, waarbij je ook in de source van de componenten zelf wijzigingen wilt doorvoeren, dan is het makkelijker om voor C# te gaan. (Zelf doe ik alles in VB.NET, en waar nodig, pik ik m'n graantje C# wel mee. :) )

edit:
Om verwarring te voorkomen: Qlone geeft correct aan dat VB en VB.NET bijna dezelfde syntax hebben. Waar ik op duidt, is dat het verschil tussen C# en VB.NET grotendeels syntactisch van aard is (wat Qlone in een eerdere post ook heeft aangestipt.)

@Sybesma:
Precies wat ik bedoel! Waar ik hierboven aangeef onder welke omstandigheden het makkelijker is om voor C# te gaan, doel ik op de wijze waarop je niet genoodzaakt bent de syntax van meerdere talen te leren. Het blijft natuurlijk mogelijk om binnen hetzelfde .NET project meerdere talen te gebruiken. (Het is natuurlijk wel de vraag in hoeverre een onervaren developer die nog geen taalvoorkeuren heeft ontwikkeld, zich al bezig houdt met frotten in 3rd party componenten. ;) )
Ja indeed, zo doe ik dat dus ook. Je merkt tog eik in alle reacties dat de meeste vb'ers die gepost hebben nog teveel denken in oude sweren en nog totaal niet OOP minded zijn. Want dat is natuurlijk de grootste stap. En door dat onbegrip is alles wat .NET nieuw is de groote boze wolf.

Strong typed programeren doe je Visual Studio ook niet uitzichzelf je kan nog steeds knoeien bij het leven hoor. Het is gewoon de "Taal" goed beheersen. Volg een cursus! ofzo? :z
Maak twee projecten met BL-Code, 1 in VB en 1 in C#. In die BL-projecten kun je de externe code frutten.

Alles in 1 solution, de voorkant maak je vervolgens in je favoriete syntax. Zo simpel is het.

Wie al te veel tijd besteed aan discussies over C# of VB heeft het niet begrepen want je kunt ze dus gewoon samen gebruiken.
en absoluut ongeschikt om een echt grote applicatie in te bouwen
Ja, en op deze aardbol worden alleen maar 'echt grote applicaties' gebouwd, dus VB moet nodig in de prullenbak...
(disclaimer: ik werk ook liever in VB.NET dan in VB6, maar je punt vond ik nogal zwak ;))


Verder zal VB6 nog wel even blijven bestaan, iig zolang Office nog met VBA blijft werken (al is het maar backward-compatible)
VB.NET is helemaal niet sneller dan VB!!!
VB compileer je direct naar native code en zal altijd sneller wezen dan Intermediate Language die Just In Time gecompiled word.
De JIT-compiler optimaliseerd wel een beetje, maar in het begin deed die het 3 keer zo slecht. Dat zal nu wel iets beter zijn, maar sneller zie ik toch echt niet gebeuren. Dacht je dat al die nieuwe features gratis waren?

Niet dat dat erg is. Performance moet je altijd met de menselijke maat meten. Een gebruiker zal het verschil niet merken tussen 0.01of 0.001 seconde wachten.

Daarbij heb je in .NET meer opties om te versnellen.
1.code verbeteren (altijd een goed idee)
2.Asynchroon/Multithreaded (vooral voor een betere gebruikerservaring, denk BeOS)
3.Een gedeelte native doen door trage functies in een DLL te propen. (Managed DirectX is hier een voorbeeld van en haalt 95% van de performance van normaal DirectX)
Zou nóg meer complexiteit in een programmeertaal eigenlijk wel er aan meewerken dat deze sneller naar de gebruikte assembly-taal van de processor is om te zetten?
Ik vraag het mij af, aangezien deze omzetting toch wel belangrijk is voor de snelheid waarbij programma's draaien. We zullen zien.
Zou nóg meer complexiteit in een programmeertaal eigenlijk wel er aan meewerken dat deze sneller naar de gebruikte assembly-taal van de processor is om te zetten?
Als dit je prioriteit is lijkt me logisch dat je zowieso een low level programeer taal als c++ neemt om de taak op zich te nemen. .NET en Java 6 zijn vooral bedoeld om nog dichter bij het denk niveau van de mens te komen. En dit is denk ik ook wel heel belangrijk omdat je als programeur zo het beste je doelen kan converteren naar goede en (tenopzichte hiervan) snelle code.
Ik vraag het mij af, aangezien deze omzetting toch wel belangrijk is voor de snelheid waarbij programma's draaien. We zullen zien.
Ik denk niet dat het een probleem vormt, met de kracht van PC's vandaag de dag moeten we tog ook een stapje vooruit kunnen zetten.
Als dit al geïmplementeerd zit in de huidige beta's van Visual Studio 2005, dan vind ik het wel een overdreven marketingpraatje. Zo niet dan hoop ik dat de fundamenten van de taal, die nou juist zo fijn zijn, gewoon hetzelfde blijven. Data-integratie in de taal zelf vind ik meer iets voor VB.NET, dat is toch al meer de RAD-taal van de .NET-familie. Bovendien komt het niet overeen met de weg die MS is ingeslagen met C# 2.0 in die eerder genoemde beta's. Daar lag de nadruk namelijk op meer en wat complexere programmastructuren. En dan gaan ze het nu plotseling omtoveren naar een RAD-taal?
hmm.... ik vond de volgende programmeertaal beter ;)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True