VBA and the Future - a bit of Philosophy?

[shades]

I have read numerous articles and reviewed many web sites that acknowledge that VBA is essentially dead in the near future. That is, after Office 2003 there may be only one more release that will have VBA (as we know it and as compatible with current versions). This has implications for all of us, certainly involving long-term, and even some short-term, decisions.

So, a few questions:

1. What are some of the long-term implications for your work in VBA?

2. Are there any short-term implications?

3. What are viable alternatives to carry on the work that has been done by VBA?

4. Will .Net be the framework for all future coding in Office? How will that relate to Mac OS X? (You knew I had to ask :) )

5. Does this mean that programming languages (Perl, Python, Java, AppleScript, etc.) will take over that role?

6. What kind of conversion issues must be thought through now to be prepared for this in the future?

-------------------

Some ramblings from an old codger...

[Steiner]

As we are still working with Office97 here :writer: , I don't think we will get to an Office Version that does not support VBA before 2150, and I hope then it won't make any difference to ME anymore:deepsleep.

By the way, the time .NET was introduced some people said VB 6 to be dead very soon. I can't see that by now (and I hope that it will still live a a while, I just can't afford to buy a new development toolkit every year MS thinks they have invented something "better").

[shades]

It would be good if there were a "line in the sand" that would allow us to use the same software for years. However, having now been in the corporate environment for a while (after being in the non-profit world for 20 years), these decisions that seem logical to the everyday worker are often made by those not using the software. How many have made the transition from XL 95, 97, 2000, 2002, and now 2003 in the past six years? And that was always within the same "world" so to speak, except for XL 95. However, if the future of Excel moves away from VBA, then there are serious issues for the everyday worker.

Some have even suggested that Excel/spreadsheets will fade away to be replaced by a hybrid database/spreadsheet.

[mark007]

Nah, the spreadsheet won't die, it's far too useful. If they tried to kill it off people would just use older versions of office!

As for moving away from VBA. There is no way that office will lose it's programming capabilities as it's too important to it's popularity and power. If anything, it is to head towards a .NET environment I guess. This is a fair way off though as the way office is written it will involve a full rewrite of the code from what I understand!

I can see Office and .Net becoming more and more integrated into windows but I think all these changes are a long way off yet. Longhorn (the next version of windows) is the key next step. After this things may start to change. So I think we have 5 years at least yet.

:)

[brettdj]

Nah, the spreadsheet won't die, it's far too useful. If they tried to kill it off people would just use older versions of office!

Agreed. I've seen corporations try to move to databases to replace financial spreadsheet models on a few occasions - the projects have floundered every time as the spreadsheet is so well ingrained

Spreadsheets have been the killer application for the pc for 20 years, I'd be surprised if this changed in soon

[ptvGuy]

For what it's worth, I don't see the imminent death of the spreadsheet anywhere near close. A database is a totally different animal. But VBA is a different story. In fact, I just started the process today of moving my Access 2002 database into Visual Basic .NET in order to stear it to a stand-alone application and get better recordset control. Unfortunately, I'm having to recode everything that has to do with my embedded graphics, because VB.NET doesn't like OLE objects. (I would have had to do this eventually anyway to get the web access to the graphics, but that's another matter.) In the end, though, I'll go wherever the money goes, and currently it's heading for VB.NET.

[shades]

Hey, ptvGuy, thanks. Here is a MS view of that same topic:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_vsto2003_ta/html/odc_VSTVBAtoVSTO.asp

[Tommy]

From what I have seen, the quality of the coders here in VBA, would not have too difficult of a transition to VB. I am in the process of translating all of my programs from FORTRAN to VB. The compiler we used was last issued in 1991. So I guess the point I am trying to make is if you drag your feet long enough something better will show up to help out :). After all you don't HAVE to be on the cutting edge, just a good thing to know for now. Tommorrow will be something different, or another way to look at things.

[ptvGuy]

Shades: Thanks for pointing me to that article. That was very helpful. They're right too; it's just too easy to pass the limitations of VBA unless you're writing a very limited office application or solution.

Tommy: Wow! FORTRAN. I started out in FORTRAN and COBOL back in the late 70's. In fact, we still had to put our programs on punched cards and take them to the main frame to run. One thing that keeps me from complaining about my work too much is reminding myself of the fact that my out-of-date, incredibly-slow, low-memory office computer would have been something in a science fiction story back then, and I probably would have laughed when the character in that story complained about it. Funny what we take for granted now.

[Brandtrock]

Shades:
Good link. Glad to read it. An opportunity for the consultants to get in on the rearchitecture end of things if they stay wary.

[Scottie P]

and as BrettDJ also pointed out...the people who depend on custom solutions will stay with what is easily customized. I too believe that spreadsheets still have plenty of life ahead.
The only difficulty is in that MS will ultimately end it's support for aging versions. Not to worry - there is VBAX and all of the others that we have learned from and contributed to. As long as we keep doing what we are doing people will always have the availability of a custom solution for their spreadsheet at their fingertips.

And, of course many of the VBA gurus have already started to transition into the new breed so I am sure we will have (at least to some degree) some backward compatability.

X

[jamescol]

I think we'll see at least one more iteration of VBA in the next Office release. After that, Longhorn will replace vbscript with something new, and I expect VBA will follow along.

My hunch is that whatever follows will be:

1. Fairly simple for VBA-literate folks to adapt to
2. Be even better than the VBA we have today

My .02

Cheers,
James

[shades]

Rick Schaut is a member of the MacBU at Microsoft, and maintains a blog on Microsoft/Mac development. His latest addresses the issues of AppleScript and VBA.

Article and Feedback:

http://blogs.msdn.com/rick_schaut/archive/2004/06/25/165528.aspx#FeedBack

Interesting comments.

[mark007]

Thanks for pointing me to that article. That was very helpful. They're right too; it's just too easy to pass the limitations of VBA unless you're writing a very limited office application or solution.


I've never found anything that I wanted to do in VBA not possible it's just a matter of working out how to do it. Many things are harder in VBA than they would be in VB but they are still possible.


I think we'll see at least one more iteration of VBA in the next Office release. After that, Longhorn will replace vbscript with something new, and I expect VBA will follow along.


Exactly. As I was saying before with longhorn will come greater integration of .Net and the internet with the OS and things will change dramatically. This is a good few years down the line though and who knows what will happen really - office/VBA included. WinXP has been out for a while now but I would say 98% of businesses still use 2000.

:)

[Anne Troy]

Are y'all telling me I oughtta be buying another domain name sometime soon? Let's get it done...before everything hits...

[mark007]

How about www.dotoffice.com. Assuming it did eventually move to .Net. At the moment the future is completely unknown though so ....

Already being used!

[ptvGuy]

How about www.dotoffice.com (http://www.dotoffice.com/). Assuming it did eventually move to .Net. At the moment the future is completely unknown though so ....

Already being used!It may be bit pretentious, but www.dotofficeworld.com (http://www.dotofficeworld.com/) is available.

[XL-Dennis]

Hi all :006:

I've been working with VB.NET (part of the Visual Studio.NET) for the last 8-9 months and it rocks as well as the interface do.

We tend to live in two worlds, where one of them is the daily work which involves working with yesterdays and todays tools. This involves VBA to a high degree but also other techniques and tools. The other world we live in is the future which we only get fragments of mainly because of the limit information available and the lack of knowledge about the present and coming new tools.

What we know today is that MS focus on the NET-plattform as the "one and only"-plattform for developing. We may or may not agree with this rapid development but it's a fact.

At present we can only speculate about the implications for our daily developer-life due to this strategy.

What we also know is that MS has always make sure of a high degree of backwards-compatibility, unlike many other vendors, and this is some kind of guarantee for future changes.

The developer-version of MS Office is now a part of the NET-plattform as Visual Studio Tools for Office (VSTO) and it's the bridge between managed code (NET) and unmanaged code (like VBA) which rely on the old COM-technique. (A special note is that the tool-set only works with Word and Excel 2003 and above.)

It strongly indicate that:
* MS maintain its backward-compatibility strategy.
* VBA will co-exist with the new programming-languages (VB.NET/C#...)
for a longer period.

The way we code in VBA is still valid and although there has been some major changes between VB 6.0 and VB.NET the coding-technique per se will still be valid (Yes, VB 6.0 heavily rely on VBA 6.0).

We need also to keep in mind that VBA has been made available to the third parts, i e other vendors, who has incorporated it in their softwares. A major change from MS will take a longer time before it get full effect among the other vendors.

MS Office is the de facto standard today worldwide. It means that many companies and organisations have made huge investments in this plattform, including many solutions based on VBA. Therefore it will take a longer time before they aband the VBA-plattform and replace it with the lastest available MS-Tools and MS-techniques.

To summarize it:
* Continue to learn & use VBA and all the present other tools and techniques.
* No matter what will happend in the future we still be using VBA.

I welcome the next version of Office. It?s time to give the VB-editor a facelift and incorporate more Intellisense and also make ADO.NET available via Office.
In addition it is also time to update the chart-technique in MS Excel and add more power when it comes to built-in tools and functions.

Thank You for reading my post on this subject,
Dennis