[WTC = What the chuff!] (chuff)

Marcus spotted this over at JOS:

VBA for Mac goes away (may be one or two down by now)

I think we’ve discussed this before, but I thought there may still be a bit of mileage in it.

Official reason VBA is going away on the Mac, is few people use it, its hard to maintain (for MS), Apple has AppleScript instead.

Unofficial reasons/conspiracy theories revolve around commercial pressure to slow adoption of Macs (they are rapidly increasing market share (still sub 5% though I think)).

Hopefully we all know there is limited love for VBA at Microsoft, where the (current) preference is for .net everywhere. Also MS recently released PowerShell which looks to be built on/a version of Windows scripting host, so they are still keen on scripting.

VBA is almost just a scripting client to an Excel server. You can do pretty much the same stuff with VBScript (or Javascript) with .vbs or .js files. I can imagine some people thinking thats good enough, no need for VBA. They miss some critical facts though. Scripts are late bound, VBA is early bound, scripts are separate files/components, VBA is integrated into the .xls. VBA is a proper language with data types etc, Got any others?

Now I’m not saying VBA on Windows is going away any time soon, I have no idea what the current plans are. But VBA has already stagnated for 10 years, the only VBAIDE update in 2007 was the mouse wheel scroll. Where are our tabbed code pages (like VS2003)?, tasklist (VS2003)? where are our snippets(VS2005)?, and there are plenty of other useful coding features that are almost certainly never going to make it to the VBAIDE. And no third party is going to target it, 1. because its nearing retirement, and 2. because the editor doesn’t expose much object model.

I believe if MS want to drive uptake of the next version of office they should revamp the VBAIDE. I thought VSTA would be in 2007, which it isn’t, so its easy to begin to wonder if MS are losing faith in Office product based Office development. Do they really think we’ll all move to Visual Studio? Or that VS devs are interested in targeting Office?

I do know of a few other devs who are rather concerned with what MS seem to be doing in this area. Are you bovvered?

Do you get the sense they are pushing us out of Excel/VBA development? Or at least trying to make other dev tools more attractive, by not developing the VBAIDE.

As a side note Novell are currently working on native VBA support in OpenOffice Calc, which I think could prove to be an ironic success.

see some of you tomorrow



17 Responses to “VBA WTC???”

  1. MikeC Says:

    Bovvered? Hells, yes…

    My personal conspiracy theory is:
    1. The push towards .NET, for which MS offer certifications such as the MCSD. No qualifications from MS in VBA, therefore no revenue.
    2. The bad press around spreadsheets. Mostly due to spreadsheets being used in inappopriate ways by inappropriate people, plus add in “Versionitis” and we have a lot of reasons why people are starting to mistrust Excel for anything complicated. Raise the trust levels, and more sales result.
    3. Excel 2007 being targeted more towards “novice” level users with its interface (IMHO!), where a lot of that level of user are currently a little frightened by things like VBA. Solution? Reduce what can be done with VBA (such as modification of the CommandBars etc in this release) until it’s no longer viable, and that way novice users are more likely to use Excel, = more sales.

    The single improvement you mention in 2007 – support for the mouse scroll wheel – has been overcome in earlier versions by wonderful tools such as VBScroll (free download from here if anyone doesn’t have anything similar), so I’m quite grateful in this instance that the company for which I work is years behind the current release and unlikely to upgrade anytime soon.

  2. Stephane Rodriguez Says:

    VBA was part of the Office platform lock-in strategy. It still is. It’s more than script, it’s a wrapper of WIN32. Don’t forget the tons of addins out there using a combination of WIN32, COM, OLE in VBA. The combination of Windows+Office is very powerful, especially when you remember that the InternetExplorer+Office strategy failed (this was based on the undocumented VML library that ships with Internet Explorer : http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf)

    VBA has been in maintenance mode for at least six years (Summit Software). What do you expect from those guys?

    (Ironically enough, they are now also responsible of VSTA. Kind of speaks volume what not to expect from VSTA…)

    VSTA is no replacement because of the deployment issues associated to mixed mode. VSTA itself is nothing by the way, you need an actual object run-time, such as VSTO for Excel.

    Why is Microsoft doing nothing about it? because if they did time bombed VBA (and force whatever .NET crap in replacement), the retaliation would be so great that they would be the biggest casualty.

    As for Novell work on “VBA”, the very definition of VBA being a wrapper of WIN32 means that either Novell won’t go very far or they will end up shipping a Windows-only version of OpenOffice. (Of course, Microsoft is happy about this, since OpenOffice+Windows is still a form of lock-in strategy).

  3. Dennis Wallentin Says:

    >>Are you bovvered?

    FWIW – No

    VBA will still be around as long as it exist Office versions that include VBA among the corporates.

    Sooner or later VBA will be replaced in a similar way that Excel4Macro language was replaced with VBA in the early 90’s. However, we still have access to it.

    Classic VB is still around although it’s no longer developed & supported by MSFT.

    In one or another way we all need to realize that we need to learn .NET. VSTO and VSTA are .NET based and so will other new tools be as well.

    For those of You who hope that a tool like VSTA will be a non .NET tool will be very disappointed and concerned. Check out the following post by KD Hallman:

    VSTA breaks down the barrier between coders

    With all the respect to this subject I believe it’s more important to discuss what Dick Moffat recently pointed out in a blogpost:

    Where Have All The Excel Guys/Gals Gone ????? http://blogs.officezealot.com/dmoffat/archive/2007/04/19/where-have-all-the-excel-guys-gals-gone.aspx

    Kind regards,

  4. Simon Says:

    Mike -point 3 O2007/novice users – I totally agree.
    Stephane – I don’t think of VBA as a win32 wrapper – that is .net, and I’d say VB6 is more a wrapper around COM, than win32. Wine and crossover provide win32 compatitbilty (roughly) on Linux.
    What I expect from Novell (in time) is that if you open a .xls in OOo Calc with standard VBA code it will run and do the right things. I’m not too bothered what or how it does it, but I totally expect it to run just as well on Linux. VSTA/VSTO – same story I don’t care whats going on underneath, I just want a decent code editor, performant code and easy deployment, a bit of security might be handy too. Personally I’d prefer a C based language, but I can live with something derived from basic.
    Thanks for the Summit s/w info, I’ll look into them
    I agree on the time bombing, but they have left us in limbo for quite a few years now, it can’t go on much longer. can it?
    My point is that really MS seem to be giving up on this Excel/VBA/Windows ‘lock-in’, and I’m not sure why. Do you agree on that? do you know why?

  5. Simon Says:

    Maybe people aren’t moving into Office development because of this confusion/uncertainty about MS commitment to it going forward.
    Youre’ right, the future is sure to be .net, but when? how long do we have to wait until it is compelling for our customers?
    I don’t see any signs of customers queueing up for .net based Office development. What I do see is lots of Office VBA development from the business and lots of .net web apps from IT. The 2 don’t meet, never have, I’d like to know when/if they will.
    If Visual Studio Orcas will solve it (release in 2007?) and large scale adoption is 2-3 years out then .net/Office may be compelling in 2010. What shall we do till then? And what shall we do for the 80% or so of orgs that still will not have office 2007 or better by then?

  6. Stephane Rodriguez Says:

    “I don’t think of VBA as a win32 wrapper”

    Well, you can import WIN32 functions and use them, which means it’s unsafe and all that. OLE and COM and ActiveX are all part of WIN32.

    How would you reproduce this in Novell’s VBA clone on Linux? Of course, the answer is you can’t. That’s why Novell VBA is only a faire-valoir.

    “how long do we have to wait until it is compelling for our customers?”

    It will never be the case. Microsoft must write next-gen Word/Excel/Powerpoint that are like brothers to the .NET environment (from both the design, development, debugging, deployment stand points). I am not talking revisions of Word/Excel/Powerpoint here : we also know Office 14 is just more of the same, not a rewrite of anything.

    It will never happen because Microsoft tries to keep the lock on their cash cow, it would be suicide to offer a breaking (more modern) alternative.

    “What shall we do till then? And what shall we do for the 80% or so of orgs that still will not have office 2007 or better by then?”

    If you wonder why Microsoft strategy seems so odd, just ask yourself : I say Microsoft first needs to understand that C# and other .NET languages need to support something as trivial as optional parameters in method signatures, if what they want is to compel developers. If you already wrote some Excel-COM code with the PIA in C#, you know what I mean.
    I suggested this when Excel 2007 was in beta, and got the typical yeah-yeah response from Microsoft.

  7. Simon Says:

    Stephane – right I see what you mean re win32 (v managed).
    I don’t think Novell are going for 100%, but if they get the most used 10% that would be enough for an awaful lot of apps. WINE is win32 on Linux so its totally do-able. Faire valoir, good expression, saving face right? I thinks its more than that, but let wait and see.

    I thought VB.net had optional params (I dunno, I’ve never used it), hence recommended for Office dev.

    C# has function overloading – it would have been nice if it came from MS with a full set of possible overloads for office so we don’t all have to write our own (I have also requested this from MS). I know what you mean though, C#/Excel is definitely painful programming.


  8. Dennis Wallentin Says:


    I can agree that it would be welcoming if MSFT could give us a hint about “what” and “when” when it comes to VBA.

    If I would speculate about it I would say that MSFT at present simple don’t know! If I would speculate more I would say that VSTO so far has not been the great success that MSFT perhaps wanted it to be.

    VS ‘Orca’ will not give more input to what we already know today. A new version of .NET Framework will be available (3.5) and VSTO will be part of the VS platform. Yes, VSTO solutions will be exposed better then today to VBA. So perhaps the future is collaboration between different technologies?

    From what I’ve seen and discussed in my part of the world is that VS has given new interest in desktop’s application as VS offer better options then what classic VS did. Perhaps this will be the ‘bridge’ between .NET and VBA?

    Kind regards,

  9. Harlan Grove Says:

    I may have a much different perspective than the rest of you. The spreadsheet models I develop and maintain are light on UI outside of worksheet cells, and usually have fewer than a dozen macros (public Subs without parameters). The bulk of my coding still lies in using VBA to create subordinated processes via OLE to extract data from files Excel can’t open itself (e.g., thousands of legacy Lotus 123 .123 format files). You have no idea how warped one’s mind can get mixing Excel and 123 object models in the same code!

    Anyway, if anything hinders Excel adoption, it’s Excel itself, not VBA. As long as Excel’s object model is exposed and available for scripting, VBA isn’t essential for macros. It’d be a pain to have to use something other then the VBAIDE to create dialogs (user forms), but I could adapt if forced.

    What’d be much less pleasant is no longer being able to use udfs written in VBA. I know there are performance benefits to .XLL or .DLL (COM) add-ins, but they’re overkill for many things, and calculation-intensive udfs (e.g., eigenvectors/values and other nontrivial linear algebraic calcs) suffer relatively less from the Excel/VBA interface drag. The main reason I started using Excel back in the late 1980s with version 2.whatever that came with it’s own stripped down Windows runtime was the ability to write and use udfs. Array formulas are nice too, but inessential in comparison.

    UDFs were in XLM back then. VBA made it much cleaner and more reliable to write them. If that facility were removed from Excel, there’d be much less reason for me to use Excel than either a lightweight typed language with a grid control or a heavyweight scripting language with Tk or HTML tabular forms. Or scripting languages with Google Spreadsheets (hosted locally on the company intranet), assuming its development trajectory is comparable to that of Google Earth. So spreadsheet mashups.

    There’s so much still needed in Excel itself that I’m concerned about VSTO/VSTA/.Net distracting from what really matters. However, MSFT’s push for ever greater uniformity of all Office applications probably means there’s not much hope for large scale gains in spreadsheet-specific functionality in Excel.

  10. Marcus Says:

    I’m resistant to theories which involve MS trying to wipe out Apple. Keep on a leash? Sure. But MS would suffer from Apple’s demise. MS also happen to have a healthy shareholding in Apple. And from an anti-trust perspective, MS will surely want a couple of healthy, albeit non-threatening competitors. MS isn’t going anywhere soon. After MS, the next 10 biggest players in the software field don’t even come anywhere near the behemoth that is MS.

    VBA vs. VBScript … any others
    > VBScript is (very) loosely typed. While VBA is that strongly typed at least there’s more than variants.
    > VBScript has no facility to create GUI’s

    “Do they really think we’ll all move to Visual Studio? Or that VS devs are interested in targeting Office?”

    I believe that half the reason MSO/VBA has entrenched itself so firmly in many corporate environments is because it is so accessible to the non-developer. Many professionals (accountants, engineers etc) have been able to hack together some trivial, and some not so trivial, solutions to their everyday work problems. I’d imagine the interest from this audience in VSTO would be somewhere between negligible to nonexistent.

    Am I Bothered?
    Not really. The main area of deliberation is where to focus my efforts in context of technical skills development. Case in point: My copy of Excel Services was delivered yesterday (woo hoo – sorry, kid in a candy shop). While I’m interested in the area, it has MSO 2007 as a dependency. I can’t see a single client implementing MSO 2007 in the next 18 to 24 months. Some have just upgraded to MSO 2004. This tells me that my VBA orientated work isn’t going away any time soon.

    P.S. Has anyone out there had any real world experience with Excel Services? One project I thought it may have been suitable for was a migration of a spreadsheet model which performed a Monte Carlo simulation which was migrated to informatica & SQL Server.

    Cheers – Marcus

  11. Harlan Grove Says:

    Re competitors: the competition in the office suite market may be small fry, but IBM, Oracle and SAP qualify as competition in the other sectors, and they’re not what most people would define as small, even in comparison to MSFT in terms of market value.

    Re Apple: they’re not a threat with respect to hardware, but now that OS X runs on Intel systems, they’re much more of a software/OS threat than they used to be. Do I see a connection? Not necessarily, but MSFT doesn’t have a track record of playing nice. [FWIW, OS X is the nicest OS I’ve used, especially now that it provides a Unix-like console window.]

    As a nonprofessional developer (my job description mentions nothing about programming, but I couldn’t do it as well or as efficiently if I didn’t program) no one’s going to give me VSTO, and I’m not about to buy it for myself. As long as Excel provides an object module for OLE automation, I can run macros, but I’d lose udfs. At that point, I’d be better off with OpenOffice. Granted its built-in BASIC dialect and application/IDE interface isn’t as polished as Excel/VBA/VBE, but I doubt the OOo developers would ever dream of yanking it out of the product.

    If MSFT is determined to make Excel workplace-only software for companies big enough to have in-house developers or rich enough to hire outside (out-house?) developers, they’re doing a heck of a job.

  12. Simon Says:

    Harlan – I agree that MS focus more on Office than Excel to the detriment of spreadsheeters. I also agree that there are more and more, ever more viable alternatives in many situations.
    Marcus – I’m interested in Excel services too, but it would be cheaper for my clients to employ a sys admin full time just to watch Excel 2003 on a server, rebooting as required, than to upgrade all clients to 2007. There are many other tools that are similar but with much less cumbersome client requirements. I think a lot more will need to be done to to make this technology worth targeting for me.
    Harlan – good point on competition. I’m doing more and more with products from that stack, and it all reduces work done in classic office apps.

  13. Simon Says:

    Marcus – when you say Excel services has Office 2007 as a dependency what do you mean?
    I thought there were no client requirements if using Excel services as it was all rendered in HTML. I’ve not really looked into it though, do you mean MOSS 2007 on a server?
    I plan to look at this stuff more in 2009/2010, (if I’m still involved with Excel).

  14. Marcus Says:

    Hi Simon,

    I’ve only >just

  15. Marcus Says:

    Hi Simon,

    Hmm… What happened there? It cut the text off at the less than character…

    Anyhoo, I’ve only just started reading my newly minted Excel Services book.


    In the opening pages it lists what you need to develop Excel Services solutions. Right up there is Excel 2007 and .Net. Now you’ve got to remember that the author is from Microsoft, so this could simply be an encouragement (read: push) to MSO 2007.

    I’ve still to determine whether these requirements are red herrings.

    If these dependencies are accurate I’ll basically just put the book aside for a year or two.

    Has anyone been involved in a ‘real life’ Excel Services project?

    Cheers – Marcus

  16. Shahar Prish Says:

    You need Excel 2007 (or Excel 2003/XP with the Compatibility pack) to be able to produce workbooks that Excel Services can load.

    While I am from Microsoft, I am not trying to sell you anything (other than, maybe, my book… :))

    As for what you need to program against Excel Services…
    – If you want to use Web-Services, you dont need Visual Studio. You just need something that can do HTTP SOAP calls (IE can do that – I have examples on my blog for an AJAX library).
    – If you want to create UDFs, you have to use .NET – we only support .NET 2.0 assemblies for UDFs.

    Hope that sheds some light.

  17. Simon Says:

    Thanks for the info Shahar.
    Your book is on my list for when/if I start looking at this.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: