Legend tells of one my old school mates who was as hard as.
Out drinking (underage of course) one night, the semi peace of a saturday night in a northern mill town pub was broken by a huge crash.
A giant barged through the door and demanded in that special Saturday night aggressive tone “who is the hardest ‘kker here?”. Heads were bowed as he was clearly looking for a fight, and it was going to hurt. No one moved, definitely no one made eye contact.
Except Dyksey: “I am – and if there’s any fighting I’m on your side!” he declared jumping up.
Dyksey was always the guy you wanted on your side when things went bad.
Having read that story I might have to go and watch Shaun of the Dead.
VBA really does seem unkillable – and its getting stronger by the day as more and more business critical code gets implemented in it.
What technologies do you think could beat VBA in a pub brawl?
cheers
Simon
Smurf on Spreadsheets 
Tuesday, 13th October, 2009 at 7:04 pm |
VBA will, I submit, continue to exist in versions of Excel that people actually use until it’s replaced by something that is (a) compatible and (b) integrated. I say “actually use”, because I won’t be upgrading to a version that won’t run my code. Not outside of work, anyway – there I’d get paid for sorting out Microsoft’s mess.
I need people to stop saying VSTO because it sometimes happens when I’m drinking and the uncontrollable laughing fits cause me to make a mess.
It really is time Microsoft either outlined a practical strategy for doing away with VBA or admitted they don’t have one. Items to be addressed might include: replacing Excel as a COM server with something more dot-Netty. Excel in managed code, anyone? Heck, with Mono they might even be able to reuse more of the code base in OSX. Double-heck, it might run on *nix…
Tuesday, 13th October, 2009 at 7:15 pm |
VBA is like the Blob, getting ever bigger and more monstruous as it swallows more users… I have to agree with Mike, as much as I like VSTO (or, to be more accurate, hate working with VBA in its editor after getting used to VStudio and .NET), it’s not a viable replacement for VBA – if only because of the different deployment model, and the absence of the macro recorder. If Microsoft managed to get Silverlight to run in most browsers on most systems, maybe they can do something similar for Excel…
Tuesday, 13th October, 2009 at 7:22 pm |
There are only a few things that make VBA different from any other non-.Net language: (1) it’s tied into Excel, e.g., you can step through udfs called from cell formulas, and event handlers and udfs can only be implemented in VBA; (2) its syntax.
Myself, I’d prefer a language with built-in support for arrays. Not just redimensioning them and assigning them to variants, but slicing, joining, rotating, transposing, and matrix arithmetic. I wouldn’t go so far as APL/J/K, but something like R/S-Plus would be nice.
Short of that, it’d be nice to have a Trap/End Trap block added to VBA’s syntax as a replacement for the overly coarse On Error. However, the top of my VBA wish list remains being able to pass 3D references in cell formula UDF calls to VBA.
As for VBA the language, it’s just another BASIC dialect. If you like BASIC, then VBA is fine. If you dislike BASIC, VBA is at best a necessary evil. I’m closer to the latter perspective.
I figure you don’t want this to become a syntax war, so I’ll just end by saying VBA is klunky when it comes to exception handling and inadequate because it can’t handle all the argument types built-in and XLL add-in functions can.
Tuesday, 13th October, 2009 at 7:30 pm |
Python. :-)
It could kick VBA in the nuts…
Tuesday, 13th October, 2009 at 9:28 pm |
Never knew VBA had balls ;-)
Monday, 19th October, 2009 at 5:00 pm |
Our latest ad (at http://www.gilesthomas.com/?p=98 ) asks “Does anyone actually like VBA?” with an appropriately silly image, and it’s getting phenomenal numbers of clicks by banner ad standards, which makes me think that there’s a lot of frustration with the language.
On the other hand, for any competitor to take over completely from VBA, it’s going to have to have serious backward compatibility. This is not easy, neither for us at Resolver nor, it would seem, for the VSTO team… for a start, although the average VBA user probably only uses 10% of the functions, each VBA user uses a *different* 10%.
So getting a sufficient level of backward compatibility to be useful to people moving over is extremely tough, even if the new platform is actually better than VBA.
Monday, 19th October, 2009 at 6:13 pm
I didn’t mean to imply that I actually like the language, just that its deathproof.
Tuesday, 13th October, 2009 at 10:49 pm |
“What technologies do you think could beat VBA in a pub brawl?”
Fortran ;)
Tuesday, 13th October, 2009 at 11:06 pm |
On a more serious note, I don’t understand why MS would want to dump VBA, since it is the only thing stopping many people from moving to a free competitor. Different applications have different needs, and for a large part of Excel application development VBA is the best thing currently available, and should be developed and improved, rather than trying to shoe-horn something else in to replace it. No doubt at the other end of the market there is a need for something different, but there is no reason at all why the two can’t be done together.
On the deficiencies of the VBE question, maybe it’s a lack of familiarity but I don’t see the advantage of the Visual Studio editor. Anyone care to enlighten me?
Tuesday, 13th October, 2009 at 11:07 pm |
Michael + Freddie – are you two a comedy double act? :-) :-)
I’d have said VBA would have Python in a brawl anyday (how many death attempts has Python survived?)
But maybe I’m wrong – results just in – Python is the Daddy:
http://www.googlefight.com/index.php?lang=en_GB&word1=vba&word2=python
Doug fair point and add in Cobol too I guess
Wednesday, 14th October, 2009 at 11:05 am |
bo ah!
http://www.googlefight.com/index.php?lang=en_GB&word1=Excel&word2=python
;-)
Wednesday, 14th October, 2009 at 11:42 pm |
To put it in perspective…. http://www.googlefight.com/index.php?lang=en_GB&word1=paris+hilton&word2=excel
Wednesday, 14th October, 2009 at 7:53 am |
I’m an Excel user, not a developer, who first learned the rudimentaries of Basic on a 1k Sinclair ZX81 – yes I’m that old!. I don’t have any training in computer languages or technologies (I work in an accounts enviroment, although I’m appreciated as much in my workplace for my Excel skills) and feel “safe” creating and editing macros in VBA, and teaching young “upstarts” how to develop their macro ideas. Hopefully VBA will continue alongside any other technologies which you developers seem to adore… please leave VBA for us oldies and users to play with!
Wednesday, 14th October, 2009 at 9:26 am |
What makes VBA different for other .net languages is that its FREE (or lets say paid for once you buy Excel) So I dont have to install /buy anything extra to start coding.
Ability to create COM addins and XLL’s directly by Save AS would be the no 1 item on my wish list for future versions
Wednesday, 14th October, 2009 at 11:10 am |
Sam,
VSTA, should MS ever get there fingers out of there ass and deliver it, will be the same as VBA in this respect.
We should not discount .Net stuff so readily, VBA is amazing, but so too is VB.net, don’t discount it, and don’t think that MS wont, (given time!) come up with something even better than VBA. They can be quite good at times you know!
;-)
Wednesday, 14th October, 2009 at 6:22 pm |
Actually, .NET is free, too, and you don’t even need to buy Excel to run it :) Visual Studio 2008 comes with a free edition which is fully functional, and can be downloaded here.
http://www.microsoft.com/express/default.aspx
Wednesday, 14th October, 2009 at 8:02 pm
Mathias
that is a very good point the express editions are a superb resource. Now if they would put the VSTO projects in them it might actually gain some traction.
Wednesday, 14th October, 2009 at 11:22 pm |
Q: What technologies do you think could beat VBA in a pub brawl?
A: Java!
In addition, in the long run VBA is dead and will be replaced despite what You guys want. I’m already looking forward to Excel 15 to see what MSFT will replace VBA with.
Kind regards,
Dennis
Thursday, 15th October, 2009 at 12:44 pm |
Dennis –
I doubt VBA will be “replaced” by anything in Excel 15. If there is another programming system, it will be placed alongside VBA in the developer’s set of tools. Much the same as VBA has coexisted with XLM for all these years.
Thursday, 15th October, 2009 at 12:41 am |
Dennis
I’d like to imagine it would be an extension(/evolution?), rather than just a replacement.
But then again with the current pattern of bold retirement statements followed by rapid backpedalling and lifecycle extensions, literally anything could happen.
You would have to say that the feedback from the MacOffice experiment appears to be VBA is worth keeping currently.
Thursday, 15th October, 2009 at 8:19 am |
The first step is to write a translation routine from VBA into whatever the replacement is – if it was accurate enough, people would be much more willing to migrate their legacy code – but I can’t see MS doing that properly but more likely to do a poor first attempt, cause early adopters grief and then a couple of SPs later it might actually work
The Excel team seems more concerned at the moment with trying to find database-type functions to gobble up their 1,000,000 rows – that would be far better done in a proper database package
Thursday, 15th October, 2009 at 8:26 am |
Mike they had that VB6 to VB.net migration bag of hammers that was a complete and utter fail. Based on that I think you are generous to give them a couple of SPs to create something useful.
And I bet it would be the VS team rather than an office team, and we know how much VS loves VBA – they have been trying to kill it for 10 years (and failed cos it’s well ‘ard).
Thursday, 15th October, 2009 at 9:52 am |
Well, then I’d suggest MS getting competent third-party such as Tangible Software to do a better job
Thursday, 15th October, 2009 at 12:45 pm |
Can you spell “NIH”?
Thursday, 15th October, 2009 at 10:09 am |
Simon,
It’s always nice to speculate! Anyway, when I look on how VSTO has evolved through the years it’s noteable that MSFT has simple cut off previously versions but with 2007 it support all versions.
A side-by-side set up with VBA + the new language may be a too large overhead to carry and may also be difficult to resolve from a technically point of view.
But again, only the future will tell us what will happen.
Kind regards,
Dennis
Thursday, 15th October, 2009 at 10:14 am |
@dougaj4,
MS most definitely DO want to ditch VBA because their strategy is to position Excel as a presentation layer on top of a .NET solution which includes SQL Server, MOSS, Excel Services (or whatever these products are all called now). So the ‘real’ work is done by ‘proper’ IT types, and Excel users just become consumers of the information. VBA is a huge barrier to the world fawningly accepting this stragey. Does this seem the fright apprach to you?
Thursday, 15th October, 2009 at 8:54 pm |
Bob,
As I see it; MSFT wants .NET developer to discover that they can create Office solutions without porting themselves to VBA. I cannot see any harm with that. Do You?
In large corporate solutions Excel *is* the presentation layer and it’s better that Excel is included then excluded in solutions like that. As a personal tool it is a spreadsheet tool.
In my opinion it would be a difficult situation if we create a situation where VBA developers are against the rest of the world. Nothing good can come out of an attitude like that.
I really like the fact that Office is on MSFT’s agenda as a development platform. In that way it will be possible to make a living of Excel services (of all kind) in the future too!
Kind regards,
Dennis
Thursday, 15th October, 2009 at 10:35 pm |
Dennis,
No I see no problem if it were just that.
The problem that I see, and I have been in companies experiencing this from the inside, is that where IT take control of the development, the business suffers. Solutions are imposed, they are over-engineered, and they are usually way behind the business timeframe.
Unless MS deliver a .NET solution that is accessible from within the Excel client, as against outwith the client (and I sincerely hope that they do as I want to move to .NET, I much prefer the language(s) and the IDE), IT will contriol all Excel development as well, and I don’t see much opportunity for one-an bands like you and I.
Friday, 16th October, 2009 at 12:22 am |
In the same vein as Bob, the reason spreadsheets and small database programs became so popular is that they allowed NON-IT people to build useful applications which IT developers were unwilling or incompetent to develop. With the explosion in development technologies over the last 20 years, IT developer business incompetence has worsened. As for unwillingness, they claim to want to take over most development, but once everything is recentralized it’ll be back to the bad old days of waiting 18 months and paying US$100K for the equivalent of a few fixes to some print macros.
I lived through the great decentralization, I have have my own first-hand memories of MIS/DP managers telling my manager that they couldn’t, in good conscience, give anyone in our department electronic access to mainframe data files or reports because MIS/DP couldn’t control how we used the data. They could only continue giving us hardcopy printouts (many were several thousand pages, so a few linear feet of stacked printouts). However we used the printouts was apparently not their concern. Logical reasoning never was a job qualification for IT managers.
But they made the mistake of giving another guy in my department a PC with an IRMA card and a printer that could be used as a mainframe printer. Within a week he’d figured out how to cache print jobs on his harddisk, and I set about writing awk scripts to turn the cached reports into useful flat files.
That’s what we’re going to see again once IT has eliminated non-IT development, only this time they won’t make the mistake of giving us (or allowing us to acquire and install) any tools to make our jobs easier. Instead of having to retype company data from mainframe printouts, we’ll have to copy/paste company data from server-generated PDF files.
In the current IT worldview productivity and security are diametrically opposed, and security is goal. Microsoft is happily facilitating this.
Friday, 16th October, 2009 at 10:14 am |
Guys,
I assume that MSFT will provide us with a .NET based new language inside Excel. Hopefully it will include a recorder as well. .NET developers have difficulties to learn and understand the Excel object model while VBA developers have no access to VS or have difficulties with C#/VB.NET so both group of developers are in need of some support.
The list of prerequisites, in order to run any .NET based solutions, gets smaller and smaller so MSFT is doing a good work here. The security model on .NET platform is superior the VBA security model but comes with the price of less flexibility.
I have had and still have my share of battles with centralized IT-departments. But I also work more and more with the centralized IT-departments. However, I cannot see why MSFT should be blame for it.
After all, it’s up to each organization to organize their IT-structure. The general key issue is that the IT-departments don’t understand the business needs on a micro level and the buiness does not understand the IT needs on a macro level. But again, don’t blame MSFT for it.
As MSFT and the corporates moves more and more to the server platforms we, i.e. one-an bands, needs to follow. What makes it difficult is that it requires expensive investments in hardware and software to get access to the most common MSFT server platforms.
It would be very nice if MSFT could offer us access to them on their Azur platform for a small monthly fee. They could start with the group of Excel MVPs as a trial.
Kind regards,
Dennis
Friday, 16th October, 2009 at 11:51 am |
“Does this seem the fright apprach to you?”
Yes or no respectively, depending on whether you meant “fright” or “right” :)
Not that it’s really “frightening” for me personally. I’m sure I’ll have fun getting Gnumeric + Python or whatever to do what I want, if necessary :)