Re: Word 2004 VBA -> Applescript

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi David-Artur:

Some really good points you raise. I was going to just dash off a quick
comment before bed. An hour later...

On 3/9/06 4:50 PM, in article C12047EC.19C06%daix@xxxxxxxxxxxxxxxx,
"David-Artur Daix" <daix@xxxxxxxxxxxxxxxx> wrote:

While I understand better now why it would not make much sense to spend
resources on bringing VBA to Intel Macs given the fact that VBA is
essentially dead _also_ on Windows, what really does not make sense is the
fact that Microsoft has decided to kill "classic" VB and VBA, period
(despite the huge virus issue, which must have weighted on their decision).

That's it, right there. That's the REASON. And it's the ONLY reason :-)

The controversy rages, of course. The less people understand the issues,
the more noise they're making on the topic.

The basic reality is:

* VBA was designed to provide powerful, object-oriented cross-application
scripting back in kinder, gentler days, when networks were safe places and
the internet did not really exist.

* the fundamental architecture of VBA relies on the fact that you can
"trust" everything in your immediate vicinity. VBA assumes that everything
on your computer is meant to be there, and every program interacting with it
is doing good.

* VBA was also designed at a time when memory and CPU horsepower was a lot
less plentiful than they are today. For reasons of efficiency, they
dispensed with a lot of the "good housekeeping:" and "security" that is
required these days.

So, when it came time to fix the problems that descended, Microsoft made the
sensible decision to do it once and do it right. They designed a single,
secure platform for the entire computer. The Common Language Runtime is
engineered as part of the operating system, and protected by all of the OS's
security mechanisms.

Instead of having to solve all these problems over and over again for every
application that exists, dot-Net solves them once for the entire system. In
the ensuing 20 years, everyone has learned a lot about making software.
VB.NET is not only fairly impregnable security-wise, it's also a LOT faster
than VBA.

You can write very serious applications in VB.NET (or any other .NET
language you prefer, including COBOL...). You can even write different
modules in different languages, depending on your needs and preferences.
They all end up executing on the same runtime platform.

But it doesn't take away the pain of the current "classic" VB
developers, on Macs _as_well_as_ PCs.

No. It doesn't. But in a sense, we only have ourselves to blame. If we
had written our applications properly in the first place, they would
auto-convert to VB.NET :-)

No, you're right. That's not quite true... But nearly. The problems with
converting to VB.NET are largely around explicitly qualifying things.
VB.NET is a lot more strongly-typed and qualified than VBA (it has to be:
it's going into a compiler that needs to resolve its references at compile
time, rather than heading off to an interpreter that can work things out at
run-time).

While on the Mac we have to start thinking about rewriting everything in AS,
on the PC side they have to rewrite everything for VB.NET (which seems to be
quite a bit of work despite the common "VB" name). And cross-platform
support is simply gone in the near future.

Yes. Even Microsoft was taken aback at just how MUCH legacy VBA there is
out there.

It will not come as a surprise then that on the Windows side the forced
switch to VB.NET seems neither popular nor, apparently, very successful
(though I haven't found any recent VB.NET vs VB6 adoption surveys, those
I've seen did not favor VB.NET at all).

I don't believe you can compare them. VB6 is simply another compiled
language. Just why you would use it these days I'm not sure. It's a
language for creating stand-alone applications. These days, I would be
surprised if a software architect did not choose C++ instead.

VB.NET is a cross-application object-oriented language which also supports
massively-distributed computing. Choose VB.NET if you want to hook pieces
of application up across a large number of systems and knit them together
with XML. You can't properly compare VBA and VB.NET either: although the
syntax is similar, they have very different purposes. VB.NET is a much
larger and richer platform than VBA.

I was speaking with one of the world's most advanced VBA coders last week,
who was giggling and chortling at how much easier he was finding things in
VB.NET. It's a much richer environment with a lot more pre-built widgets
that do useful stuff you don't have to write. If you wanted to compare
VB.NET with something, you would probably compare it with Java: they're very
similar in purpose.

And the same arguments I've been reading about the VBA disappearance on the
Mac have already appeared more than a year ago about that forced migration
to VB.NET on Windows: people threatening to stop upgrading their Office
version if VBA is gone, to switch to Open Office instead, and if they have
to learn a new language and rewrite everything anyway to simply forego any
Microsoft-made solution and adopt Java instead (or C#, for those still
willing to consider a Microsoft language: once bitten...).

Well, YOU have managed to make sense of it then :-) Some people are going
to take a little longer. One of the main things we lose is that in VBA, the
code is executing INSIDE the application we're automating. So the VBA
interpreter has the full object model of the host application immediately
available. To do this in VB.NET, you must use Visual Studio to add support
for the object models of the applications you're trying to automate.

Yes, some people will not upgrade their current copies of Office. But they
WILL develop new applications in the new language for the new platform.
Switching to Open Office is not a viable strategy, and they'll find that out
if they attempt it.

Anyone who has tried to get things working efficiently cross-platform in
Java becomes an instant convert to dot-Net :-) You've heard the promise
"Write once, run anywhere"? The reality is "Write once, test everywhere,
efficient nowhere!"

C# simply IS dot-NET. If you prefer object-oriented C syntax, C# is made
for you. If you prefer to write in VB syntax, VB.NET is your weapon. The
object code that comes out of the compiler can be exactly the same from
both.

You would probably choose C# if your main interest was in "efficiency". You
would probably choose VB.NET if your main interest was in productivity.
C-based languages are very close to Assembler: ultimate performance with a
very steep learning curve. VB-based languages are closer to a
fourth-generation language. Lots of pre-built add-ins that massively
improve programmer productivity at the expense of a bit of efficiency.

Typically, VB code doesn't do very much "work". It's great for presenting
displays to single users. C# comes to the fore when you are writing server
applications that are going to do millions of iterations of each step and
support thousands of concurrent users.

In the end, what seems really surprising is that Microsoft would make what
seems to be an incredibly bad _business_ decision regarding VB and VBA on
_every_ platform.

I don't think it *was* a business decision. I believe that if they could
have made *any* other decision, they would have. The bottom line was that
VBA was not safe, and could not be made to be safe. It had to go. From
there, they knew they HAD to re-design the fundamental architecture. If
they were going to do that, far better to do it once and get it right for
the entire platform, than have to do it over for each of several hundred
applications. And having it as a common runtime enabled some substantial
value-adds that would have been difficult and expensive if they stayed with
the application extension model.

But I can see why people -- and businesses especially -- would simply decide
not to upgrade at all, on Windows as well as on Mac OS, to VBA-deprived
versions of Office.

Sure. So can I. However, I think you will find that what happens is that
business won't "upgrade", it will "replace". Instead of migrating their
existing applications upwards, I think you will find that business will
develop new applications in the new version of Office.

One thing that's not at all clear to anyone, yet, is just how much
programming will be *needed* in the new version of Office. The development
tools and documentation have not yet appeared for Office 2007. When they
do, I think we will find that we can accomplish a lot of what we used to do
with VBA -- faster and more reliably -- in XML and all its various
associated technologies.

At least WinOffice 2007 will still support VBA. So that decision has bought
Microsoft some time.

Well, *I* think they caved in to pressure from the "Fortune 500", and what
that has done is *waste* everyone's time :-) The sooner we get out of VBA,
the sooner we will be safe, secure and reliable.

And on Macs, maybe the need for an Intel-native version
of Office will also save the MacBU's bacon, at least for casual users who do
not need cross-platform support beyond document formats. But do casual users
really need/buy Office anyway?

That's a very good question. If you look at the design of Office 2007, you
would see a substantial "dumbing-down" of individual Office Applications.
Together with a move of the "development" and "customisation" functions off
the desktop and into the IS Department. There's no longer much support for
individual users' customisation. Microsoft's research tells them that
end-users basically DON'T use macros or customisations. So the ability to
produce these, and the tools to do it with, have all gone off into the
glass-house where professional information systems people will do that work.

Office 2007 is substantially quicker than Office 2003. I suspect that's
because it's actually quite a bit lighter in weight :-)

I'm not even sure that by a time a CLR would be available on Macs, VB.NET
would still be a viable development platform _anywhere_! At the very least
I'd sure think twice before committing to it.

Very good question. The start-up of dot-Net was VERY slow. People took a
very cautious look, and for years it went practically nowhere. All I can
say is that the up-take of the dot-NET technologies has turned into a flood
in the past year. I think one of the reasons was that developers were
waiting for it to work properly. Another was that they were waiting to see
if Java 2 would solve their problems.

On the WinTel side, I think the VHS vs BetaMax debate is over. Everyone's
going to DVD :-)

Cheers

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <john@xxxxxxxxxxx>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410

.

Relevant Pages

  • Re: Why to use VBA?
    ... c# is not suited to be the only language to write eneterprise Apps or system Programms! ... 1- use existing vba apps with new versions of office ... If Microsoft were to rewrite Office using the .NET platfrm instead of the ActiveX platform it uses now, they would probably be 4 years doing the rewrite with no features added. ...
    (microsoft.public.word.vba.general)
  • Re: Why to use VBA?
    ... all I am saying is its time to start introducing new features in .net that will do the same thing VBA does and give the market time to accept it without dropping VBA as you said executives are conservative to change VBA! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ... Lots of people asked Microsoft what that reason was, with regard to that and dozens of other changes to the language. ...
    (microsoft.public.word.vba.general)
  • Re: Word 2004 VBA -> Applescript
    ... I can understand and it did say with the advent of Boot camp and the other applications there was no need for VPC. ... Maybe it was VBA would no longer be supported on the Mac version? ... Since I expect the Mac Community is not wedded to VBA and don't have much at Stake. ... language you prefer, including COBOL...). ...
    (microsoft.public.mac.office.word)
  • Re: Why to use VBA?
    ... MS can not keep VBA for 20 years no technology will remain more than 5 or 6 years in computing field! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ... Lots of people asked Microsoft what that reason was, with regard to that and dozens of other changes to the language. ...
    (microsoft.public.word.vba.general)
  • Re: Word 2004 VBA -> Applescript
    ... I have the actual article in from of me its in the Mailed version of the Oct Mac Addict Magazine that comes with the CD. ... I don't no whether it means That VBA will be totally unusable in Mac Version from now on. ... You can write very serious applications in VB.NET (or any other .NET ... language you prefer, including COBOL...). ...
    (microsoft.public.mac.office.word)