Op de bijeenkomst van gisteren is door Frans Bouma en Maurice de Beijer strijd geleverd over de vraag welke ontwikkeltaal nu beter is: C# of VB.NET. Nu ja, strijd. Plus- en minpunten van iedere taal werden belicht, mythen ontzenuwd en om het niet tot in de kleine uurtjes te laten duren werden sommige puntjes makkelijk weggegeven. Maar ieder voordeel van de één ten opzichte van de ander is ter stemming gebracht. Hier is de uitslag:
|
Voordeel voor C# |
Stelling |
Voordeel voor VB.NET |
|
● |
C# programmeurs zijn beter. Ze hebben meestal een academische achtergrond. Bovendien worden ze beter betaald.
|
|
|
|
VB.NET beschikt over optionele en named parameters. Dat maakt het geschikter voor interop met bijv. Office. Een reeks Type.Missing parameters in een methodcall is immers niet nodig.
|
● |
|
● |
C# beschikt in versie 2.0 over het yield return keyword. Hiermee wordt een waarde van het enumerator object teruggegeven of beëindig je een iteratie. VB.NET heeft deze mogelijkheid niet, alhoewel er wel alternatieven te bedenken zijn.
|
|
|
|
VB.NET maakt late binding veel gemakkelijker. Hierdoor is COM interop eenvoudiger te gebruiken dan in C#.
|
● |
|
● |
C# 2.0 beschikt over anonymous methods. Daarmee wordt voorkomen dat kleine stukjes functionaliteit een eigen methode nodig hebben en daarmee de class ‘vervuilen’. VB.NET krijgt dit waarschijnlijk in versie 9.0 (de eerstvolgende versie).
|
|
|
- |
De performance van in C# geschreven code is beter. Nu, dit blijkt een mythe. Het heeft lang geduurd om iets te vinden dat in de praktijk in VB.NET trager lijkt te werken: een tien niveaus diep geneste for-next loop. Wie dergelijke code schrijft, kan wellicht beter een ander beroep en niet een andere ontwikkeltaal kiezen. Alle code wordt immers gecompileerd tot Intermediate Language (MSIL). Er zitten wel verschillen in de resulterende IL code, maar die hebben vrijwel geen effect op de performance. Conclusie hiervan is dat verbetering van performance vooral in algoritmes moet worden gezocht en niet in de taal.
|
- |
|
● |
Performance, ronde 2. Is er dan nooit sprake van betere performance in C#. Ja, maar dan verlaten we onze veilige managed omgeving, waar we ons geen zorgen hoeven te maken over geheugenbeheer. In C# kunnen we code markeren als ‘unsafe’. Daarbij moet ook de de applicatie gecompileerd wordt met de unsafe parameter. In zo’n stuk code kan met pointers, à la C++, gewerkt wordt en direct geheugen in- en uitgelezen worden. Dat is sneller, maar pas op dat je je vingers niet brandt.
|
|
|
|
VB.NET beschikt over extra mogelijkheden voor errorhandling. Unstructured error handling (‘on error resume next…’) wordtook door de huidige generatie VB.NET ontwikkelaars liefst vermeden, maar is wel mogelijk. Een meer handige feature is de Catch When instructie die extra condities toelaat voor het opvangen van een exceptie.
|
● |
|
● |
In Visual C# 2005 (de IDE voor C# 2.0, onderdeel van Visual Studio 2005) beschikken we standaard over een reeks refactoring mogelijkheden. In VB.NET 2005 is dat minimaal, maar om het gebrek op te vangen kan men via de MSDN site gratis een DevEpress ‘lite’ downloaden voor VB.NET die deels overlappende refactoring mogelijkheden biedt. Omdat het standaard wel in C# zit, punt voor deze taal.
|
|
|
|
Hulp bij het ontwikkelen. VB.NET 2005 wordt geleverd met een flinke verzameling codesnippets. Ook kent het de My-namespace waarmee veel voorkomende acties (bestandsbeheer, netwerk) via een soort shortcut beschikbaar zijn. Ook is er een klein application framework, waarmee via projectinstellingen veel voorkomende taken (splashscreen, single instance app) worden geregeld. Deze ondersteuning is er niet in C# en moet handmatig worden ingevuld.
|
● |
|
● |
Namespaces in VB.NET zijn standaard verborgen. De ontwikkelaar ziet ze niet, maar ze zijn er wel. Daardoor is men ook niet snel geneigd ervan gebruik te maken, en als men het wil, zijn er beperkingen, omdat de opgegeven namespaces altijd onder de in het project opgegeven namespace vallen. In C# is men explicieter en vrijer in het beheer van namespaces.
|
|
|
|
In VB.NET is het With-statement erg praktisch voor geneste objecten. Objecten die onderdeel zijn van een ander object die weer onderdeel is van een ander object. Met het With-stement voorkom je dat je telkens deze hiërarchie moet intikken.
|
● |
|
½ ● |
De errorlist in de IDE van VB.NET wordt direct bijgewerkt zodra men van coderegel verandert. De background compiler kijkt direct of er fouten in de code zitten en meldt dat je hier nog wat aan moet sleutelen. C# kijkt enkel naar de syntax van de code, niet naar de semantiek zoals dat in VB.NET gebeurt. Dit aspect bleek eerder een kwestie van smaak. Sommige VB.NET ontwikkelaars willen ook niet voortdurend op hun fouten gewezen worden, wetende bijvoorbeeld dat een ingevoerde methode nog geschreven moet worden. Ook kan bij grote projecten deze background compilatie het systeem belasten. Niettemin is de compiler wel heel efficient en compileert enkel de verandering. Omdat dit voordeel ook als nadeel werd ervaren, voor beide talen een half punt
|
½ ● |
Los van de taal is ook de ontwikkelomgeving, de IDE, van belang. In de discussie is het daarom van belang om vast te stellen of een ontwikkeltaalverschil zit in de taal zelf, of in de tool die men gebruikt om in deze taal te programmeren.
Concluderend kon tijdens de bijeenkomst vastgesteld worden dat C# vooral correctheid nastreeft en VB.NET vooral pragmatisme. De zinsnede "C# dwingt je om..." kwam in dit verband meerdere keren terug, maar evenzeer "Met VB.NET gooi je wat dingen bij elkaar..." .
Meer nuttige links: