Is VB.NET weakly typed compared to C#

Question

Yesterday I was at an interview where my interviewer (who admittedly didn't claim to be an expert on the subject) stated that "VB.NET is more weakly typed then C#" - (At the same time he couldn't recall an example).

This statement seemed incorrect to me (particularly given that both languages use the same framework libraries for their types) and I advised as such and that perhaps he was confused with the option to turn Option Strict or Option Infer on/off.

At the same time I know that VB.NET has situations where it will do type coercion - leading to occasionally unexpected results (although I also cant recall under what conditions) - (Actually I think I just remembered that it was mainly when performing arithmetic operations with different types - whereas other languages will force you to be explicit (?) ).

So could someone please clarify is VB.NET somehow more weakly typed then C# and if so could you provide examples?

• Daniel Little: There's no such thing as weakly typed, you are or you aren't
• Andrew Barber: I haven't used VB in a long time, and when I did I always had Option Explicit on; but does that option not still exist?
• Andrew Barber: Also... just tossing it out there; are we truly talking 'strongly typed', or do you mean 'statically typed'?
• Maxim Gershkovich: @Lavinski - I wouldnt agree that it's quite as black and white as you claim and @Andrew Barber Option Strict turns Option Explicit along with a number of other checks on.
• Maxim Gershkovich: Nah weakly, we know that it is statically typed. I think he was referring more to cases where types behaved unexpectedly under various conditions - that was my take on it anyway.

Answer 1

"Weakly typed" and "strongly typed" are effectively meaningless without clarification. The way they are used they usually mean "the type system has features I do not like" or "the type system has features I do like". It sounds like your interviewer does not have a clear idea of what those terms mean, and therefore probably shouldn't be asking questions about them in interviews.

There are a lot of features of type systems that different people say are "strongly typed" vs "weakly typed". For example, some people say that "strongly typed" means "every object knows its own type at runtime". Some people say that "strongly typed" means that the compiler knows the exact type of every variable and expression. Some people say that it means that the compiler has inexact type bounds on every variable and expression. And so on. Every feature of type systems can count as points towards 'strong'.

I say abandon the whole ill-founded notion of "strong" and "weak" typing and talk about what you actually mean.

The differences between the C# and VB type systems are few, particularly since the addition of 'dynamic' to C# 4.0. Both C# and VB use the CLR type system, in which every object knows its own type, and in which illegal type conversions are detected by the runtime (either when the code runs or when it is passed through the verifier) and turned into exceptions. Both have single inheritance for classes and multiple inheritance for interfaces. Both make a distinction between value types and reference types. And so on.

The principle difference between C# and VB type systems is that VB supports optionally dialing down the compile time static type checking, and deferring type checking to runtime, more like a dynamically typed language. This is very handy when interoperating with object models that were designed for dynamic type systems. We added a similar feature to C# 4.0, but in keeping with C# 4.0's historical support of static typing, the feature is based on statically typing certain expressions as "dynamic", which are then resolved by starting up the type analyzer again at runtime and doing the type analysis against the live objects.

More on this subject can be found on my blog:

http://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/

• Maxim Gershkovich: Awesome to get a response from the man himself! Thank you. PS: Can you please make Using() {} work for multiple types without hacks? Pretty please! :-p
• Andrew Barber: @Maxim - What is wrong with using(var obj1 = new obj1) using(var obj2 = new obj2){ obj1.Thing = obj2.Stuff(); }
• Maxim Gershkovich: I consider that as much of a hack as Using ((IDisposable obj1), (obj2)) {} - Just doesn't look or feel right..
• Andrew Barber: What I typed - each using on its own line, of course, is nice and neat and compact. Or are you one of those people who thinks that statements need to be 'short', simply for shortness' sake? ;-)
• Maxim Gershkovich: lol Ouch, well no but if I wanted to be verbose I'd move back to VB. :-)

Answer 2

As an interview strategy, it would have been better to say "you're correct, it is more weakly typed, but only for particular settings like Option Strict Off or Option Infer off"

Most people are happier to be told "you're correct" rather than "you're confused" :)

• Maxim Gershkovich: lol, Although I take your point I'm not interested in working for someone who can't take criticism or debate. Thankfully I have the luxury of current gainful employment.

Answer 3

(I've never really used VB before, so this is all new to me too)

They are referring to the Option Strict statement, or rather what happens when you omit it.

The following VB compiles and runs perfeclty as long as you have Option Explicit off:

Class Widget
 Sub Method1()
 End Sub
End Class
Sub Main()
 Dim someInt As Integer
 Dim someDouble As Double
 Dim someObj As Object = New Widget
 someDouble = 1234567890.9876542
 someInt = someDouble
 Call someObj.Method1()
 Call someObj.Method2() ' causes runtime error
End Sub

The above implicitly casts a double to an integer, calls a method Method1 on an Object reference and even calls a method Method2 (which doesn't even exist) - none of which will compile in C# or in VB with Option Strict On.

This definitely matches the definiton of "not as strongly typed" as C#, although the term seems to be fairly subjective.

Update: We can use ILSpy to reveal the "magic" going on here by looking at the compiled assembly (in C#):

object obj = new Module1.Widget();
double num = 1234567890.9876542;
int i = Math.Round(num);
NewLateBinding.LateCall(obj, null, "Method1", new object[0], null, null, null, true);
NewLateBinding.LateCall(obj, null, "Method2", new object[0], null, null, null, true);

This explains why the VB.Net compiler is able to do things that would otherwise seem to be illegal in the CLR, although it does seem to come with some sort of runtime performance penalty.

Answer 4

VB.NET allows both. As mentioned in the comments, you can set this in the project (or file) by setting Option Strict either ON or OFF.

The MSDN documentation here talks a bit more what the option does.