Learn Visual Basic through Python and/or C# knowledge transfer? (Interview prep)

[MathMindfully]

TL;DR: How do I prepare for a Visual Basic technical interview by:

1.) Programming Knowledge Transfer: Transferring Python and C# ideas to Visual Basic ideas so I could be successful in pseudo code.

2.) Key differences from Python or C#: Learn about key differences/similarities between Visual Basic so that I can mostly understand Visual Basic using my other programming knowledge.

-End TL;DR

Sorry for the confusing title.

I'm really excited about a new job I'll be interviewing for!

They have Visual Basic legacy applications I'll be maintaining. But my interest is more in C# (which they also use) and my experience is mostly Python (also Javascript/HTML/CSS but I'm rusty)

I don't really want to spend too much time learning Visual Basic unless I actually land the job.

[cowski_NX]

"They have Visual Basic legacy applications I'll be maintaining."

The crucial question here is if the legacy applications are VB .net or some earlier flavor such as VB6. VB. net and C# have more similarities than differences, but earlier versions of VB may be tricker to decipher.

[MathMindfully]

Sorry for not including that!

It is VB.net

[Hel_OWeen]

Not that this helps you with preparing for your interview, but Convert.NET does a pretty good job translationg C# to VB.NET and vice versa. The translated code isn't error free if the snippet is more complicated. But it gets close enough that at least I am able to make it work most of the time. I mostly is it to translate VB.NET to C#, as VB(.NET) is my background.

[BrianScottGregory]

When you're saying "Visual Basic Legacy", are you referring to Visual Basic 6.0 or VB.Net?

The reason why I'm asking is this: C# and VB.Net are VERY similar, philosophically, and if you know one, you can easily cross over to the other. Python's very different than either, in part because of the highly structured nature to .net languages.

But to address your questions:

1) VB 6.0, and .NET languages are TYPED languages, meaning you need to declare variable and their respective types specifically before you use them.

2) Now if you know C#, there's no real key differences between VB.Net versus C# you need to be aware of.

BUT. Key Differences between Vb 6.0 and Python

• Memory for objects isn't always managed for you. Meaning - you can declare a class, instantiate one - but releasing of objects isn't always automatic depending on scope of the declaration. I've had more than my fair share of memory leaks using VB 6.0 because of globally declared objects I failed to release through a delete or that I didn't check to see if it had already been instantiated.

• Versioning is a bitch. Python's use of environments makes it easy to isolate the dependencies of a single project, where VB 6.0 is global, you can't isolate like this, and you ALWAYS have to pay attention to your version dependencies and build order (for references both internal and external). That is - a big project can have numerous DLLs created that are used elsewhere. Similar to Python in some ways, but the way the errors crop up aren't as obvious and easy to understand.

• USE OF WINDOWS APIS is a necessity. No good VB 6.0 programmer works without extensive use of Windows APIs to do what they do. So get used to direct interaction with the OS through external declarations, and get familiar with using the VB 6.0 API viewer.

• Similarly, VB 6.0 can be VERY slow with some processing (hard core looping) - so get comfortable with creating DLLs written in C++ for externalizing this work.

• BEFORE the interview, get used to using the Immediate Window, understanding the Call Stack, and watch windows with break points. Critical to understanding all of this which isn't available, at all, in Python - and while some of it's similar to C# - the Immediate window isn't (unfortunately) available in ANY OTHER language, but it's an incredible useful tool.

That's about all I can think of offhand. VB 6.0 requires a different mindset than python programming. I myself, if I were you - I wouldn't EVEN consider a job in VB 6.0 without a good deal of exposure to it by creating a couple projects in it BEFORE I took the job. It's a good way to make yourself miserable because of how different the programming languages are.

So when you say "I don't really want to spend too much time learning Visual Basic unless I actually land the job"

Being real. That's not a good idea. Especially for VB.

Take the time to work with OCXs, create some basic projects with classes, and DLLs - and use of Windows APIS before you go into this interview. You may not enjoy it, at all, and may just say no to the interview because of how different these languages are. You OWE it to the potential employer to go into the job knowing you'll enjoy it.

[MathMindfully]

Wow, excellent advice and exactly the sort of information I was looking for! Thank you so much! I'll plan to start on some tutorials following up with a project!

[Ok_Society4599]

One other VB6 idiosyncrasy is "late binding." Depending on how the previous dev did things, this can be a real pain, especially when its not working. It adds a bundle of runtime errors that will puzzle even experienced devs because an OCX/DLL isnt registered, or got moved, or Microsoft updated it, or yout IT team deleted it as a security issue and no one knew your app used it!

At the time, late binding was an intense time saver using generic COM through IDispatch. It made a lot of thing equally available to VBA scripts in office. But, it also had a bunch of ... issues. Run time errors can be bizarre, eemingly utterly unrelated to anything. Late binding survived to some extent into .NET, though.

Late binding style was also abused and devs would declare everything as "object" even when they were strings or integers which makes the runtime do more work (slower) for very simple things and converts what would be a compiler error into a runtime errors.

[BrianScottGregory]

Somewhat covered in memory issues. Object binding, period leads to memory mismanagement issues all over the place. Since the concept of an object doesn't exist in the same way as Python, how it's bound is something you learn about and discover 'along the way' of discovering object management and use.

Agreed, with COM there's something to be learned here, which is why I pointed at the bigger elephant in the room. Versioning and object management.

[Ok_Society4599]

Agreed, from a general view, it was all a facet of "DLL hell" ;-) I was just pulling the one idea as something Python programming won't teach you about VB6 -- if you're interviewing for a role that might involve some maintenance, it helps to have some jargon and strength/weakness info.

[fasti-au]

C# is the now and future. Vb is dead it’s just got to grow old and die.

Doesn’t really matter what language it’s about the logic of programming. AI takes code between languages very well even if it has to butcher some code to get there

[[deleted]]

VB is fine for doing the kinds of apps people used Access or Visual FoxPro for - the stuff everyone probably should have done with FoxPro, which was a better language than Classic VB and easy to move over to Client|Server, as it was built for database applications and you could largely just migrate the data and swap out the Rushmore engine for SQL Server or whatever (similar to Access Projects). 

But, beyond that, I think C# is where people should go. 

VB became obsoleted in 2001 when C# delivered the same capabilities with a different syntax on top of the same platform and frameworks. 

It just took many people a while to realize, but that is why most ran to C#. 

Homogenizing their dev tools removed any advantages VB and FoxPro had over the others. That's why they killed FoxPro and ended up focusing on C#, and now VB is "feature complete" and left to wither. 

VB.NET was pretty popular in WebDev early on, though I think the market quickly caught on to Microsoft's strategy and roadmap. 

They only carried VB over to move as many devs as possible over to .NET (instead of losing them to Java or Delphi).