Hi Phillip:
I suggest that you read the online version of your sources
The demise of VBA was announced around 1999 and was intended to apply
to all
platforms.
The Fortune 500 companies, with their giga-dollar legacy base of VBA,
kicked
up such a fuss that Microsoft has delayed the removal of VBA from
Microsoft
Office 2007.
However, they are strongly encouraging new development to be in VB.NET.
Microsoft has not backed away from their intention to get rid of VBA,
they
have simply granted a stay of execution. I will bet they are also
producing
large legal agreements that say "If you continue to use VBA, and your
entire
corporation gets blown away by some nasty viruses, don't try to claim
that
we didn't warn you!"
Microsoft is NOT "Dropping VPC" for heaven's sake
That's just WRONG.
It's a key strategic product for them, in Windows Server 2003.
However, it is no longer needed on new Macs.
Virtual PC for the Mac will continue to be sold for Power PC
machines. On
Mac Intel machines, it's simply not necessary -- the new Macs will run
Windows (better than most PCs...) without it. So there won't be a new
version of VPC for Mac, and it's unlikely that the product will be
reinstated unless and until Apple produces a Mac that won't run Windows.
Cheers
On 9/9/06 6:31 AM, in article (e-mail address removed),
Just read in MacAdict Magazine, That MS was discontinuing any support
for VBA seemed to imply across all platforms. this was also during a
report that they were dropping Virtual PC.
John McGhie [MVP - Word and Word Macintosh] wrote:
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@spoof_usenet.com,
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
