The other issue is VBA itself. Solver may make a comeback in a future version
of Excel 2008 depending on how loud the screams get, but VBA will never see
the light of day on the Mac again. Microsoft would love to kill VBA on Windows
as well, since it is a dead-end code base in terms of their .NET strategy, so
it didn't make any sense to put any effort into a new version of VBA for Mac
Office. Microsoft has pledged that VBA will remain in the next version of
Windows Office (after some reports to the contrary [1]), but they also stopped
licensing Windows VBA to third parties last July and have recommended that new
Windows Office applications and add-ins (like the Solver) be written using
Visual Studio Tools for Applications or Visual Studio Tools for Office, both
.NET environments that have no VBA anywhere and will never be offered on the
Mac. Nothing substantial has been improved in VBA for years, so it's clear
that it is on it's way out on Windows too. Much like Microsoft's old C++ GUI
MFC library, it's just a matter of how long it takes to kill it off.
Microsoft is treading on thin ice here. There is another subtle point here on
backwards compatibility that goes back to the introduction of .NET. VBA was an
outgrowth of Visual Basic. When .NET was evolving, Microsoft realized that the
original Visual Basic language could not be turned into a .NET language as-is.
So they enhanced the language and chose to break backward compatibility with
old VB code. Before switching to the Mac when OS X came out, I was a long time
Windows developer, and this was the first time I ever saw Microsoft ruin
backward compatibility on purpose (See [2] for an interesting essay about this
from the former Microsoft developer who wrote the original VBA spec). Visual
Basic.NET is a completely different beast, and older non-.NET VB code won't
run in .NET. When all of the VB coders realized that their VB code needed a
line-by-line port to work in VB.NET, a lot of them stopped, and for the first
time, lifted their head out of the sand, and looked around for other
solutions. The thought was, "If I need to rewrite this anyways, maybe I should
use Java/Python/Ruby/PHP/Flash/etc.". And that's what a lot of them did.
What's this have to do with Mac Office? Well, there's a similar force at work
here. From version 1.0 until Excel 2008, I never considered using anything
except Excel. It was the gold standard - both for compatibility and for
features. But both compatibility and features have taken a big hit with Excel
2008, and now I'm looking at the vast number of spreadsheets I have with VBA
code that won't run in Mac Excel 2008 today and probably won't run in Windows
Excel 2010 (or whenever VBA disappears completely), and I'm making that same
assessment - If my features are gone and I'm breaking backwards compatibility,
why stick with Excel? There's no way I'm using Applescript to automate
spreadsheets - it's a far worse language than VBA ever was. So I'm pausing to
look around for other options. And you know what? It's kind of refreshing. I
don't expect to find a drop-in Excel replacement, but the market forces will
fill the void in time.
I'm not really frustrated by any of this. I can't say that I agree with the
choices Microsoft made for Mac Office 2008, but I assume they made them after
thorough realization of the various issues that would arise. And I'm not
anti-Microsoft. I very much like the MacBU and have a lot of respect for what
they accomplish, but in the end, I don't think this was their call. I¹ll be it was.
[1] <
http://www.regdeveloper.co.uk/2008/01/14/office_mac_08_vba/>
[2] <
http://www.joelonsoftware.com/articles/APIWar.html>