I liked this idea better when it was called "VBA".
It seems like "they" (whoever they are) took VBA away (don't kid yourself it's going away) because it wasn't deep enough, it didn't give enough control.
Let's get in our time machine and go back 5 years:
We AutoCAD programmers were told "You need to make the change to this new .NET code. Pick your poison. VB.NET or C#.NET. We're not going to lie, it's going to sting a bit. But in the long run you'll be glad you learned all about DocumentLocks and Transactions and ResultBuffers and Delegates and Interfaces and PolymorphineInjections . . ."
Fast forward to today:
"These languages are too complicated. They take too many lines of code and they aren't very easy to read so here's what we're going to do for you. We're going to let you write code that is simpler, more logical without all the complexity. Look how great it is to write simple code to get your work done! . . . You are welcome!"
So we have C++, C#, VB.NET, F#, IronPython, IronRuby, Boo (I'm not making that last one up) and who knows what else.
With all these new choices in programming languages will support be easier or harder to get?
Will examples be more plentiful or more scarce?
Will you really be able to produce better tools quicker or will you be spending your time learning new languages?
By the way what help will developers get when it comes to debugging these new languages? Remember the help AutoLISP gave you when it broke?
Prediction: In 3 years we will have VBA back. It won't be called VBA and it won't be built on the same platform as todays VBA. But it will be a relatively easy interface that let's the AutoCAD programmer create quick, friendly, powerful programs without the overhead of Visual Studio.
And we will have to learn a new language to use it.
It's tied in with the whole idea of "frameworks".
Basically, what's happened for a long time (since C became popular) is for people to have "class libraries". This is where people would typically put all the common stuff - you know, the basic routines that people use all the time, and don't want to rewrite all the time. Then the typical way to create an application was to start writing code that calls the routines in these "class libraries".
Along the way, it became apparent to some that we were still rewriting a lot of the same code over and over again. So they got the idea to try and include EVERYTHING that we write all the time in a "framework". As opposed to having a class library full of routines that get called by our application, we have a framework that contains all the common components of an application. Then we only write the parts that are different from other applications. We actually start an application by simply instantiating an "Application" class (or a subclass of an "Application" class). Then this "Application" class has a bunch of hooks (i.e., events and delegates), which allow us to add our custom pieces. Net result is we can build a better application faster.
In other words, instead of creating a bunch of custom code that makes a bunch of calls to a "Class Library", we have a framework that makes a bunch of calls to our custom code. In many respects, it's the mirror-image approach to what we did in C.
When we start looking at things this way, then most of the time, all we need to do is specify little pieces of high-level logic. Everything else is done by the framework. So we actually aren't losing anything as programmers. By contrast, we're gaining, and we can concentrate only on the important logic of our application. All of (or at least most of) the "grungy details" are taken care of in the framework.
Now of course, not EVERYTHING can be done via a high-level approach. So we might still find ourselves breaking out chunks for implementation in some lower-level language, such as C++ or (in very rare cases) even Assembly. But for most application programming, this approach yields FAR better results, FAR quicker, than attempting to do everything via a low-level approach.
