Why VBA? (Part 2)

Let’s look at the case against:

  • Yes, it’s from Microsoft, and some people react against that by instinct. But the fact is that Office is overwhelmingly the de facto standard for desktop software, and VBA is part of that platform. If Open Office does take over, then we’ll use its scripting language, which is or will be very like VBA. So I don’t think that using VBA waves any sort of flag for Microsoft – it’s just something that’s out there to use.
  • Yes, there are security issues with any kind of executable code in a desktop environment, in that, obviously, an executable can potentially do anything (delete files, send emails, etc). However, we now live in an IT world where security issues are pervasive, and this is just one among many, of which we all need to be aware. I’d guess that the vast majority of VBA code is developed and used in-house, and so can be subject to normal quality control. Similarly, add-ins from reputable vendors are not going to be a problem. So the only source of malicious macros is injudicious downloads from the web, or spam emails, and we should all be extremely wary of those.
  • Yes, as a language it’s not ideal. Having started as a very simple language about 30 years ago, and having been subject to many elaborations since then, it’s not exactly a language designer’s delight. There are annoyances, inconsistencies and redundancies (I’ll comment on some of these in later posts). But many other languages have been at least as bad and have been widely used (we round up the usual suspects). Personally, I’ve used probably the best designed programming language ever used commercially–Eiffel–so I set high standards; but even I can used VBA without swearing more than occasionally.
  • Yes, VBA is used by people who aren’t ‘proper’ developers, but then so are many other scripting languages. We live in an age of lightweight languages, agile development, and so forth; it seems strange then to argue against that for VBA in particular. Clearly, the more serious the scale and scope of development, the more that software engineering practices such as testing and version control are necessary. One of the issues I’ll try to address in this blog is how to use VBA in a disciplined manner.
  • VBA looks like it will be around for a while yet. There’s just too much of it out there for it to be radically changed or removed from Office. In any case, it’s hard to see that an application scripting language could be fundamentally different from VBA, because of the nature of the applications themselves.
  • So I suppose the conclusion is: yes, it has it’s flaws, but it’s out there on nearly every PC, it’s useful and it’s usable.

0 Responses to “Why VBA? (Part 2)”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

January 2009
    Feb »

%d bloggers like this: