Yes. On the 'porting', I can believe that! However, I couldn't do the porting because I don't know C# syntax!

For "classic VB", I don't know that either! I never used it. For Windows programming, I just started with what you call 'VB.NET'. I didn't mention 'classic VB' (or VB 6.0 or whatever it was) but tried to indicate that I am using the newer, most recent version of VB and am also heavily using .NET, ASP.NET, and ADO.NET.

On the 'porting', sure: It appears that in effect Microsoft went 'language syntax agnostic', concentrated on the lower levels down toward the processors and Microsoft's 'common language runtime' (CLR), their 'intermediate language' or whatever they call it, etc. and in effect said that anyone was welcome to develop any 'syntactic sugar' on top they wanted. Sounds like a good move to me.

I understand that C# offers a little that VB.NET does not, e.g., for 'reflection' or whatever, useful for writing polymorphic or more efficient late binding code. Okay. I'm trying to avoid using late binding. For polymorphic code, mostly for object oriented programming, I'm just using .NET where I mostly don't have to think about polymorphism.

I have written a few classes and, then, a few polymorphic functions, but there I used interfaces which I regard as much the same I've done for decades with 'entry variables'. The problem has always been, and still is, inside the polymorphic code, for each time touch the relevant data, have to call a function that is passed to the polymorphic code, and even just a little such usage can double or triple execution time of the polymorphic code. Of course another way out is to use 'generics', but those go way back, also: Basically just have the compiler write different versions of the code depending on the data types to be used.

Since VB.NET can be translated to C#, if I have to look at some C#, then I will imagine that I'm just looking at VB.NET with some 1-1 syntactic translations.

But the thread was concerned about training employees, and it seems to me that the syntax, semantics, etc. of VB.NET are so nice that, just for the language, the training should be fairly easy.

Moreover, in my work, nearly all the effort is just understanding the documentation for .NET, ASP.NET, and ADO.NET. Then that understanding should be quite similar no matter what language is used to get to .NET, etc.

For understanding the basic VB.NET syntax and semantics themselves, that's from easy down to nearly trivial. So, for my company, I'm trying to stay with VB.NET instead of C#: Get what my company needs, have the code easier to read, and have training easier.

Yes, one of the nicer parts of VB.NET, and likely all the languages based on the CLR, and maybe not so easy for a beginner trying to understand and use, is the CLR 'garbage collection' (GC). I was afraid that maybe each few seconds GC would wake up, put all the application logic on hold, do its GC, and then restart the application logic, but so far I've been pleased: From some timings I've done, etc., I've seen no significant such intervals of 'application logic on hold'. What will happen with VB.NET and GC on processors with many cores will be interesting to watch.

I don't know that the CLR, VB.NET, C#, the other Microsoft languages based on the CLR, and .NET are in all ways the best possible, but so far I'm pleased and thrilled. E.g., they look solid enough for me to concentrate on my work for my company.

I've seen a lot in computing, including IBM's old efforts at some 'commonality' in the programming languages, etc., saw a lot of messes, and see what Microsoft has done as much better. That they got GC working well is IMPRESSIVE -- they could have messed that up. Microsoft could have made a huge mess out of the CLR, etc., but it appears so far that, instead, they did some good work.

What's comparable or good/bad in the Unix/Linux world I don't know.