The company I work at is run on Excel sheets. Several of those sheets have some form of VBA code embedded. I'm doing some maintenance on them, but it feels really dated.
What's gonna happen to Office VBA?
Why hasn't Microsoft released an embedded .NET macro language for Office?
I would say it's time for you to dive into .NET.
You can call .NET libraries from Excel.
They are adding VBA support to the next version of Office for the Mac, so I suspect that it'll be around for a while.
I kinda came across the same line of thinking yesterday. What a coincidence. Suddenly the boss at my parttime job was looking for an Excel application I created 3 years ago (left the company in 2007 and came back to them as parttime employee to augment my fulltime job). I remember I had converted that to an MS Access 2003 application; but the app needs to be updated to fulfill newer requirements. Guess what, I think I already forgot VBA. It is not the right time to go back and re-learn things from ground up. I am moving on with C# 2.0/3.0. Rebuilding that MS Access 2003 application with C# 3.0 will be a great learning experience, I'm sure!
@IainMH is right..." it's time for you to dive into .NET"
Short answer: you're probably fine for a while yet.
Long answer: VB6 (which is what VBA really is) is pretty much a dead, unsupported language, last updated a decade back with an IDE from the same period. It's only still around because it's embedded in Office and there are millions of Office apps that would stop working if VBA was removed or changed. Not to mention millions of mightily annoyed users.
So how to move forward? Can Office be re-implemented in managed code? Does Microsoft want to do that at all? Are they going to make an even bigger backward-compatibility break than the Ribbon and just discard the notion of macro recording and interpreted embedded code? I just can't see my users taking to VB.NET in Visual Studio, using COM Interop and whatnot.
If I had to put money on one outcome (and I wouldn't want to bet much even then) I'd be looking at the Dynamic Language Runtime and the fact that several languages are in various states of preparedness to run on it. Suppose the DLR, with some suitable replacement or wrapper for the Office app COM model, were to replace the VB6 runtime. Further, suppose VBA were implemented as a DLR language. Now legacy VBA will continue to run, just on a different (modern, supported) interpreter and into the bargain, we can program Excel macros in Python, Ruby or whatever other DLR language takes our fancy.
But that's just my best guess - I have no idea whether or not it's anywhere near to waht will actually happen. I'd surely love to be able to program Excel macros in Ruby, though.
Well I'm a experienced .NET programmer. I tried Tools for Office which is a pain to use and it requires you to distribute assemblies (LOL.) There's no way Finance or Delivery is going to use that. We had a good laugh before hitting uninstall.
We tried Google Docs, which was surprisingly flexible, but still not as powerful as Excel macro's. Microsoft has stagnated since 2000, and Google is moving fast, so in a few years the answers might be different. VBA itself is actually less powerful today due to all the security nonsense.
In the end I still got a button in their sheet to do what they want, and they can make minor changes to the code if they like. It's weird that VBA is the way to go for something that I suspect all finance departments in the world use.