Last week I highlighted how embarrassingly deathproof VBA has proven to be. Especially compared to its alleged big brother VB6 that died with barely a murmur back in the day. I say dead, there are still plenty of us still actively coding VB6 – there is nothing better for a whole raft of applications and scenarios – I mean dead as in off Microsofts support map. No reprieves, extensions or back pedalling for VB6.
These last few days I have be working in a technology that has been threatened with retirement lots of times, and continued as a core product feature regardless, the real Daddy of technology:
why? because of the gaping holes in COM/VBA coverage of the Excel OM.
- Number of printed pages? – not with VBA (ignoring app.executeXL4 of course)
- Connect to Dlls when you don’t know the path at release time – not with VBA (not without some grotty virus-like code generation anyway
- Some protection/function registration combos – not with VBA
- Some mildly esoteric chart stuff – not with VBA (or 2007 probably!)
- And some other stuff I forgot
- And some stuff I don’t know about I’m sure
At one point I even fired up my old Excel 5 lapper because I needed to record some XLM to fix a syntax problem I was having.
They have been trying to kill off XLM since Excel 5 in 1995 and its still alive and kicking in 2010. So even if its gone in vNext that’s still 20 years of healthily cheating death. Fair play.
So yeah VBA is hard alright but XLM is harder.
I totally accept that some of those golden oldie languages like cobol and smalltalk and fortran, and even C are still ticking along, in fact isn’t fortran about to be relaunched into the limelight as F# for .net? (yep its in VS 2010 beta 1). But these non vendor specific languages are much more steady (lifecycle wise) I would say. Would you?
I’m really highlighting the longevity of VBA rather than any affection I might have for the language. (I have none, I would rather work in almost anything else (except XLM) – if it were as effective).