VBA Going Away, Macs Now, PCs Soon

Nom du Keyboard writes "As Microsoft drops support for older Office file formats, it looks like Visual Basic for Applications is also going soon. Mac Office 2008 has dropped VBA in favor of enhanced support for AppleScript, and Office 2009 is scheduled to lose it in favor of Mac incompatible Visual Studio Tools for Applications (VSTA) or Visual Studio Tools for Office (VSTO). This sounds like the Mother of All Backwards and Cross-Platform Incompatibilities — especially since there appears to be no transition period where both the old and new scripting languages will be simultaneously supported. And as past experience with Visual Studio .NET has shown, upgrade tools are far less than perfect."

Unless....

[VValdo]

As Microsoft drops support for older Office file formats, it looks like Visual Basic for Applications is also going soon

Unless... what if there were only some alternative, open-source project [neooffice.org] that already supports it on Mac [neooffice.org] and a similar ongoing Windows/Linux project [openoffice.org]...

Oh well, I can dream.

W

Time for Java

[teknopurge]

Not a troll.

Java has a scripting extension [sun.com]. No, not Javascript(only), but you can plug various Scripting languages [java.net] into it, or use Judo [judoscript.com] which is the real endgame for this problem.

Re:Difference between VST(O|A) and VBA?

[Anonymous Coward]

The same VB apps have worked in Office for a hell of a lot longer than 4-5 years.

Wow, that's a surprise.

[ErichTheRed]

No VBA support in the next version of Office for Windows? It's great in terms of eliminating a huge security risk. It's terrible in terms of backward compatibility.

Maybe Microsoft doesn't get this. Companies use SAP, Oracle Financials, SAS, etc. to store and crunch aggregate data. I have never worked in a company that doesn't literally run on hacked-together Access "applications" and Excel macros. Business users pull all that data out of SAP et al and work on it using tools they develop. In many cases, that's because the IT department is too swamped to help them build a proper app, or because it's too much bureaucratic red tape to build an application.

Admittedly, they are replacing it with VSTA. However, any tool that is less forgiving on business-level users' programming mistakes isn't going to be adopted quietly. There's also the cross-platform problem with Mac Office, and the fact that tons of Excel macros and other stuff will need to be rewritten.

If I were Microsoft, I'd build in a highly crippled "compatibility sandbox" that throws up tons of warnings, but runs _most_ non-dangerous VBA code. They did this with Microsoft Graph and other Excel add-ons to encourage people to move on while preserving backward compatibility.

The reversal of the SP3 file format disabling was an easy fix...this one won't be so easy to unwind.

Good Time To Switch to Ruby and Python

[oldwarrior]

Since they can be the glue that hold together cooperating subsystems, rather than closed (and now retiring) VBA.

Absolutely wrong!

[Anonymous Coward]

I wrote a *trading* application in Excel, written almost entirely in VBA (with a C++ ActiveX control providing the real-time feed). It ended up being almost 50k lines of code. All the user had to do was open up his workbook, which had a worksheet for each stock, and voila! real-time updates and the ability to auto-sell based on thresholds and calculations done within the sheet itself.

I can attest that others have done similar, non-trivial projects in the financial industry; that's where VBA is used heavily because it's easier to calculate Black-Scholes using VBA than with in-line formulas.

Microsoft is high on pills if they think this will go over well in the financial sector.

Re:Unrelated VS jab?!?

[MrSteveSD]

The conversion tools just died on some of the code we tried them on. Also if you ever did anything clever in VB to try to get around it's limitations, the conversion tools were a disaster. On top of that, conversion from VB6 is flawed even in principle because .NET does not have deterministic finalization, so if you ever had important code to be run when a VB object expired, all of that would need to be manually changed.

Realizing that conversion was not an option, we instead decided to write all new stuff as C# modules to be called using interop. This was a nightmare too. There are a lot of companies out there that have invested huge amounts of money in developing VB products and many of them just do not have the finances to rewrite everything.

Re:Cross Platform?

[ianare]

Python Power [openoffice.org] baby !!

Re:Cross Platform?

[ricegf]

"There is no macro language specified in ODF [wikipedia.org]. Users and developers differ on whether inclusion of a standard scripting language would be desirable." So, I'm afraid not.

However, OOo defines a Universal Developer's Kit [openoffice.org] that allows development of scripts in any supported language. The one's we have written are in Basic, though our current choice would be Java or Python [openoffice.org] (we us a lot of both).

My current version of OOo (2.3 in Ubuntu Gutsy) lists Basic, Python, Javascript, and Beanshell as available by default. I'd have to check to verify that these same options are available on 2.3 on Windows and Unix.

Re:Cross Platform?

[mvdwege]

Does ODF have a scripting language defined?

Wrong question. ODF is a document format, it defines the form of the data. The data does not determine what tools must be used to process it, except in cases of proprietary formats, where the only tools are the vendor supplied ones. Tying the format closely to the tools meant to process it, to the point of embedding the processing code in the data, is one of the design blunders perpetuated by Microsoft, which gave us such wonderful 'innovations' as Word Macro Viruses.

ODF can in principle be processed by any language that has a decent XML processing library available, or through the API of the document editing tools. The leading API at the moment is OpenOffice.org's, which is open to any language with bindings to its UNO component model, including the language shipping with OpenOffice.org, a version of BASIC resembling VBA.

Mart

Re:Time for Java

[lgw]

As always, it depends on what kind of software you're writing. Java has firmly replaced COBOL as the tool of choice for business programming. Java will never replace C/C++ as the tool of choice for infrastructure programming (although JVMs written in Java are an entertaining exception).

Re:Difference between VST(O|A) and VBA?

[jrminter]

In the mean time, companies have spent a lot of money supporting and implementing the technologies, buying training, books, etc. Then you re-start the cycle all over again. This is just the next in a long-line of technologies that Microsoft has swept under the rug and moved on. Then a whole new gravy train starts.

Well put. As an analytical scientist (microscopy and image analysis), I use VBA to automate data analysis and prepare reports and graphs because Excel is ubiquitous among my client community. I have a big investment in VBA. My employer has been reluctant to roll out new Microsoft versions because they offer little real benefit to our business.. Guess we'll continue to "just say no" to new versions. When that fails, there is Python.

VBA isn't exactly 'going away'

[BitZtream]

So, for those of you who aren't used to Microsoft or, who are too blind to see. Microsoft doesn't invent new technologies, they rename thier current ones. VBA isn't going away, its getting renamed. You know this whole .NET thing? You know how .NET assemblies are 'new and different' Let me give you a hint, under the hood, they are basically OLE version 3, 'ActiveX' was OLE version 2.

Yes they are new, Yes they aren't 100% backwards compatible, Yes you can still use them with the same old code as before with a bit of tweaking.

VSTO is the same crap, different name. Stop letting the marketing people freak you out so much.

Funny, my captha is arrogant ... how fitting.