Jeg elsker både VB.NET og C#, hvilken skal jeg så vælge?

Udgivet: 18. januar 2010

Jeg er lidt i et dilema. Jeg elsker både VB.NET og C#.

Når jeg skal lave et nyt projekt, så sidder jeg altid og bruger alt for lang tid på at spekulere i hvilket sprog, jeg skal lave mit program i. Vi er alle enige om at det på et højt plan er rimelig ligegyldigt, da VB.NET og C# på et feature plan, er så ens, at der næsten ikke er forskelle - og dog.

Jeg elsker mit VB.NET, jeg er ikke flov over at sige det, selvom jeg godt ved at C# programøres generalisering af en VB.NET programmør, er at han er en anden-rangs programmør, som ikke har lært sine simikolons, og skriver dårlig kode.

Så lad mig som det første slå det fast: Jo jeg skriver dårlig kode - men det gør jeg også i C# - sproget har intet med det at gøre :)

Hvis jeg kigger på sprogene side om side, så har jeg meget svært ved at argumentere for at bruge C#, andet end den Geek love der følger med. Hvis jeg laver et VB.NET projekt, så er jeg noget mere alene, end hvis jeg f.eks. lavede det i C#. Jeg kan lige forestille mig den ”addr” føelse, som C# programmørene får, når de finder ud af at projektet er VB.NET.

Men sådan er .NET kulturen, og det er nok ikke noget man kan gøre noget ved.

Grunden til at jeg er så glad for VB.NET er at jeg ser C# som et meget kræsent sprog. Et eksempel er at du skal Caste dine objekter til strings eller til andre sjove objekter, hvilket resultere i en masse tekst, for at fortælle compileren, at du ved hvad du gør. I VB.NET stoler compileren på dig, som standard, og lader dig caste ting til andre typer, uden at du skal til at caste. Du har også muligheden for at sætte såkaldt Strict på, hvilket betyder at den nu også hyler, når du gør den mindste ting, som kunne resultere i fejl, som er sket ved casting. Du har altså valget.

Nu skal det siges, at jeg har oplevet, at vi har fået en enkelt fejl, i forbindelse med implicit casting i VB.NET, i det år, jeg har arbejdet med VB.NET på arbejdet. Hvis man tager den tid, det tog at finde den fejl (10min), og så opvejer det med den tid jeg har sparet, ved ikke at skulle caste hele tiden, så tror jeg nok jeg har vundet nogle dage på den der. Casting er en produktivitets dræber – puntum.

VB.NET har også en masse fede features, som XML literals, og My namespacet, som er fyldt med goodies. Vi har With keywordet, som gør at vi kan tilgå et objekt nemt, hvis vi bruger det mange gange. Select Case (switch) er faktisk brugbart i VB.Net, hvor i C# er den meget mere begrænset. En anden ting, som er lidt sjov i forbindelse med extensionmethods er at VB.Net også har noget som heder Modules. Modules, giver dig lige præcis mulighed for at have extenionmethods, som du kan kalde, uden at de ligger på et objekt, da de bare er globale metoder, alt efter hvilket namespace du inkludere. Derfor kan du lave små metoder, som gør din kode mere præcis – pas dog på med at du lige pludselig ikke gør din kode ikke-testbar. (Det samme gælder med extenionmetodes, og generelt statiske ting)

Modules er dog ikke noget, som jeg generelt bruger så meget, men det er en sjov lille ting i VB.NET, som kan have sin plads, og måske erstatte den typiske Utils klasse, med hjælpemetoder.

Generelt, vil jeg faktisk beskrive VB.NET, som mere Ruby agtigt, end C#. Det giver nogle fede features, som er koblet op mod produktivitet, istedet for ”korrekthed”.

Grunden til jeg elsker C# er dog lidt anderledes. Det er nemlig ikke pga. sproget, men mere de tools, som understøtter det. Resharper er et godt eksempel, som ganske hvist også virker 10% til VB.NET, men det er bare så meget bedre i C#.

Kodeeksempler er generelt også i C# - så man skal til at konvere koden til VB.NET – hvilket er ganske let, men dog en irretation aligevel.

Til sidst, så er det, lige som med meget andet, bare så meget lettere at følge med strømmen, og bruge det som alle hylder – så slipper man for alle diskutionerne om hvorfor man dog ikke brugte C#.

Jeg er stadig i tvilv om hvad jeg skal bruge, men sådan er det med valg – jeg er bare dårlig til sådan noget.

Nå men, hvad siger jakob?

Jesper Eiby skrev den 19. januar:

Rigtig god artikel, og du ramte plet med din C# stereotype's generalisering af VB folket. Jeg må indrømme at jeg ikke bryder mig om VB, men hver mand sin stil.

Og ja, på første forsøg sagde Jakob "Ved ikke", dette emne er endda for dybt for Jakob.
Arne Vajhøj skrev den 19. januar:

Hvis du bedre kan lide VB.NET end C#, så synes jeg da at du skal vælge C#. Den nok bedste begrundelse for at vælge C# nemlig at der er flere eksempler på nettet (ikke mindst indenfor mere komplekse problemer) er jo ikke relevant for dig, da du jo kan C# og næppe har problemer med at oversatte.

Sprog snobberi er for autodidakte teenagere.

PS: Jeg synes dog at argumentet med de manglende casts er lidt søgt.
Deldy skrev den 21. januar:

Hej Arne,

Ang. det med casts, så ser jeg ikke argumentet for hvorfor det skulle være søgt. Jeg er ude efter alt som dræner produktivitet, og selvom casts er til for at compileren måske kan fange en bug, så synes jeg alligevel, at det 9 ud af 10 gange, er en pris der er for høj at betale. Alt efter hvilke systemer du koder, så skal du caste mere eller mindre. Hvis du som os, sider og primært koder Webforms applikationer, så sker der pænt meget casting i forbindelse med f.eks. DataBinding.

Nu skriver du også at "Sprog snobberi er for autodidakte teenagere." - så kan jeg kun sige, at vi er ufatteligt mange teenagere der ude :)

Men generelt handler posten også om valget, og det er noget som Microsoft er rigtigt gode til at give os - hvilket jeg faktisk mere og mere ser som noget negativt, da jeg jo har så svært ved at vælge :)
Kasper Bo Larsen skrev den 19. februar:

En vinkel som du måske også burde overveje er, om du på et tidspunkt vil komme i nærkontakt med sprog som C, C++ eller Java. I så fald er min erfaring, at et rigtig godt kendskab til C# er en kæmpe fordel. Derimod har jeg ikke kunne bruge min VB-viden i forbindelse med andre sprog, sååh
janus007 skrev den 20. februar:

Jeg forstår heller ikke hvorfor du fokuserer så meget på casts, hvis du har et stort behov for at caste så er der noget grundliggende i vejen med koden og så er sproget ligegyldigt! - Show me the code ;-)

Modules er det samme som at skrive en class uden namespace, jeg kan slet ikke se idéen med modules, udover jeg da naturligvis kan huske tilbage i VB6 hvor de var fede, men det var inden VB blev til hvad det er i dag :)
Jesper Blad Jensen aka. Deldy skrev den 20. februar:

Hej janus007

Jeg giver dig helt ret i at hvis du koder op imod din egen kode, så er casts sjælden. Der hvor man f.eks. bruger mange casts er i forbindelse med Webforms. Desvære gør webforms ikke så meget brug af Generics, så f.eks. i din ItemDataBound events, så ville du skulle caste det hele - hvilket bliver lidt træls.

Jeg ved godt at dette selvfølgelig ikke er noget der skal bevise at VB.NET er gud, og C# er ringe - for som jeg skriver, så kan jeg godt lide dem begge. Der er meget små tekniske forskellige, og dette er altså hvad jeg kunne finde. At jeg så måske skriver det som om at det er en big deal - det er så sådan den måde jeg har valgt at skrive den på :) Fordi i har helt ret, det er nok ikke noget der ødelægger din dag, eller gør at din kunde ikke kan få sit projekt til tiden :)

Ang. Kaspers argument, så tror jeg også det er en af kernepunkterne i hvorfor C# er mere populær: C-familien, er bare så meget større end Basic familien, og derfor ligger det til højrebenet, at hvis man kan et C-sprog, så bør det være nemmere at gå over til et andet sprog, der også er i den samme familie. Dette gør naturligvis også at mængden af folk der kan C# er naturligt større end VB.NET
Troels Thomsen skrev den 20. februar:

Jeg synes, at VB.NET som sprog tager mange dårlige valg, der ultimativt ender med at gøre mange til dårligere udviklere. Fordi sproget tillader ting som Option Explicit Off og at man ikke bruger Option Strict, kan man altså producere nogle grimme løsninger. Det udelukker dog selvfølgelig ikke, at man stadig kan være en god udvikler og anvende det, ligesom grimme løsninger også sagtens kan fungere.

At sammenligne VB.NET med et dynamisk sprog som Ruby køber jeg heller ikke. Der er rigtigt nok mange fordele ved dynamiske typede sprog, ligesom der er fordele ved statisk typede sprog, men hvis det er pointen, er VB.NET slet ikke det rigtige valg til at starte med.

Et andet eksempel er en af de ting, du fremhæver som en fordel - det særlige My. Man kan med My.Computer.FileSystem.ReadAllText let læse en fil. Jeg kan dog ikke se, hvorfor man skulle bruge det fremfor File.ReadAllText. Hvad er formålet i, at man skal skrive mere, introducerer et par ekstra kald og bliver mere sårbar overfor ændringer? Det er vist en bjørnetjeneste. Netop muligheden for at kunne teste taler i øvrigt også fuldstændigt imod brugen af både Modules og My.

Derudover er jeg helt på linje med Janus, når det kommer til casting. Hvis du har brug for det så ofte, at det bliver en produktivitetsdræber, så er det altså symptom på helt andre problemer.

Jeg kan dog godt lide XML Literals ;-)
Jesper Blad Jensen skrev den 21. februar:

Hej Troels,

Jeg er enig i at man kan producere dårlig kode i VB.NET, som compileren ikke kan fange, fordi man f.eks. har slået de forskellige safegards fra. Dog som jeg skriver i min post, så er det meget sjældent vi rent faktisk støder på dem. Det argumentere selvfølgelig ikke for om man skal bruge dem eller ej - om man skal være "better save than sorry", eller om man skal tage de produktivitets muligheder der kommer ud af det.

Det er selvfølgelig en trade-off.

Ang. My, så kommer det an på hvordan du ser testing og testability. Det er rigtigt at det er svært at lave unit tests omkring et module - men ting der er i et module skal være ting som ikke behøver at blive testet, eller ting som man ved virker. Jeg ved godt det er lidt fy-fy i unit testing, men man er nød til at lave disse valg. Ellers skal du jo også til at teste string.IsNullOrEmpty i din kode. Det er rigtigt at My namespacet har mange ligegyldige metoder, hvor der findes nogle mere standard .NET metoder - men f.eks. som at hente en fil ned fra FTP, lave et one-liner kald til en Webserver, hvor du får response tilbage osv. er noget som My namespacet kan byde på. Sørger du får at du kan koble disse fra i din unit testing, ved at du selvfølgelig bruger interfaces som du altid gør, så har du måske vundet nogle minutter. Men vi snakker jo selvfølgelig om småting.

Og som jeg også skrev til Janus omkring casting, så er dette primært noget som bliver brugt i forbindelse med Webforms, men jeg giver jer da ret i, at jeg måske har lagt en andeles mere i det, end hvad godt er :)
Arne Vajhøj skrev den 6. marts:

Forsvandt der ikke nogle indlæg i forbindelse med at din blog skiftede host/software/et-eller-andet ?

Med hensyn til cast så mener jeg ikke at det er sprogs opgave at minimere tastetryk. Med normal KLOC/måned så er det ret ubetydeligt.
Arne Vajhøj skrev den 6. marts:

Jeg mener ikke at man skal afskrive et sprog fordi det giver mulighed for at slå checks fra.

C# vill jo også ryge på den konto. Konsekvent brug af unsafe blokke og pointere plus fra 4.0 variable erklæret som dynamic.

Skriv en kommentar