Is VB.NET weakly typed compared to C #

Question

Yesterday I was in an interview where my interviewer (who admittedly did not claim to be an expert on this issue) stated that "VB.NET was more weakly typed then in C #" - (At the same time, he could not remember an example) .

This expression seemed wrong to me (especially considering that both languages ​​use the same framework libraries for their types), and I advised as such, and maybe he was confused by the ability to enable Option Strict or Option Infer on / off.

At the same time, I know that VB.NET has situations in which coercion like this will do - leading to unexpected unexpected results (although I also can’t remember under what conditions) - (Actually, I think I just remembered that it was mainly when doing arithmetic operations with different types, while other languages ​​would make you be explicit (?)).

So can someone make it clear that VB.NET somehow more weakly typed C # then, and if you could give examples?

Answer 1

“Weakly typed” and “strongly typed” are virtually meaningless without explanation. The way they are used usually means that "the type system has functions that I don't like" or "the type system has functions that I like." It seems that your interviewer does not have a clear idea of ​​what these terms mean, and therefore, probably, you should not ask questions about them in the interview.

There are many features of type systems that different people say are “strongly typed” and “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 each variable and expression. Some people say that this means that the compiler has inaccurate type restrictions for each variable and expression. Etc. Each feature of type systems can count as points on the "strong".

I say, I give up the whole unreasonable concept of “strong” and “weak” typing and talk about what you really mean.

The differences between C # and VB systems are few, especially with the addition of "dynamic" to C # 4.0. Both C # and VB use a CLR type system in which each object knows its own type and in which illegal type conversions are detected by the runtime (either when the code starts, or when it is passed through the verifier), and are turned into exceptions. Both have one inheritance for classes and multiple inheritance for interfaces. Both make a distinction between value types and reference types. Etc.

The fundamental difference between C # and VB systems is that VB supports the optional set of time for static checking compilation time and checking the type of delay at runtime, more like a dynamically typed language. This is very convenient when interacting with object models designed for dynamic type systems. We added a similar function in C # 4.0, but in accordance with the historical support for static typing in C # 4.0, this function is based on the static typing of certain expressions as “dynamic”, which are then resolved by restarting the type analyzer at runtime and performing type analysis against live objects.

More on this topic can be found on my blog:

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

Answer 2

As an interview strategy, it would be better to say: "You are right, it is more weakly typed, but only for certain settings, such as Option Strict Off or Option Infer off"

Most people are happier saying "you're right" rather than "you're embarrassed" :)

Answer 3

(I’ve never used VB before, so for me it’s not at all)

They refer to Option Strict , or rather, what happens when you omit it.

The following VBs are compiled and executed in full execution, if 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 translates double into an integer, calls Method1 via the Object link and even calls Method2 (which doesn't even exist) - none of them will compile in C # or in VB with Option Strict On .

This definitely matches the definition of "not as strongly typed as" C #, "although the term seems rather subjective.

Update: We can use ILSpy to show that the “magic” happens 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 capable of doing things that would otherwise seem illegal in the CLR, although it seems to have some runtime.

Answer 4

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

The MSDN documentation here says a little more about what the option does.