For me, there are two primary benefits: 1. Communicating intent -- using a well-known testing framework (as opposed to rolling your own) more easily communicates to other people what the testing code is supposed to do, because it's using a standard language. 2. Integration -- such as with an automated build pipeline, or Visual Studio's Test Explorer.

APL?

Not sure what you're expecting here. `IList` has no knowledge of the type of its elements. Both the parameter to [`Add`](https://docs.microsoft.com/en-us/dotnet/api/system.collections.ilist.add) and the returned element of the [indexer](https://docs.microsoft.com/en-us/dotnet/api/system.collections.ilist.item) are typed as `object?` to be as wide as possible. You'd have the same problem here: var lst = new List(); IList ilist = lst; ilist.Add("Lorem ipsum");

Anyone else using LINQPad?

If you already have code that parses C# expressions, why not use the factory methods at [`System.Linq.Expressions.Expression`](https://docs.microsoft.com/en-us/dotnet/api/system.linq.expressions.expression)?

Isn't the author saying this is a faulty assumption? > Time and time again I see the discussion of Microsoft’s level of investment in VB.NET framed around the same faulty assumption: it’s just too darned expensive and impractical for Microsoft to support two .NET languages (ignoring the fact that they actually make three); it would take an army of developers and content writers at great expense nearly duplicating all effort across the ecosystem at worst or perhaps 10-30% of the (Developer Tools) division resources at best. Today I want to put that misconception to rest. If I understand correctly, the author is arguing precisely that it is not too expensive or impractical for Microsoft to support two .NET languages, or even three .NET languages. If there was enough interest in F#, Microsoft could make it as big as Scala.

Have you seen Rubberduck, an addin which uses ANTLR to parse VBA and add more features? Also, there's a proposal on Rubberduck's repo to create a Language Server Protocol implementation for VBA; this would allow any LSP-supporting editor, such as VS Code, to work with VBA.

I can find my IP address on Win 10 (1809) as follows: Click on the wireless icon in the tray Click on the Properties link for the current network Scroll down to the bottom; there's a section labeled Properties where I can see my IP address. (two clicks and a scroll) Or, I can open Control Panel, search for Network, click on View network connections, right-click on the connection and choose Status, then click on Details. (after opening Control Panel, typing and three clicks) But at the end of the day, ipconfig is still fastest.

John Simmons / outlaw programmer wrote:

Because the name starts with "VB".

Because you don't like the name? It seems to me your dislike is far to strong to be justified by this.

John Simmons / outlaw programmer wrote:

The words "virtually" and "almost" should be indicators for you...

I was referring specifically to pattern matching and types that make use of Span, which are both relatively new features in C# and .NET in general. Unsafe code is also something that C# has which VB.NET doesn't. IMO, pattern matching is as much a game-changer as LINQ, in writing expressive code, and it is quite unfortunate that it is not yet in VB.NET. But I think the others are relatively edge cases. Your average business developer, targeting a Web stack or desktop application, doesn't need the higher performance of Span, or unsafe programming -- not in C# and not in VB.NET. Are you aware of other differences in day-to-day usage? Please feel free to correct me.

John Simmons / outlaw programmer wrote:

"Inferring" and being typeless do not make VB a better idea.

I think that inferring the type in general is a good idea (using `var` in C# or `auto` in C++), because the code becomes more declarative -- focused on the intent of the code, and less focused on the mechanism the code will use. It's true that when every byte matters, it may be important to specify the type as byte, but again, I think these are relatively edge cases. But I didn't say I think these are good things; only that these are things that work in VB.NET and will not work when transferring this knowledge over to C#. (In fact, inferring delegate types from lambda expressions might involve a serious performance hit. If I have a database with a million records, and I use an ORM to extract the records which match a certain condition:

Dim qry As IQueryable(Of Person)

'fill qry

Dim filter = Function(x As Person) x.LastName.StartsWith("A")
Dim results = qry.Where(filter)

this code will use the Enumerable.Where extension method (which takes a delegate instance and not an expression), retrieve all the records in the database, and filter them in memory in the application code, all without any error. C# will not allow this, and force you to explicitly type filter as

You mean the Excel and Word object models, respectively. You can easily access the Word object model from Excel, and the Excel object model from Word. You can also access both object models from an external program/script -- .NET languages, Python, VBScript, JScript and others. I think the limitations of these object models are independent of the language. VBA (and VB6) is limited in that it doesn't have a first-class-function mechanism (AddressOf doesn't count, as AFAICT there is no way to call such a function pointer from VBA), nor does it have a lambda function syntax. This means that LINQ/FP-style data processing is impossible in VBA/VB6, and filtering / sorting / projecting any collection of data involves nested For Each and conditional blocks.

This thread is about VB.NET, which can express virtually everything that C# can express, albeit with a wordier syntax. Do you mean that C# is not a real programming language? Or do you mean that VB6 / VBA is not a real programming language (which I could get behind, if not entirely agree with)?

I'm curious to know why you feel that way about VB.NET, which can express virtually everything that C# can; and like other .NET languages can make use of (almost all of) the types in the .NET Framework. There are obviously various small differences (VB.NET allows inferring the delegate type, allows assigning a numeric string to a number, etc.) Generally, I have found only one reason to prefer C# over VB.NET -- VB.NET's syntax uses English words where C# would use symbols.

Does that mean if I use F# I'll have more problems than if I use regular expressions?

Are you sure? Maybe the white car IS your other car[^]

Douglas Crockford, the inventor of JSON, pronounces it "Jason".

Doesn't C#'s ``foreach`` come from VB's ``For Each``? AFAIK C++ doesn't have any equivalent.